Resumen

  • RFC 5262 ordena estados completos y deltas, y permite detectar una actualización perdida; la garantía pertenece a un flujo dirigido a un observador concreto.
  • La evidencia debe unir base, versiones, diffs, observador, autorización, reconstrucción y caducidad, manteniendo aparte el intento de contacto y su resultado.

El número siguiente llegó, pero al estado equivocado

Un cliente reanudó una suscripción desde una copia completa guardada horas antes. A partir de ahí recibió todos los deltas en orden. El contador era impecable y cada operación XML tuvo éxito. Sin embargo, la base pertenecía a otro contexto de autorización.

El sistema había construido con precisión una historia que no debía mezclar. La continuidad posterior no corrigió la identidad inicial.

La enseñanza no es que el contador falle. Es que responde a una pregunta más pequeña: si esta cadena conservó sus pasos. La identidad del flujo y la legitimidad de la base siguen siendo condiciones externas.

Un contador cubre lo completo y lo parcial

El formato application/pidf-diff+xml admite raíces pidf-full y pidf-diff. La primera establece la composición local; la segunda aplica add, replace y remove mediante el marco XML Patch.

Cuando se usa version, aumenta de uno en uno. El mismo contador continúa aunque el emisor cambie de diff a documento completo. Así se pueden ordenar entregas y descubrir una ausencia.

No se comprueba con ello la exactitud del contenido, la totalidad de lo que conoce el presentity ni la cercanía entre publicación y realidad. Una secuencia puede ser completa y estar envejecida.

La base debe tener identidad, no solo número

Para aceptar 568 después de 567 hay que saber que ambos pertenecen al mismo presentity, observador, diálogo, política y flujo. El número sin esos vínculos es una coordenada reutilizable.

El recibo debe retener bytes y hash de la base, URI del presentity, identidad del watcher, suscripción, tipo de contenido, charset y versión de política. Si no, una sustitución de base puede parecer una reanudación normal.

La ausencia puede ser una decisión de autorización

La presencia puede contener datos sensibles. La política circundante decide qué se muestra a quién y cuándo. Por eso, un campo ausente no permite distinguir entre “falso” y “no revelado”.

El contador ordena la proyección permitida. No atraviesa la política para descubrir datos retenidos. Dos observadores pueden recibir secuencias diferentes y ambas ser correctas dentro de sus permisos.

La comparación solo es válida si la organización ha demostrado que las dos vistas comparten alcance y espacio de versiones.

Detectar la pérdida no demuestra la recuperación

Esperar 569 y recibir 570 crea evidencia de un hueco. No crea una base reparada. La aplicación todavía debe decidir si congela la vista, pide un pidf-full, descarta intermedios o funciona con degradación explícita.

Una recuperación verificable conserva el primer número inesperado, el rango perdido, el último hash fiable, la nueva base y el momento en que sustituyó a la anterior. Que la alarma desaparezca no basta.

Negociar, recibir, aplicar y mostrar no son lo mismo

Los sistemas SIMPLE negocian el tipo de contenido con los mecanismos de notificación parcial. Esa negociación demuestra compatibilidad. Un diff concreto aún puede no llegar, fallar al seleccionar un nodo, no persistirse o no alcanzar la pantalla.

Cada transición merece su recibo: llegada, aplicación ordenada, hash reconstruido, almacenamiento y exposición. Sin esa cadena, “versión recibida” se convierte indebidamente en “estado operativo”.

XML válido no equivale a disponibilidad humana

El documento debe estar bien formado y debería ser válido. Aun así, un terminal puede desconectarse, una persona puede cambiar de intención y una sesión puede fracasar después.

La afirmación defendible es “este observador reconstruyó el último estado que recibió”. Decir “la persona estaba disponible” exige evidencia del intento posterior y de su desenlace.

El recibo de presencia parcial

Conserve:

  • presentity, watcher, suscripción, diálogo e identidad de flujo;
  • política de autorización, versión, decisión y campos permitidos;
  • tipo de contenido y charset aceptados;
  • bytes, hash, versión, recepción y caducidad de la base completa;
  • bytes, hash, versión, orden y hora de cada diff;
  • versión esperada, recibida y huecos;
  • operación, selector, preimagen y resultado del patch;
  • hashes intermedios y documento reconstruido;
  • petición de recuperación, nueva base e intermedios descartados;
  • confirmación de almacenamiento y vista expuesta;
  • intento de contacto, negociación, entrega y resultado humano o de servicio.

El recibo no convierte presencia en certeza. Impide que la continuidad de un flujo suplante la verdad completa de la institución.

Sources