Skip to main content
OxiMail’s position is that a protocol extension worth shipping is worth specifying. Every extension surface the server serves under urn:oximail:params:jmap:* is being written up as an Internet-Draft intended for submission to the IETF — in the JMAP tradition where the specification and a real, deployed implementation are developed against each other.

​
The discipline

The specification programme runs on a published methodology (docs/jmap-v2-amendments-discipline.md in the server repository): every server change that touches a specified surface ends with a conformance audit against the draft text, and every divergence found is resolved explicitly — the code follows the draft, the draft is amended to match reality, or both are wrong and both change. Divergences are never left “to be sorted out later”; the draft corpus stays code-faithful by construction, which is what makes it worth submitting.

​
Domains covered

The draft corpus in progress covers, at the level of detail appropriate before submission:
  • Chat over JMAP — rooms, messages, receipts, and the capacity model, as served today.
  • Real-time calls — the session object anchored on a room, the membership lease, and the relay that carries a WebRTC handshake between participants without ever storing it.
  • Server-to-server federation — how two independent JMAP servers exchange and deposit content for each other’s users. A node is authenticated by the key its peer pinned at pairing, and requests and responses are signed with HTTP Message Signatures (RFC 9421); the earlier mtls-dane transport option is gone from the text, as it never existed in the server. A federating domain announces its endpoint under its own _jmap-federation._tcp record, distinct from the clients’ _jmap._tcp. The server implements the relayed availability read and the read-only Drive profile (FileNode/get, /query, /changes and content in signed blocks); deposit is specified, not served (federation).
  • Delivery and deposit semantics — a thin profile of the federation primitives for message deposit.
  • Document custody — retention and immutable-filing semantics built on the same deposit primitive.
  • Collection ownership transfer — moving a federated shared collection (a chat room, a shared calendar) from one server to another when the owning organization closes, merges or changes operator, so that even a live shared collection is portable rather than trapped on its host.
  • Tamper-evident audit log — the append-only, SHA-256-chained event log and its verification, separated from the policy of what a deployment chooses to log.
  • The v2 modernization surfaces — the capability families described on the JMAP v2 page.
End-to-end encryption is not part of the corpus. OxiMail does not implement it (the server reads what it stores, and at-rest protection is the volume’s, see encryption at rest), and the draft that described it was withdrawn from the published set in September 2026.

​
Status

Pre-submission. The drafts are working documents in the server repository, evolving with the implementation; the pre-submission sweep (editorial pass, amendment reconciliation, IANA considerations) is the gate before the first draft-*-00 lands in the IETF datatracker. This page will link each draft when it is submitted. Until then, the served wire is the reference: everything the drafts describe is feature-detectable from the session capabilities of a running server, and the developer pages of this site document the as-built behaviour.