Summary

  • The 28 October JMAP Object Metadata draft, revision 05, adds a Binary value: exactly two members, @type and padded base64. A server stores and returns the valid wrapper exactly as given; malformed values fail a write.
  • The new value counts as depth zero, but its members cannot be patched or reached by a query path, and text filters never match it. Metadata quota and size controls are separate from depth. Revision 04 had no Binary section.

The label is visible. The contents are not searchable.

The draft’s own example places a 32-byte thumbprint in a vendor namespace on an object. Under revision 05, a client can ask whether that metadata path exists. It cannot ask the server’s text filter to find a particular byte string inside the thumbprint, or patch only the base64 member. The wrapper is one value, not a tiny searchable object. To replace it, a client must address the value as a whole.

That is a deliberate new line in the working-group draft. JSON strings carry text; the proposal wants room for arbitrary bytes. It therefore defines @type: "Binary" and a padded base64 string, forbids extra members, and rejects malformed encodings with invalidProperties. A path that tries to drill through the wrapper fails with invalidPatch; a text match simply finds no match. The server’s duty is exact custody, not interpretation.

The namespace owner decides what a thumbprint means. A vendor can use a lower-case domain name it controls as a namespace without first registering a name with IANA. The JMAP server decides whether vendor namespaces are supported for that object type and what storage it will accept. The broader proposal already distinguishes shared metadata, visible with access to the object, from a user’s privateMetadata. Those permission rules predate the Binary addition; they still decide who may see the sealed value at all.

Calling the wrapper depth zero creates an easy trap. Depth is a nesting limit, not a byte allowance. The draft says servers should enforce metadata quota; a server may also impose implementation-defined size limits, returning overQuota on excess. Its text-match filters are optional at the server side even for ordinary strings when implementation cost is too high. A buyer promised “searchable metadata” needs to ask which fields are strings, which are Binary, and which filters the server actually supports.

The Datatracker record lists active JMAP working-group draft status, with no RFC or implementation result. A trace that writes a valid Binary value, reads it back byte-for-byte, tests path and filter behavior, and records quota charges would settle how a specific server handles the proposal. Until then, the new jar has a precise seal and no proven shelf.

Sources: revision 05; revision 04; IETF status.