Resumen

  • RFC 3939 definió Caller-ID y Caller-Name para guardar en mensajes de voz lo que la red telefónica había presentado al destinatario, no para autenticar al hablante.
  • El propio RFC mostró que una cadena intacta podía ser inútil o peligrosa: una extensión reenviada perdía su ámbito y un número internacional truncado podía apuntar a otra persona.

Un origen sin dirección de correo

En un mensaje de contestador, el sistema conocía la grabación y quizá el número, pero no necesariamente una dirección RFC 2822 del llamante. RFC 3801 ya contemplaba non-mail-user cuando no era posible responder por correo. Manipular From para incluir el teléfono mezclaba, sin embargo, una identidad de correo con un dato presentado por la red telefónica.

Publicado en diciembre de 2004, RFC 3939 separó ambos orígenes. Caller-ID recibió los dígitos suministrados por la red; Caller-Name, el nombre mostrado. La solución conservaba procedencia, pero no garantizaba veracidad. Ninguno de los campos probaba quién habló, quién poseía la línea o si estaba autorizado a originar la llamada.

El valor predeterminado era desconocido

El número debía contener solo dígitos. Una llamada interna podía aportar únicamente una extensión. Una internacional debía usar la secuencia E.164 completa, sin + y con un máximo de quince cifras. El parámetro opcional NumberingPlan permitía indicar unknown, local o e164; si faltaba, el significado era unknown.

local solo tenía sentido dentro del dominio del sistema de correo de voz que almacenó el mensaje. Por eso el RFC no definía una dirección telefónica marcable. RFC 2806 exigía contexto para números locales en URL telefónicas, y RFC 3191 reservaba + para una dirección GSTN global en correo. RFC 3939 guardaba una observación anterior a esas decisiones de encaminamiento.

Un error podía parecer un número válido

El RFC advertía que ciertos sistemas truncaban números internacionales a diez dígitos. Su ejemplo convertía, mediante pérdida de cifras iniciales, un número irlandés en una secuencia con apariencia norteamericana. El destinatario no veía necesariamente un fallo: podía llamar con éxito a la persona equivocada. Validar longitud y caracteres no detectaba el cambio de país semántico.

El reenvío producía otra ruptura. Una extensión corta bastaba dentro de una empresa; fuera de ella dejaba de ser utilizable y, al mismo tiempo, revelaba parte del plan privado de marcación. El mensaje había cruzado la frontera administrativa sin transportar la autoridad que interpretaba los dígitos.

Caller-Name tampoco era una credencial. Las redes podían usar varios juegos de caracteres; ASCII era la base y RFC 2047 permitía codificar nombres nativos. Un receptor incompatible podía presentar un nombre erróneo, y un proveedor podía limitarlo a quince caracteres.

La privacidad se definía respecto de la pantalla telefónica: un número restringido debía conservar lo que el llamado habría visto, como Private Name, no los detalles internos de los operadores. Pero el correo añadía persistencia y reenvío. El usuario podía ignorar que el número estaba en la cabecera si su cliente no lo mostraba.

Incluso Date admitía dos procedencias: la hora facilitada por el sistema telefónico o la hora local del almacén. Sin registrar la elección, el sello temporal no demostraba por sí solo cuándo ocurrió la llamada.

El logro histórico de RFC 3939 fue acotado y útil: encontró un lugar para datos telefónicos sin confundir transporte con identidad. También dejó escrito que preservar la forma de un dato no preserva necesariamente su ámbito, su privacidad ni la acción correcta que debe seguir.