Resumen

  • RFC 5264 usa publicaciones parciales para modificar una publicación completa identificada mediante etiquetas de entidad. Si su vida útil vence sin renovación, se elimina todo ese estado publicado, no únicamente la última diferencia.
  • La trazabilidad necesita la cadena de SIP-ETag, los hashes completos antes y después, el plazo, la renovación o retirada y la contribución resultante al estado compuesto.

El incidente parecía una reversión y no lo era

Un terminal había publicado disponibilidad, actividad y medios de contacto. Durante una hora envió pequeños cambios: abrió un servicio, sustituyó una nota y retiró una actividad. Todas las respuestas fueron satisfactorias.

Después faltó una renovación. El estado aportado por ese terminal desapareció del compositor. Al mirar solo los últimos mensajes, alguien podría concluir que caducó el cambio más reciente y que el sistema volvió a la versión anterior. Esa explicación sería incompatible con el mecanismo.

No había una escalera de parches que el protocolo obligara a bajar. Había una publicación de estado blando cuyo resultado actual incorporaba todos los cambios aceptados. Lo que venció fue esa publicación.

El estado blando tiene un solo reloj

PUBLISH, definido en RFC 3903, crea estado con una duración negociada. Una renovación conserva la publicación; una modificación cambia su contenido; una retirada con plazo cero la elimina. RFC 5264 conserva esa gramática y añade una forma más eficiente de llevar el cuerpo.

Por eso el primer uso de application/pidf-diff+xml contiene pidf-full: hay que establecer una base completa. Las modificaciones posteriores pueden llevar pidf-diff o un nuevo pidf-full.

El reloj no se divide entre los elementos tocados. El compositor administra la vida de la publicación identificada. La diferencia reduce bytes; no crea micropublicaciones con plazos independientes.

La precondición mantiene el orden sin un segundo contador

Cada PUBLISH aceptado devuelve un nuevo SIP-ETag. Para modificar, renovar o retirar una publicación existente, el agente envía SIP-If-Match con la etiqueta que recibió anteriormente.

El formato PIDF parcial también dispone de un atributo de versión. RFC 5264 decide no usarlo para el orden de publicación, porque dos relojes podrían discrepar y dejar una condición de error sin definición. La cadena causal queda en las etiquetas y las solicitudes condicionales.

Una auditoría que guarde el XML pero pierda las etiquetas omite la mitad del hecho. Puede mostrar qué operación se intentó, pero no contra qué estado, si la precondición era vigente ni qué identidad devolvió el compositor.

El parche deja de existir como unidad histórica

Los elementos add, replace y remove se ejecutan secuencialmente sobre el documento almacenado. El resultado se entrega a la lógica de composición igual que un estado completo ordinario.

El compositor no tiene obligación de conservar los parches aplicados. RFC 5264 lo dice para explicar por qué la caducidad no provoca una vuelta a la versión anterior. Restaurar un estado exige presentar un documento completo nuevo.

Esta elección es coherente con el objetivo: ahorrar ancho de banda, no construir un repositorio histórico. Exigir al mecanismo una genealogía reversible inventaría una propiedad que nunca prometió.

Una ausencia pequeña puede tener un efecto grande

Una renovación puede llegar sin cuerpo. Su trabajo es prolongar la vida de la publicación existente. Si no llega a tiempo, se borra el estado completo que ya resultaba de todos los deltas.

La asimetría es relevante para operaciones. El último delta puede ocupar cientos de bytes y la publicación acumulada decenas de kilobytes. El tamaño del mensaje más reciente no mide el alcance de la expiración.

También existe la situación inversa: un cambio pequeño puede persistir durante muchas renovaciones porque ya forma parte del documento completo actual. Su duración no se deriva de cuándo apareció el parche, sino de la continuidad de la publicación.

El límite exacto es la publicación individual

RFC 3903 permite que varios agentes publiquen estado para un mismo recurso. El compositor genera una vista agregada con las publicaciones activas y puede añadir estado duro configurado que no caduca.

Por tanto, “se borra el estado completo” significa el estado completo de la publicación que venció. No significa necesariamente que el recurso quede sin presencia, que se borren los demás agentes o que desaparezca el estado duro.

El informe correcto enumera la publicación retirada, las que sobrevivieron y el hash del compuesto antes y después. La precisión evita tanto minimizar como dramatizar el alcance.

Rechazar una transición no equivale a expirar después

Si un pidf-diff intenta iniciar una publicación sin base completa, el compositor debe rechazarlo. Los errores al procesar el documento producen 400 y pueden traer diagnósticos. Otros fallos antes de terminar toda la operación producen 500 y obligan a recuperar el estado local anterior.

En esos casos la transición no llegó a convertirse en estado vigente. La restauración protege la atomicidad del intento. La expiración ocurre más tarde, sobre una publicación ya aceptada, y tiene la semántica distinta de eliminación completa.

Registrar solo “falló” borra esta diferencia. Hay que saber si se rechazó un intento, si se confirmó una modificación o si expiró el objeto de estado blando.

Recibo de vida y estado

Un recibo útil conserva:

  • recurso, evento, publicador, presentity e identidad de publicación;
  • SIP-If-Match, etiqueta previa y nueva SIP-ETag;
  • tipo de cuerpo, bytes, hash y hora de recepción;
  • resultado ordenado de cada operación de parche;
  • hash completo local antes y después;
  • plazo solicitado, concedido y efectivo;
  • margen, solicitud y respuesta de cada renovación;
  • retirada explícita o expiración natural;
  • otras publicaciones y estado duro que siguieron activos;
  • hash compuesto, versión de política y notificación posterior; y
  • decisión automática, visualización o respuesta humana posterior.

Este registro no atribuye al protocolo más autoridad de la que tiene. La etiqueta demuestra orden condicional. El commit demuestra estado local. El compuesto demuestra una salida del compositor. La recepción y el efecto humano pertenecen a capas posteriores.

Sources