Resumen

  • RFC 5341 coordina nombres de parámetros y referencias permanentes; no certifica que un consumidor implemente la extensión ni que un valor concreto sea válido.
  • Registro, especificación, sintaxis, capacidad, política, encaminamiento, identidad y resultado necesitan recibos distintos.

La tabla llegó antes que el software

Un gateway recibe un URI con un parámetro que figura en IANA. Su filtro de admisión lo acepta por esa sola razón. El motor de señalización usa una versión anterior, desconoce el parámetro obligatorio y continúa como si nada hubiera ocurrido. La cadena convirtió la coordinación del nombre en una declaración falsa de capacidad.

RFC 5341 pide nombre, clase de valores y especificación pública para registrar una extensión. Así evita que dos comunidades usen el mismo término con significados incompatibles. La entrada dice dónde vive la semántica. No despliega código en los receptores.

RFC 3966 obliga a no usar un URI cuando contiene un parámetro obligatorio desconocido. Por eso la capacidad no puede inferirse de IANA. Debe observarse qué parser y versión reconoció el nombre, qué reglas aplicó y si rechazó o continuó.

La referencia contiene las reglas que la fila resume

La columna Constrained no enumera todas las formas aceptables. Remite a la especificación. Un valor puede usar un nombre registrado y violar longitud, alfabeto, contexto o comparación. También puede ser sintácticamente legal y operacionalmente obsoleto.

No Value tampoco significa sin efecto. Puede describir un flag como enumdi o npdi, o la ausencia de un conjunto predefinido. La presencia del flag comunica una afirmación definida en otro RFC. No autentica quién la hizo ni demuestra que el estado afirmado sea actual.

Un validador serio sigue la referencia y conserva el resultado por parámetro. Un simple booleano registered=true sólo responde a la colisión de namespace. Si controla admisión, ruta o fraude, está usando una evidencia demasiado pequeña.

Un tel URI no es la llamada

RFC 3966 describe un identificador basado en número telefónico. No indica los pasos para alcanzarlo, no impone cómo marcarlo y no designa un dispositivo físico concreto. El marcador convierte el identificador en secuencia según red y terminal.

Tampoco elige voz, fax o datos. Esos parámetros y capacidades se negocian por otros mecanismos. La presencia de extensiones registradas no convierte el URI en comprobante de medio o conexión.

Para un número local, phone-context define alcance. El campo puede estar bien formado y aun así diferir entre organizaciones, ser mal configurado o no conducir a una ruta. Declarar contexto no demuestra acuerdo.

El servicio base debe sobrevivir a la extensión

RFC 5341 protege la interoperabilidad al exigir que el servicio siga invocable y opere normalmente cuando estos parámetros faltan. Una extensión puede refinar, pero no apropiarse de la existencia del servicio.

En la práctica, un proveedor puede decidir que cierta extensión sea obligatoria para su producto. Esa es una política local que necesita versión, contrato y monitorización. Atribuirla al registro oculta quién tomó la decisión y dificulta cambiar de proveedor.

La ausencia también merece pruebas. Hay que ensayar llamadas sin el parámetro, con parámetro desconocido opcional, con obligatorio desconocido y con valor inválido. Sólo así se distingue la compatibilidad del comportamiento permisivo.

El presente no reescribe la tabla histórica

El registro IANA vivo contiene parámetros iniciales y adiciones posteriores como premium-rate y verstat. Un inventario codificado en 2008 no representa la autoridad actual. Pero la tabla de 2026 tampoco describe automáticamente lo que entendía un producto de 2012.

La auditoría debe congelar fecha, contenido del registro y referencia utilizada. Cuando cambia una entrada, los eventos antiguos conservan el contexto que tenían. Sin ese recibo temporal, una revisión puede declarar retrospectivamente soportado un nombre que entonces era desconocido.

Portabilidad y trunks requieren procedencia

Los parámetros de RFC 4694 expresan información de portabilidad y encaminamiento; los de RFC 4904 describen grupos de trunks y contexto. IANA les da nombres coordinados. No prueba que el rn sea vigente, que el cic esté autorizado, que el grupo exista ni que el siguiente salto lo acepte.

Cada dato necesita emisor, frontera de confianza, instante y consumidor. Después hacen falta recibos de decisión y señalización. Lo mismo vale para enumdi e isub-encoding: definición pública no equivale a historia verificada ni interoperabilidad real.

Fuentes y límite probatorio

Las fuentes demuestran normas, historia documental y un estado del registro IANA. No demuestran llamada actual, dueño del número, identidad, producto, despliegue, ruta, precio ni resultado.