**Session Date/Time:** 17 Mar 2026 01:00

# [JMAP](../wg/jmap.html)

**IETF 125 Session Minutes**

## Summary
The JMAP working group met in a joint session with CALEXT to discuss the progression of JScalendar, JSContact, and various JMAP extensions. Key outcomes included the decision to pursue a "bis" update for vCard 4.0 to resolve long-standing errata and align with JSContact, and a technical consensus to shift the JMAP File Storage model toward a more POSIX-like mutable structure. Progress was reported on several JMAP extensions, including Mail Sharing and Metadata, with implementations currently being tested in the Stalwart and Fastmail servers.

## Key Discussion Points

### CALEXT Updates: JScalendar and JSContact
Robert Stepanek provided an update on the JScalendar and JSContact suites ([Slides: calext-jscalendar-jscontact](https://datatracker.ietf.org/meeting/125/materials/slides-125-jmap-calext-jscalendar-jscontact-00)).
*   **JScalendar:** Documents are undergoing minor tweaks to align with JSContact definitions and IANA sections. Submission to the IESG is expected before July.
*   **JSContact:** `JSContact-profiles` is now unblocked in the IESG review process. `JSContact-UID` is nearing the Auth48 stage. 
*   **RFC 9553-bis:** This document aims to align JSContact/vCard conversion with the JScalendar/iCalendar conversion patterns. Adoption is expected imminently.

### vCard 4.0-bis Proposal
Rick proposed a refresh of the vCard 4.0 specification ([Slides: vcard-4.0-bis-proposal](https://datatracker.ietf.org/meeting/125/materials/slides-125-jmap-vcard-40-bis-proposal-00)).
*   **Problem:** The current spec has 33 reported errata. Significant confusion exists regarding UID types (text vs. URI) and membership indicators, which complicates the upgrade path from vCard 3.0 and synchronization with JSContact.
*   **Discussion:** Ken and others supported the effort to clean up the specification to discourage vendors from creating non-standard vCard 3.0 extensions.
*   **Consensus:** There was strong support for adopting this work within the working group to maintain the standard.

### JMAP File Storage and Blob Extensions
Bron Gondwana presented updates on `draft-ietf-jmap-filenode` and the proposed Blobext ([Slides: filenode-blobext](https://datatracker.ietf.org/meeting/125/materials/slides-125-jmap-filenode-blobext-00)).
*   **Filenode Roles:** Bron proposed standard roles: `root`, `home`, `temp`, and `trash`. Ben suggested adding a `pictures` role.
*   **Mutablity Debate:** The current draft used immutable `blobId`, `size`, and `type`. Neil Jenkins and Ben argued that allowing these properties to change on a single FileNode ID (POSIX-like) is more efficient for clients, sharing permissions, and avoiding unnecessary round-trips for small writes (e.g., SQLite `fsync`). Bron agreed to update the draft to allow mutability.
*   **Blobext:** Discussion centered on chunked uploads and `Blob/convert` for thumbnails. While Ken questioned the historical lack of adoption for IMAP CONVERT, Bron noted that thumbnailing is a critical requirement for modern file clients.
*   **Resumable Uploads:** The group discussed leveraging the ongoing HTTP Resumable Uploads work rather than reinventing a JMAP-specific mechanism.

### JMAP Extensions: Mail Sharing, Metadata, and Refplus
Mario Loffredo provided updates on three drafts:
*   **`draft-ietf-jmap-mail-sharing`:** Implemented in Stalwart; considered stable and ready for review.
*   **`draft-ietf-jmap-metadata` and `draft-ietf-jmap-refplus`:** Mario is seeking further feedback before proceeding with full implementation. Neil Jenkins committed to reviewing the latest versions.
*   **CBOR and Compression:** Mario suggested exploring CBOR for JMAP or using Compression Dictionary Transport (RFC 9842) to optimize JSON payloads. Neil Jenkins requested benchmarks to demonstrate significant wins over standard compressed JSON before adding protocol complexity.

### JMAP Email Push
Neil Jenkins updated the group on `draft-ietf-jmap-emailpush`.
*   **Status:** The document is adopted. Mario Loffredo confirmed partial implementation in Stalwart. The next step is full end-to-end testing of payload delivery.

## Decisions and Action Items
*   **Decision:** The working group will adopt a new work item to produce a vCard 4.0-bis document (Rick to lead).
*   **Action:** Bron Gondwana to update `draft-ietf-jmap-filenode` to move away from the immutable content model to a POSIX-like model where the `blobId` can change for a stable Node ID.
*   **Action:** Hans-Joerg to refresh the expired JMAP Tasks draft and determine if checklist features are ready for inclusion.
*   **Action:** Bron Gondwana to issue a call for adoption for the JMAP Blobext draft.
*   **Action:** Alexey to review the S/MIME sender draft in coordination with Philippe.

## Next Steps
*   **WGLC:** `draft-ietf-jmap-mail-sharing` will likely proceed to Working Group Last Call soon following final reviews.
*   **Implementation:** Mario Loffredo will set up a public Stalwart instance to allow client developers to test `draft-ietf-jmap-refplus` and `draft-ietf-jmap-emailpush`.
*   **Milestones:** Bron Gondwana to update the Datatracker milestones, including shifting the `draft-ietf-jmap-filenode` submission date to June and adding Blobext milestones.