Summary

  • RFC 8620 gives a JMAP client a state string for all data of one type in an account; a difference tells the client to discard its cache or request the exact changes.
  • A StateChange push tells a client which account/data-type states have moved. It does not independently preserve an actor, object-level before/after values, cause, event order, retention guarantee, or mailbox outcome.

The notification that asks for another request

Neil Jenkins and Chris Newman’s RFC 8620 solves a practical synchronization problem. A mobile or web client cannot continually download every record from a large server just to discover whether its cached copy is stale. The protocol therefore attaches a short state string to a data type in an account. If the server’s data changes, the string must change. If it has not changed, the server should normally return the same string.

That is a useful boundary. The state belongs to all data of the relevant type in the account, not merely to the objects returned in one Foo/get response. A client that sees a different value is not licensed to guess at the contents of the difference. RFC 8620 instructs it either to discard the cached objects of that type or to call Foo/changes to retrieve the exact changes.

The protocol is deliberately economical. A small token makes it possible to decide whether synchronization work is required without shipping a large data set in every response. It does not turn the token into an explanation of the work that occurred. A changed value says that the previous cached representation is no longer current. It does not state an author, motive, approval, command path, message identifier, field delta, or a result at a human or recipient boundary.

State is a cache boundary, not an audit boundary

The distinction becomes clearer when the state string is placed beside the /changes method. The client supplies sinceState, the state it previously received. The server returns oldState and newState and can enumerate created, updated, and destroyed identifiers. That exchange is designed to reconcile a cache.

Even this more detailed exchange is not automatically a complete audit. Identifier lists are not a statement of who caused an update, which authorized request was accepted, which values changed, why a rule applied, whether concurrent events were ordered for a compliance purpose, or how long the record will remain intact. Those are separate properties of an audit system. A service may choose to retain them, bind them to an identity system, protect them against alteration and make them reviewable. RFC 8620’s synchronization contract does not itself assert that it has done so.

For a mailbox, the temptation is especially strong. An operator sees a different Email or Mailbox state and writes that a mailbox was changed. The modest version may be true: the server reports a different state for that data type. The larger version needs an evidence chain that names the relevant account, object, old and new values, action source, authorization context, time semantics and observation point. Without that chain, a state transition is a prompt to retrieve information, not the information itself.

A push can combine several changes

RFC 8620’s StateChange object makes the same design explicit for push. The object maps an account identifier to the data-type states that have changed since the prior push. A client compares those values with its own and fetches changes where it is no longer current. The RFC’s example allows the server to amalgamate several changes across two accounts before it sends a single StateChange object.

That is exactly what a synchronization client needs. It avoids polling and keeps a device from treating every remote change as a separate full reload. It also supplies a clear warning against over-reading the notification. One StateChange may be a compressed indication that multiple server-side changes have accumulated. It is not necessarily one event, one request, one user, one message, one mailbox action, or one ordered event ledger.

This is not a flaw in JMAP. Compression is a feature when the receiver’s job is to converge a cache. The error begins when a monitoring dashboard gives the compressed signal an audit label. A green delivery indicator, a changed counter, or a fresh state value can be useful operational telemetry. None should silently acquire facts that the observed field does not carry.

The evidence stack for a serious mailbox claim

Different questions require records from different owners. A client synchronization question can be answered with a state value and, where necessary, a /changes response. A question about an object can require the relevant object identifier and before/after representation. A question about a privileged modification can require the authenticated principal, authorization decision, request correlation, server decision and durable time/order record. A question about downstream delivery or reader experience needs evidence at that later boundary.

Question Useful JMAP evidence Additional evidence needed
Is this cache current? Matching state string None for the narrow cache question
Which records must a client reconcile? /changes identifiers and returned state Object contents if the difference matters
Who made a mailbox modification? Not established by StateChange alone Authenticated principal, request and authorization record
What values changed and in what order? Not fully established by a state string Before/after values, event time/order and durable audit controls
Did a recipient or user experience a result? Not established by generic sync state Delivery, mailbox, recipient or user-boundary observation

The table does not impose a new requirement on RFC 8620. It keeps claims attached to the system that can support them. That is the running-code discipline: a protocol signal should be credited for the job it performs, while consequential claims remain tied to the operational evidence that actually observes them.

Neil Jenkins’s bounded contribution

The public RFC records name Neil Jenkins and Chris Newman as the authors of RFC 8620. The specification is a collective IETF Standards Track document, not a claim that either person runs a particular mail service or owns a particular customer outcome. The relevant contribution here is architectural: a client can cheaply detect that its cached account data has moved, then use standard methods to converge its view.

That architecture is valuable because it does not pretend to be more than it is. A cache token can trigger investigation without foreclosing it. A StateChange can wake a client without deciding the story of a mailbox. Good operations preserve that modesty. They retain sync evidence for synchronization, and they retain audit evidence for audit.

Sources