> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oximail.ch/llms.txt
> Use this file to discover all available pages before exploring further.

# IETF drafts

> The standardization programme: OxiMail's JMAP extensions are specified as Internet-Drafts intended for IETF submission, developed against the running implementation.

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.
* **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 collection between accounts as a first-class operation.
* **The v2 modernization surfaces** — the capability families described on the [JMAP v2 page](../developer/jmap-v2).

## 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](../developer/jmap-core) of a running server, and the developer pages of this site document the as-built behaviour.