Resumen

  • RFC 5367 permite crear una suscripción a una lista plana de recursos incluyendo esa lista en el SUBSCRIBE inicial, exigiendo recipient-list-subscribe y recibiendo estados de los recursos mediante notificaciones compatibles con rlmi+xml.
  • El código de respuesta al SUBSCRIBE no informa si el servidor logró suscribirse a cada URI. Un diálogo puede existir mientras los recursos muestran éxito, rechazo o incertidumbre diferentes; la evidencia constituyente llega por las notificaciones.
  • La dirección debe preservar la cardinalidad: principal autenticado, lista canónica, permisos de destino, diálogo, URI de continuación, posición de cada recurso, versión y frescura de NOTIFY, capacidad de gestión, expiración y borrado son recibos distintos.

El diálogo era el contenedor, no el resultado

La eficiencia de RFC 5367 empieza con una reducción visible. En lugar de abrir un diálogo SIP por cada recurso, el agente de usuario envía una sola solicitud SUBSCRIBE al servidor de listas. Una parte con disposición recipient-list contiene la lista, y Require declara recipient-list-subscribe.

El cliente también anuncia que entiende rlmi+xml. Esta elección revela la arquitectura: la respuesta inicial gestiona la relación con el servidor, mientras una representación diseñada para listas informa después sobre sus miembros.

El servidor puede aceptar la solicitud y establecer el diálogo antes de saber o demostrar el resultado de cada suscripción downstream. RFC 5367 lo dice de forma directa: el código de respuesta no da información sobre si pudo suscribirse correctamente a las URI incluidas.

Por eso «diálogo activo» y «tres recursos activos» no son dos frases equivalentes. La primera tiene un sujeto y una observación; la segunda necesita tres posiciones y evidencia que todavía puede no existir.

Una notificación debía conservar tres posiciones

RFC 4662 define el marco de notificación de eventos para listas. rlmi+xml permite identificar recursos dentro de una notificación y relacionar su estado con el diálogo agregado.

La lista canónica fija el denominador. Si el documento inicial produjo tres URI efectivas, el sistema necesita tres posiciones incluso cuando una no aparece en el último evento. Reducir el denominador a lo que el NOTIFY menciona convierte ausencia en éxito invisible.

Cada posición necesita identidad, estado, versión, instante de observación y finalización. «Pendiente» puede ser una realidad válida; «desconocido» puede ser lo único honesto después de una pérdida de mensajes. Ninguno debe traducirse en verde por comodidad.

El orden y la versión también importan. Una notificación posterior puede actualizar sólo una posición o reemplazar una vista anterior según el contrato. Sin secuencia y cobertura declarada, dos mensajes correctos pueden reconstruirse en un estado imposible.

La aceptación no heredó las observaciones futuras

El primer código SIP prueba que el servidor de listas trató la solicitud de una manera concreta. No puede probar rutas todavía no intentadas, autorizaciones todavía no evaluadas o estados que cambiarán después.

Esto no vuelve débil la respuesta. La vuelve precisa. El error nace cuando el producto renombra «aceptado por el servidor» como «suscrito» sin objeto, y luego como «todos observados» sin nueva evidencia.

Una interfaz útil puede mostrar ambos niveles: diálogo establecido y cobertura constituyente. El primero responde si existe la relación agregada. El segundo muestra cuántos recursos tienen estado reciente, cuántos fallaron y cuántos permanecen desconocidos.

Los reintentos deben seguir esa separación. Rehacer toda la suscripción por una sola posición ambigua puede perturbar las correctas. El servidor necesita identificar el intento y la historia de cada recurso detrás del diálogo.

La lista sirvió para crear, no para cada renovación

Tras establecer el diálogo, el UAC puede enviar nuevos SUBSCRIBE para ampliar su duración. RFC 5367 no define significado para un cuerpo de lista en esas solicitudes posteriores.

El cliente debería omitirlo. El servidor que recibe uno responde 415 Unsupported Media Type. El mismo XML que fue autoridad de creación deja de ser una instrucción válida en mantenimiento.

La regla evita que una renovación se convierta en mutación encubierta. Si conservar el diálogo bastara para sustituir la lista, una credencial de mantenimiento también concedería poder para ampliar a quién se observa.

Una extensión futura podría crear otra semántica. Hasta entonces, no interpretar es una decisión de seguridad. El sistema debe registrar que vio el cuerpo, que la fase no lo permitía y que lo rechazó.

La URI pública cedió paso a una URI del diálogo

La solicitud inicial se dirige a la URI pública del recurso de lista. Las posteriores se envían a la URI que el servidor proporciona al establecer el diálogo.

Desde la perspectiva del cliente, la primera admite cuerpos recipient-list; la segunda no. Pertenecer al mismo proceso de negocio no las convierte en alias de autorización.

El registro debe enlazar URI pública, principal, hash de lista, identificadores de diálogo y URI de continuación. Así se puede explicar de dónde surgió la capacidad de renovar y por qué no incluye autoridad para recrear el conjunto.

Una petición enviada al destino equivocado puede ser sintácticamente válida y aun así actuar sobre otra superficie. Observar sólo el método SUBSCRIBE oculta esta diferencia.

El formato general contenía más de lo necesario

RFC 4826 permite listas jerárquicas y entry-ref. RFC 5367 usa ese formato como predeterminado, pero el servicio sólo requiere una lista plana. El cliente debería evitar jerarquía y referencias, y el servidor puede descartar información adicional.

Validez de esquema y significado ejecutado no son lo mismo. Un documento revisado por una persona puede expresar agrupación o referencia que el servicio no promete mantener.

El recibo debe conservar bytes originales, perfil admitido, elementos descartados, algoritmo de normalización y conjunto plano. El hash del archivo prueba custodia del documento; el hash del conjunto prueba qué recursos se interpretaron.

Esta reducción mantiene extensible el formato sin permitir que características no soportadas adquieran autoridad accidental.

La gestión de lista era otra capacidad

El servidor puede incluir en el NOTIFY inicial un Call-Info con purpose=list-management. La URI permite manipular la lista asociada a la suscripción.

Que el enlace exista no significa que una modificación se haya hecho ni que cualquier poseedor pueda hacerla. El servicio de gestión debe autenticar, autorizar, validar y registrar sus propias operaciones.

La URI pública crea; la URI del diálogo mantiene; la URI de gestión modifica. Una aplicación puede mostrarlas juntas, pero no debe usar la autorización de una como prueba para las otras.

También debe retirar o invalidar la capacidad cuando termina la suscripción. Un marcador guardado en una consola no debería sobrevivir como puerta lateral hacia una lista que ya perdió su finalidad.

El final del diálogo marcaba el final esperado de la lista

La vida de una lista manipulable está ligada a la suscripción. Debería destruirse cuando la suscripción expira o termina por otra causa.

Esa obligación impide convertir una lista temporal en inventario permanente. Sin embargo, Expires igual a cero no es por sí solo un recibo físico de eliminación.

Puede haber cachés, réplicas, índices y copias de auditoría. La organización necesita declarar qué se destruye, qué excepción retiene, durante cuánto tiempo y con qué evento observable se completa.

La conclusión correcta no es abandonar la regla porque el almacenamiento sea complejo. Es separar terminación protocolaria, revocación de capacidad, eliminación primaria y limpieza de derivados.

Un cliente legítimo aún necesitaba permiso de destino

La RFC hereda las consideraciones de seguridad de RFC 4662 y RFC 5363. El servidor autentica y autoriza al cliente; la protección de servicios de listas incluye opt-in para los destinatarios afectados.

La identidad del suscriptor explica quién pidió observar. No explica por qué cada recurso aceptó ese event package, propósito y duración.

Una decisión sólida vincula principal, servicio, evento, URI canónica, finalidad, tiempo y permiso. Un rol genérico no debe autorizar listas arbitrarias.

Los rechazos y las omisiones también requieren causa. Sin ella, una posición vacía puede interpretarse como fallo técnico cuando en realidad fue una protección deliberada.

El registro estandarizó palabras, no cobertura

IANA registra recipient-list-subscribe y list-management. Eso permite que clientes y servidores reconozcan una opción y el propósito de un enlace.

La presencia del option-tag prueba una declaración de capacidad, no la ejecución de cada suscripción. El purpose explica el tipo de URI, no demuestra autorización actual, mutación ni borrado.

RFC 5367 se publicó en octubre de 2008 como Standards Track y actualizó RFC 3265 para permitir Call-Info en NOTIFY. RFC 6665 volvió obsoleta a RFC 3265. Una implementación actual debe seguir esa evolución sin perder la separación entre fases.

Las notas de Lu Heng sirven como lentes declaradas. Minimum Initial Specification explica por qué el contrato base no debe inventar semántica de mutación para renovaciones. Reality Layers recuerda que respuesta, NOTIFY, URI y temporizador son símbolos distintos de la realidad operativa que afirman. Las fuentes de hechos siguen siendo las RFC y el registro IANA.