Module patch 

RFC 8620 §5.3 PatchObject — the typed wire-format wrapper for JMAP */set update argument values.

PatchObject is a string-keyed JSON map where:

• Keys are RFC 6901 JSON Pointers with an implicit leading / (i.e. the wire form is "alerts/1/offset", evaluated as "/alerts/1/offset" for the JSON Pointer algorithm).
• A null leaf value either restores a default value (if the property has a spec-defined default) or removes that property from the object.
• Any other leaf value replaces or adds the value at that path.

The type is intentionally a thin newtype around serde_json::Map<String, serde_json::Value> with #[serde(transparent)], so the wire format is byte-identical to a bare JSON object. The newtype exists to bind the RFC 8620 §5.3 contract to the type system: when a function signature carries PatchObject, every reader knows the contained map is a JMAP patch (with JSON Pointer key semantics and the null-leaf removal rule), not arbitrary JSON.

Path-syntax validation is the handler’s job

Per RFC 8620 §5.3, path violations (paths that traverse arrays, paths whose parent does not yet exist on the patched object, paths that prefix another patch in the same PatchObject) MUST be rejected by the server with an invalidPatch error. This crate intentionally does not perform that validation: the wire-format type is value-agnostic, and the meaning of each path is method-specific (e.g. Email/set patches mean something different from Mailbox/set patches). Validation lives in the method handler that knows the target object’s schema.

Future adoption

crate::SetObject::Patch is currently typed as serde::Serialize + serde::de::DeserializeOwned, which downstream crates fill with serde_json::Value. Migrating those impls to use PatchObject is a separate, opt-in refactor (see bd JMAP-o7cj follow-ups) and does not change the wire format.

Structs

PatchObject

A JMAP PatchObject (RFC 8620 §5.3) — a String → JSON map describing the changes to apply to a record during */set update.