Session Date/Time: 04 Nov 2025 16:30

JMAP

Summary

The JMAP session covered the status of existing JMAP drafts, discussed plans for expired drafts, and reviewed new proposals for cryptographic extensions, generic object metadata, enhanced result references, and email sharing. Key decisions included initiating calls for adoption for several new drafts and setting action items for updating existing documents and planning for interoperability testing. The working group also reviewed and updated its milestones.

Key Discussion Points

JMAP Calendars

The jmap-calendars draft was pulled back from the IESG editor queue to incorporate feedback, particularly from ongoing implementations, and to update it for consistency with js-calendar-bis.
A new version incorporating all recent changes will be published shortly.
The plan is to await two complete and tested implementations (e.g., Cyrus and Starwater) before proceeding, likely with another working group last call due to the changes.

JMAP Email Push

The jmap-mail-push draft is awaiting implementation experience.
There was a discussion regarding the need for a mechanism to group multiple push events, especially when a server needs to deliver delayed notifications. An action item was noted to update the document to address this.

File Notes

Minor changes have been made to the jmap-file-nodes draft, including adding isSubscribed and aligning ACLs with other specifications.
Discussion on "metadata support" highlighted the need for a separate, generic metadata draft (later presented by Mauro).
Hans Jürgen asked for clarification on how to handle multiple root notes (e.g., "my file store" vs. "group file store") and how clients can identify folder ownership.
Neil emphasized the need for implementation experience to ensure jmap-file-nodes can serve as a remote file adapter for systems like macOS and Windows.

Expired Drafts

S-MIME-Sender: Alexey acknowledged that he had not made progress but committed to working on it by March if reminded.
Tasks: Hans Jürgen stated that progress is planned once their implementations are updated to recent spec versions.
Essential Portability / REST: No volunteers came forward to revive these drafts.

New Work: Cryptographic Extensions (Call for Adoption)

Neil presented a proposal for jmap-cryptographic-extensions to use JS Contact for establishing and maintaining end-to-end trust across cryptographic applications (SSH, Git, code signing, email).
The draft proposes modest extensions to JS Contact to:
- Better specify key usage for different applications, moving beyond a 1990s PGP-centric view.
- Support cryptographic hygiene by separating keys across applications and uses.
- Enable secure updates of contact information (e.g., new keys, websites) via an update URI and verification mechanism.
Key use cases include email address portability and in-person contact exchange via QR codes, offering an alternative to traditional PGP key signing parties.
Robert (co-author of JS Contact) expressed willingness to guide on fitting this into the JS Contact data model but noted the need for cryptographic expertise for security assurance. He suggested initially focusing on the data model without retrofitting to V-Card.
Hans Jürgen noted the "portability" aspect for email addresses as interesting and pointed to the vacation-notice draft for potential interrelation. He also asked about supporting "previous keys" or "outdated addresses" for historical context, which could be addressed by preferences or potentially post-quantum crypto efforts.
Andy Newton (as an individual) supported the work, seeing it as a valuable building block to make JS Contact more widely usable (e.g., for RPKI) and differentiate it from V-Card.
Ben Bux sought clarification on the secure update mechanism, specifically how recipients are informed of changes (e.g., new email address). Neil explained it relies on polling an update URI, with potential for more efficient notification mechanisms in the future.
Concerns were raised about privacy (not publishing full contact info) and the need for authentication for updating contact info, to which Neil responded that multiple contact cards can be used for different audiences.
Mickey Nourine indicated interest from Open Cloud Mesh for refreshing contact information and using OpenID Connect for authentication.
Brian warned against tying update URLs to email providers to avoid vendor lock-in.

New Work: Generic Metadata Storage for Clients (Object Metadata, Enhanced Result References, JMAP Email Sharing)

Mauro presented three related drafts:
- Object Metadata: A standard way to add metadata to any JMAP object, addressing use cases like synchronization IDs, photography metadata, and vendor-specific extensions. It proposes an IANA registry for metadata types, supports private/shared metadata, and allows bridging IMAP and WebDAV metadata properties.
- Enhanced Result References: Extends JMAP core's result references to be usable in set requests (e.g., copying participants/attachments from a template) and filter operators for chaining queries. It also proposes an optional JSON Path mechanism for more powerful expressions.
- JMAP Email Sharing: A simple extension to make the Mailbox JMAP object a shareable type, consistent with JMAP Sharing.
Mail Sharing: Neil found it straightforward and useful as an underlying standard.
Enhanced Result References:
- Neil questioned the use of hash syntax for references, worrying about potential conflicts with property keys that might legitimately start with a hash (e.g., JS Contact, JS Calendar). Mauro explained it would involve looking at the value type, not just the key.
- Robert suggested addressing the hash concern by either rejecting IANA registrations for property names starting with a hash or defining allowed characters for property names in JS Contact and JS Calendar BIS.
Object Metadata:
- Neil raised concerns about how changes to metadata would interact with the /changes method (e.g., whether changing metadata on an object triggers a change notification for the parent object).
- He also expressed a general "unease" that the generic metadata approach might become an "incompatibility bucket" for arbitrary vendor extensions. Mauro clarified that servers can advertise which metadata types they support, allowing them to be strict and avoid generic annotations.
- The chair (Daniel) suggested a new name for the parentID property in metadata objects to avoid confusion with parentID in same-type hierarchies.
- Discussion was raised about whether Object Metadata could be combined with the previously discussed "Server Settings" extension or if a separate "generic object store for user-defined objects" should be considered.

Milestones Review

Several milestones were updated, including pushing back target dates for s-mime-sender, jmap-tasks, jmap-calendar-bis, jmap-icalendar, and jmap-icalendar-extensions to July 2026.
The js-contact-uid and js-contact-profiles documents were noted as ready for submission.

Decisions and Action Items

JMAP Calendars: Neil will publish a new version of jmap-calendars today. The working group will await two full implementations and likely conduct another working group last call before submitting for publication.
JMAP Email Push: Neil will update the jmap-mail-push document to include a mechanism for grouping multiple push events.
File Notes: Neil will update the jmap-file-nodes draft to clarify how multiple accounts/file stores are handled and how clients can determine ownership of folders.
S-MIME-Sender: Alexey committed to working on the draft by March, with a reminder to be sent in January.
Cryptographic Extensions: A call for adoption will be initiated for jmap-cryptographic-extensions on the mailing list.
Generic Metadata Storage: Separate calls for adoption will be initiated for jmap-object-metadata, jmap-enhanced-result-references, and jmap-mail-sharing on the mailing list.
Milestones: The working group milestones were reviewed and updated to reflect current progress and planned timelines.

Next Steps

Working group chairs will initiate calls for adoption for jmap-cryptographic-extensions, jmap-object-metadata, jmap-enhanced-result-references, and jmap-mail-sharing.
Authors will address identified issues and incorporate feedback into their respective drafts (e.g., JMAP Email Push grouping, File Notes ownership, Object Metadata naming).
Implementers will continue testing jmap-calendars to gather interoperability feedback.
Maintainers of expired drafts (s-mime-sender, jmap-tasks) will continue efforts to revive and update them.