Resumen

  • RFC 5196 permite representar en PIDF capacidades dinámicas de servicios y dispositivos para orientar al watcher antes de iniciar contacto. Esas señales no sustituyen la negociación SIP/SDP.
  • Cuando intervienen varias fuentes, el resultado compuesto debe conservar el objeto, la procedencia, la vigencia, la política de autorización y la decisión de conflicto; de otro modo, un resumen útil se convierte en una afirmación imposible de auditar.

La tercera voz de la composición

La presencia distribuida rara vez nace de un único dispositivo. El teléfono de sobremesa, el móvil, un cliente de software y un servicio de política pueden publicar datos sobre la misma persona. RFC 5196 reconoce que la combinación de fuentes puede perder información o producir una imagen que no coincide con la capacidad efectiva.

El punto merece más atención que la típica regla de precedencia. El agregador no se limita a transportar afirmaciones: crea una tercera afirmación. Una unión de características puede describir un dispositivo imaginario que reúne capacidades repartidas entre varios terminales. Una intersección puede ocultar un medio válido. La política «último valor gana» depende de qué reloj se crea, y un valor más reciente sobre un servicio no necesariamente refuta uno anterior sobre otro dispositivo.

Por eso la salida no puede conservar solamente el dato vencedor. Necesita el identificador de cada fuente, el objeto al que se refería, su momento de publicación y expiración, el watcher para el que se construyó la vista y la regla que resolvió el conflicto. Sin esos elementos, el documento final parece más seguro cuanto menos puede explicar.

Positivo, negativo y no revelado

El formato distingue una declaración positiva en supported de una negativa en notsupported. Además, desaconseja enumerar negativos irrelevantes. Si un mismo valor aparece en ambos grupos, el watcher puede asumir que está soportado. Esa decisión impide que una contradicción paralice al lector, pero no borra el hecho de que hubo dos afirmaciones.

Hay también un tercer estado: no divulgado. El presentity puede omitir una capacidad real; el propio RFC usa como ejemplo la voz. Las reglas de autorización o el servidor de presencia pueden limitar o modificar lo publicado. Un campo ausente, por tanto, no prueba que la función falte.

Este matiz es decisivo en sistemas que convierten presencia en automatización. Interpretar toda ausencia como false puede impedir una comunicación posible. Interpretar todo positivo como promesa vigente puede lanzar una comunicación imposible. RFC 5196 describe ambos riesgos y advierte que los watchers no deben esperar una correspondencia completa con la capacidad real.

El URI no decía qué servicio era

La extensión existe por una necesidad concreta. Un URI de contacto dentro de PIDF puede no explicar si el tuple representa voz, vídeo, mensajería u otra función. La vocabularia de RFC 3840 y las extensiones de capacidad ayudan al watcher a elegir. RFC 4479 aporta el modelo de persona, servicio y dispositivo; RFC 5196 añade características de servicio y de dispositivo dentro de ese marco.

Pero una decisión mejor informada sigue siendo una decisión previa al contacto. El ámbito del documento habla de indicios acerca de preferencias, voluntad y capacidades, y afirma expresamente que no reemplaza mecanismos de negociación de medios como SDP. La presencia puede sugerir a quién y cómo invitar. La oferta, la respuesta y el endpoint que contesta determinan qué medio queda acordado.

También hay un desfase temporal. Un teléfono puede apagarse, un usuario puede cambiar de cliente o una publicación puede quedar retenida. El servidor conserva una vista coherente de ayer mientras la sesión de hoy encuentra otro dispositivo. No es una paradoja: son observaciones con tiempo y alcance distintos.

Servicio y dispositivo no son intercambiables

El modelo evita otro error de agregación: propagar una propiedad a todo lo asociado con una persona. Que un servicio admita vídeo no demuestra que cada dispositivo lo haga. Que un dispositivo conozca un idioma de contenido no demuestra que una persona capaz de responder esté presente. Que un watcher vea una voluntad publicada no equivale a consentimiento para una sesión concreta.

La arquitectura operativa debe mantener esos sujetos separados. Una afirmación pertenece a un tuple, servicio o dispositivo. Una política decide qué parte revelar. Un compositor elabora una vista. El watcher toma una decisión. SIP tramita la invitación y SDP negocia. El resultado vivo pertenece a la sesión, no al documento de presencia que la precedió.

Si una plataforma reduce la secuencia a disponible, ya no puede decir qué cambió cuando el resultado difiere. El símbolo ha ocupado el lugar de los mecanismos que debía resumir.

Un recibo que conserva el desacuerdo

El registro mínimo debe identificar presentity, watcher y suscripción; tuple, servicio o dispositivo; agente de publicación; versión; tiempos de publicación y caducidad; valor exacto y estado positivo, negativo o no revelado. Debe añadir la regla de autorización, las transformaciones del servidor, todas las entradas de composición y la decisión aplicada a cada conflicto. La vista entregada merece su propia huella y hora de recepción.

Después comienza otro expediente: señal que motivó la invitación, URI objetivo, endpoint seleccionado, petición y respuesta SIP, oferta y respuesta SDP, medio negociado, voluntad humana y resultado observado. Estas piezas pueden relacionarse, pero una no sustituye a otra.

La propuesta es un control operativo, no una nueva obligación de sintaxis para RFC 5196. Sigue la regla de realidad de Heng Lu: la representación debe permanecer subordinada a lo que corre. Presencia, autorización, composición y negociación son útiles cuando ninguna pretende absorber la autoridad de las demás.

Sources

  1. RFC 5196 en HTML
  2. Texto de RFC 5196
  3. Ficha de RFC 5196
  4. IETF Datatracker: RFC 5196
  5. Historial de RFC 5196
  6. Referencias de RFC 5196
  7. Erratas de RFC 5196
  8. RFC 3840
  9. RFC 3863
  10. RFC 4479
  11. RFC 3859
  12. RFC 4566
  13. RFC 3261
  14. RFC 2778
  15. RFC 3856
  16. RFC 3903
  17. RFC 5025
  18. Heng Lu — capas de realidad y poder simbólico
  19. Heng Lu — especificación inicial mínima
  20. Heng Lu — primacía del código en ejecución