Resumen

  • RFC 8620 entrega una cadena state que representa todos los datos de un tipo dentro de una cuenta; si cambia, el cliente debe reconciliar su caché.
  • StateChange anuncia qué estados de cuenta y tipo cambiaron. No contiene de forma independiente el actor, los valores anteriores y posteriores, la razón, el orden probatorio ni una conclusión sobre un buzón.

La señal que pide otra consulta

Neil Jenkins y Chris Newman diseñaron en RFC 8620 un mecanismo para que una aplicación no tenga que descargar continuamente un conjunto completo de datos. La respuesta Foo/get puede incluir una cadena breve que representa el estado del tipo de datos en la cuenta. Si los datos cambian, la cadena debe cambiar. Cuando sigue igual, el servidor debería devolver la misma cadena en solicitudes posteriores.

La consecuencia correcta no es adivinar el detalle a partir del valor. RFC 8620 indica que el cliente debe descartar sus objetos en caché o solicitar Foo/changes para obtener los cambios exactos. El estado abarca todos los datos del tipo, no solo los objetos de la respuesta concreta. Es un límite de coherencia de caché.

Por ello, una cadena diferente no es una bitácora de hechos. No identifica el principal que inició una modificación, la política que la permitió, la representación previa, la representación final, el motivo ni una secuencia de tiempo protegida. Puede avisar de que algo requiere reconciliación; no reemplaza los registros que pertenecen a quienes ejecutaron, autorizaron u observaron el hecho relevante.

La lista de cambios tampoco es toda la historia

En /changes, el cliente envía sinceState y el servidor responde con oldState, newState y, cuando corresponde, identificadores creados, actualizados o destruidos. Es la pieza adecuada para hacer converger una vista local.

Sin embargo, una lista de identificadores sigue teniendo una finalidad de sincronización. Una auditoría de buzón puede requerir la identidad autenticada, una solicitud correlacionada, la decisión de autorización, campos antes y después, semántica de tiempo y orden, controles de integridad y una política de retención. Un proveedor puede construir esos elementos alrededor de JMAP; no debe atribuirlos a una cadena de estado que no los expresa.

La diferencia importa cuando un panel muestra actividad de Email o Mailbox. Decir que el cliente debe recuperar diferencias puede estar respaldado. Afirmar quién cambió una carpeta o qué experiencia tuvo un usuario exige otra cadena de evidencia. La precisión protege tanto al operador como al lector del panel.

Varios cambios caben en un aviso

El objeto StateChange mapea cuentas a los estados de tipos de datos que han cambiado desde el aviso anterior. El cliente compara cada cadena con su valor local y solicita cambios si hace falta. El ejemplo del RFC permite al servidor amalgamar varias modificaciones de dos cuentas en un único push.

La amalgama es una ventaja de eficiencia y una frontera de significado. Un aviso no equivale necesariamente a un evento individual. No prueba que existiera una única solicitud, un único usuario, un único mensaje ni una cronología exhaustiva. Convertirlo en una afirmación de auditoría elimina precisamente la compresión que hace útil al mecanismo.

Pregunta Evidencia JMAP pertinente Evidencia que falta
¿Está actualizada la caché? La cadena state coincide Ninguna para esa pregunta limitada
¿Qué debe recuperar el cliente? /changes y sus identificadores Contenido de los objetos cuando importe
¿Quién ejecutó un cambio? No lo establece StateChange Principal, petición y autorización
¿Cuál fue el resultado para un destinatario? No lo establece el estado genérico Observación en la frontera de entrega o lectura

El aporte arquitectónico asociado a Jenkins es valioso por su modestia: permite detectar divergencia y restaurar la coherencia. Una operación madura conserva esa prueba para ese propósito y conserva una bitácora separada para las afirmaciones que requieren responsabilidad.

Fuentes