Resumen

  • RFC 3969 reservó cada nombre de parámetro URI para SIP y SIPS con el fin de impedir dos significados incompatibles; esa reserva doble no declaraba que el parámetro fuese aplicable a ambos esquemas.
  • El documento mezcló la etiqueta “Specification Required” con la exigencia de una RFC de estándares. RFC 5727 identificó la contradicción y confirmó que la intención era Standards Action.

Una tabla puede presentar dos casillas ocupadas y, aun así, describir una sola identidad. Esa fue la decisión deliberada de RFC 3969. Todo nombre de parámetro se registraría para URI SIP y SIPS. Sin embargo, el propio texto advertía que algunos parámetros no serían aplicables a uno de los dos esquemas. La segunda reserva impedía reutilizar el nombre; no fabricaba una segunda conducta.

El problema venía de RFC 3261. La especificación base permitía crear parámetros y valores nuevos, pero no había abierto un registro IANA para coordinarlos. Dos extensiones independientes podían escoger la misma palabra y otorgarle funciones distintas. El conflicto no tenía por qué romper la sintaxis: podía sobrevivir hasta que dos implementaciones interpretaran de modo opuesto un mensaje aparentemente válido.

Publicada en diciembre de 2004, RFC 3969 creó el registro que faltaba. La tabla inicial enumeró comp, lr, maddr, method, transport, ttl y user. La entrada comp remitía a RFC 3486; las demás, inicialmente, a RFC 3261. El registro guardaba el nombre, si las opciones pertenecían a un conjunto predefinido y las referencias normativas.

La segunda reserva era un cortafuegos semántico

Registrar el nombre en ambos esquemas evitaba que una palabra libre en SIPS recibiera un significado diferente del que ya tenía en SIP, o al revés. La decisión protegía a analizadores, equipos de operación y futuras implementaciones contra una homonimia institucionalizada. Pero la aplicabilidad no estaba en la mera ocupación de la casilla. Había que leer la RFC citada.

Esto impone una disciplina de evidencia. Una observación debe conservar esquema, nombre, fecha y conjunto completo de referencias. Una marca de “registrado para SIP/SIPS” no es una matriz de compatibilidad. RFC 5630 aclaró después el tratamiento de SIPS y sus expectativas de seguridad; RFC 3263 documentó localización de servidores y transportes. Ninguna de esas condiciones cabe en la reserva del nombre.

RFC 3969 declaró los nombres y valores registrados “palabras reservadas”. Permitía el uso local de nombres no registrados, pero advertía que una asignación posterior podía colisionar con ellos. Tampoco creó un árbol para extensiones de fabricantes. RFC 3427 había explicado que una extensión SIP podía aumentar mucho la complejidad o perjudicar la seguridad; por eso el registro exigía documentación pública sobre sintaxis, uso y semántica.

La columna de valores predefinidos tampoco era una lista exhaustiva. Cuando decía Yes, el implementador debía seguir todas las referencias. El registro SIP de IANA cita hoy RFC 3261 y RFC 7118 en transport. Esa acumulación enseña que una fila es un índice vivo, no una gramática congelada.

La política escrita no coincidía con el filtro normativo

La propia regla de admisión contenía otra separación. La sección 4.2 adoptó la categoría “Specification Required” de RFC 2434, pero enseguida exigió que el parámetro estuviera definido en una RFC de la vía de estándares. Specification Required y Standards Action asignan decisiones diferentes; no son dos nombres decorativos para el mismo proceso.

RFC 5727 corrigió la procedencia, no el pasado. Señaló que existía una contradicción causada por entender mal las categorías y afirmó que la intención era Standards Action. La página actual de IANA muestra esa regla. El marco posterior de RFC 8126 permite leer estas políticas como límites explícitos de autoridad y revisión.

Por eso no basta con una captura presente ni con una cita de 2004 aislada. El registro del RFC Editor, la consulta de erratas y el Datatracker documentan estado, correcciones y evolución. RFC 3986 aporta la arquitectura general de URI. RFC 6648 reforzó más tarde una lección vecina: ni un prefijo ni una grafía permiten deducir por sí solos madurez o estatus.

El procedimiento operativo es corto, pero no admite atajos. Primero se identifica el esquema y el nombre exactos. Después se fecha la fila, se siguen todas sus referencias y se comprueban aplicabilidad y seguridad. Por último se obtienen pruebas del software, la configuración y la transacción. Que una llamada termine bien no demuestra que el parámetro influyera; que IANA reserve el nombre no demuestra que el terminal lo procese.

RFC 3969 gastó dos posiciones para impedir dos significados. Su historia muestra por qué los sistemas maduros separan reserva, semántica, aplicabilidad, soporte y resultado, incluso cuando una tabla invita a fundirlos.

Fuentes