Resumen

  • RFC 3191 colocó una representación telefónica mínima en la parte local de una dirección de Internet, pero sólo el MTA responsable del dominio derecho podía interpretar el selector de servicio, el número y sus calificadores.
  • El estándar no confundía una forma válida con una entrega probada: ignoraba separadores visuales, conservaba extensiones desconocidas, dividía subdirecciones en destinatarios distintos y trataba DNS, SMTP, la pasarela y el dispositivo final como observaciones diferentes.

La arroba era una frontera de autoridad

Las primeras pasarelas entre correo y telefonía no carecían de formatos; tenían demasiados. Cada servicio podía inventar una forma para introducir un fax, una llamada de voz o un mensaje corto en una dirección de correo. La dificultad no consistía sólo en reconocer dígitos, sino en saber quién tenía derecho a decidir qué significaban.

RFC 3191 respondió con una sintaxis deliberadamente pequeña. La parte local incluía un selector de servicio, un signo igual y la representación del teléfono. Podía añadir calificadores registrados. Después de la arroba aparecía el dominio de la pasarela.

La distribución de funciones era más importante que la puntuación. Los sistemas de tránsito debían respetar la regla general del correo: no interpretar la parte local de un dominio ajeno. Aunque una cadena VOICE=+... pareciera una orden legible, sólo el MTA encargado del dominio derecho poseía el contexto y la autoridad para actuar sobre ella.

Por eso el número no se convertía en una identidad global. La dirección no verificaba al abonado, no demostraba que el destino existiera y no prometía que la red telefónica aceptaría la operación. Designaba una pasarela y le presentaba una solicitud.

El signo más y los separadores no pesaban lo mismo

La forma global empezaba con + y continuaba con dígitos. Podía contener puntos y guiones destinados a los ojos humanos. Un receptor conforme debía ignorarlos, y un emisor debía evitar producirlos. La agrupación visual podía cambiar sin cambiar el número que la pasarela procesaba.

El signo más, en cambio, estaba reservado a la forma global. Un plan de marcado local o privado podía admitirse por otros medios, pero no debía usar ese prefijo para simular alcance global. RFC 3191 no normalizaba todos los sistemas telefónicos: protegía el significado de un marcador dentro del formato mínimo.

Los selectores aceptaban letras, cifras y guiones, sin distinguir mayúsculas de minúsculas. Ejemplos con VOICE, FAX o SMS enseñaban la gramática. El texto advertía que esos ejemplos no eran necesariamente direcciones reales. Una cadena podía pasar el análisis y fracasar por asignación, política, disponibilidad o capacidad del servicio.

Ésa era una decisión de diseño: el formato describía lo que podía enviarse a una pasarela, no un directorio que certificara todos los destinos posibles.

Un campo desconocido seguía perteneciendo al remitente

Los calificadores ampliaban el núcleo con elementos del tipo barra, nombre, signo igual y valor. Permitían que otra especificación añadiera semántica para un servicio concreto sin fragmentar de nuevo el mínimo compartido.

Una implementación básica podía no ejecutar un calificador que desconocía. Sin embargo, RFC 3191 exigía conservar todos los elementos recibidos. No entender y borrar eran actos distintos. El primero confesaba un límite local; el segundo modificaba la orden para todo actor posterior.

La conservación mantenía abierta la posibilidad de que una pasarela autorizada más adelante entendiera ese dato. También hacía visible que la instrucción original contenía más información que la utilizada en una ejecución determinada.

El registro de IANA imponía disciplina sobre los nombres. Un selector o calificador necesitaba una especificación permanente y suficientemente clara para una implementación independiente; un calificador podía limitarse a determinados contextos. El registro coordinaba vocabulario. No afirmaba que toda pasarela hubiese desplegado cada capacidad registrada.

Compatibilidad no significaba repetir cada residuo histórico

La dirección completa seguía siendo un addr-spec del correo, con sus reglas de comillas. Además, el formato debía aceptar barras oblicuas que rodearan la construcción telefónica. Podían ser cicatrices de otras pasarelas, incluidos caminos X.400.

Los receptores debían tolerarlas. Los emisores nuevos no debían generarlas. Una conversión podía retirarlas. La asimetría permitía recibir historia sin convertirla en una recomendación futura.

El propio RFC era una revisión de RFC 2303. Sustituyó el sentido de «Public» por «Global» en GSTN, al reconocer que la telefonía ya no cabía en un modelo dominado por uno o pocos operadores públicos. A la vez conservó ciertos nombres antiguos en la ABNF para no romper implementaciones. La descripción del poder institucional cambió; los identificadores en uso no se reescribieron por estética.

Varias subdirecciones requerían varios destinatarios

Un mismo número telefónico podía tener más de una subdirección. El correo, sin embargo, contabiliza aceptación y fallo por destinatario. RFC 3191 ordenó generar varios elementos pstn-email cuando una entrada representara múltiples subdirecciones.

La interfaz podía mostrarlas juntas, pero debía entregarlas por separado al MTA. Esta expansión evitaba que un único destinatario opaco ocultara cuál de las variantes fue aceptada, rechazada o reintentada.

Separar los sobres no garantizaba la entrega telefónica. Permitía atribuir correctamente cada transición. El MTA podía aceptar dos destinatarios; la pasarela podía analizar sólo uno; la red conmutada podía no alcanzar ninguno. Cada resultado exigía un recibo propio.

DNS resolvía el camino del correo, no el hecho telefónico

Como el dominio elegía la pasarela, la manipulación de DNS era un riesgo central. Un servidor comprometido, una respuesta falsificada o datos adicionales contaminados podían desviar el mensaje hacia un MTA hostil.

Validar la respuesta autoritativa protegía una parte de la cadena: la elección de ruta. No demostraba que el software de la pasarela fuese correcto, que sus datos estuvieran actualizados, que una política autorizara el servicio o que el teléfono final respondiera. Ni siquiera un número real demostraba que perteneciera a la persona supuesta.

La evidencia debía conservar seis momentos diferentes: la cadena presentada por el usuario, la respuesta DNS, la aceptación SMTP, el análisis de la pasarela, la orden enviada a la red telefónica y el recibo final, si existía. Reducirlos a «funcionó el correo» borraría precisamente el cambio de autoridad que RFC 3191 había hecho explícito.

El formato común funcionó porque renunció a controlar el final

RFC 2846 definió un repertorio más amplio para marcado local, secuencias posteriores, subdirecciones y detalles del destinatario. RFC 3192 aplicó el marco mínimo al fax. Ninguno convirtió la sintaxis general de RFC 3191 en una máquina universal de ejecución.

El beneficio histórico fue más concreto. Servicios distintos compartieron una envoltura corta y un proceso de extensión registrado. Los servidores intermedios transportaron datos que no debían interpretar. Las pasarelas recibieron una orden legible sin prometer que su destino fuera verdadero o alcanzable.

A la izquierda de la arroba estaba la representación; a la derecha, la elección del intérprete. El efecto final quedaba fuera de ambos. La interoperabilidad nació de esa renuncia: cada capa obtenía sólo la autoridad que necesitaba y debía dejar evidencia para la siguiente.