Session Date/Time: 09 Nov 2021 12:00

jmap

Summary

The jmap working group meeting at IETF 112 covered a wide range of topics, including updates on JMAP Blob, S/MIME for both received and sending mail, JMAP Calendars and Tasks, JSContact, and an IMAP extension for efficient searching and fetching in large mailboxes. Key discussions revolved around refining existing specifications based on feedback, addressing extensibility, and exploring new features. Decisions were made regarding certain properties in JMAP Blob and S/MIME, while several action items were assigned for further research, specification refinement, and community engagement. Milestone dates for various drafts were also reviewed and updated.

Key Discussion Points

JMAP Blob

Encodings: Discussion around specifying encodings for binary data.
- Base64: Need for explicit reference to RFC 4648, currently assumed.
- Hex: Questioned if asHex is needed. If kept, should it enforce lowercase or align with RFC 4648's case-insensitivity.
- Base32: Questioned if it should be included for completeness, despite no current use case.
expires Property: The expires property was included in examples (e.g., blob persists for a week) but lacked formal definition or assumptions. Considered if it should be removed.

JMAP S/MIME (Received Mail)

Recent Changes: Extensive changes since the last meeting, primarily addressing Gen-Art and Art Directorate comments, improving formatting, clarifying the implicit trust model, enhancing security considerations, and refining S/MIME status attribute extensibility.
Caching Time: The cacheTime for S/MIME verification (currently 10 minutes) was discussed. The trade-off between DoS protection and quick revocation propagation was considered. A day was suggested as a reasonable default, especially given infrequent certificate expiration and the cost of checking CRLs.
S/MIME Status Extensibility: Discussed if an IANA registry is needed for future sMimeStatus values (e.g., encrypted+signedVerified). Given that JMAP relies on capabilities for extensions, the consensus was to define current values and allow future extensions to introduce their own via capabilities, avoiding a sparsely populated registry.
Email/query for S/MIME Status: Proposed extending Email/query to search for S/MIME status at the time of delivery, similar to what Email/get already provides. This would allow clients to filter messages based on their validity at delivery without re-verification.
signed Attribute: The signed attribute provides an optimization to indicate syntactic presence of an S/MIME signature without full verification. Clarification was sought on its interaction with sMimeStatusAtDelivery and how status is calculated/cached. The server-set nature of sMimeStatusAtDelivery implies it can change.
sMimeStatusAtDelivery Immutability: Discussed implications of sMimeStatusAtDelivery changing due to trust anchor changes (addition/removal of CAs, certificate revocation/expiration). The desired user experience is to know if a message was trustworthy at delivery and if its key has since been revoked (meaning it's no longer trustworthy). Distinction between revoked and expired certificates was highlighted; expired keys should not invalidate past signatures, but revoked keys should.
signedVerified/signedFailed Definition: These statuses contained too many implementation details. Suggestion to reference existing RFCs and clarify specific checks (e.g., From address matching certificate).
ISG Comments: Noted that ISG comments received were non-blocking but led to good discussions and improvements.

JMAP S/MIME (Sending Mail)

Message Generation: The draft adds isSigned and isEncrypted boolean attributes to Email/set.
MIME Structure: Questioned if clients need to control multipart/signed vs. application/pkcs7-mime for signing.
Configuration: Suggested that signing/encryption preferences (and potentially key selection) should be set on an Identity object rather than per-message.
Automatic Decryption: Discussed if JMAP should automatically decrypt messages on retrieval or require explicit client requests. A boolean option in Email/get (similar to fetching text/HTML body parts) was suggested.

JMAP Calendars

Status: Still seeking implementation experience. A few minor TODOs remain. No significant updates since the interim meeting.

JMAP Tasks

assignee Property: Minor change: assignee property moved to be a value within the participantRole property (similar to JS Calendar).
Task System Survey: A survey of various task systems (groupware, Kanban, issue tracking) was conducted.
- Heterogeneity: Task systems are heterogeneous regarding complex features (alerts, attachments, recurrence, relations). Many implementations might skip these.
- Homogeneity: Most core features are homogeneous.
- New Features: Identified features not yet in JMAP Tasks but common in systems: checklist, comment list/discussion, history, generic key-value properties.
Extensibility Model: Proposed approach: Define a minimal core functionality that all servers supporting JMAP Tasks must implement. Servers can then advertise support for additional features (e.g., recurrence rules) via capabilities. This allows clients to adapt their UI.
Generic History/Comments: Discussion on whether "history" or "comments" should be a separate, generic data type across JMAP (for contacts, events, tasks) rather than task-specific.

JSContact

Implementation Experience: Still actively seeking broader implementation experience. FastMail is working with an older version, and the RDAP working group is implementing a subset.
Unicode Personal Name Formatting: A Unicode Public Review Issue on personal name formatting is highly relevant.
- Alignment: The goal is to align JSContact's nameComponents with this Unicode effort, while keeping formatting/sorting out of scope for JSContact itself.
- Renaming: Proposed renaming personalName to given and additionalName to middle.
- Surnames: Discussion on handling multiple surnames (e.g., surname, secondarySurname) and their ordering, potentially using an array with an nth property or implicit order.
- Unicode Liaison: Identified an IETF liaison manager for Unicode.
Gender Property (vCard): No resolution yet on how to best support the vCard GENDER property in JSContact. The primary use case is pronoun/addressing (Mr./Mrs.) in different languages. Seeking guidance from the IETF and/or the Unicode liaison.

IMAP Extended Search and Fetch for Large Mailboxes (Extra WG)

Problem Statement: Current IMAP clients and servers struggle with large mailboxes (50k+ messages). Clients often fetch excessive flag data, and servers face high memory/resource usage for message ID to UID mapping.
Proposal: Extend IMAP SEARCH and UID FETCH with a PARTIAL option that specifies the maximum number of messages to return.
- SEARCH: Extend RFC 526's PARTIAL option to allow negative ranges (e.g., -100 for the last 100 messages) in addition to starting from the first.
- UID FETCH: Add a similar PARTIAL modifier.
Benefits: Allows servers to stop processing early, optimizes network traffic, and enables clients to fetch only what they display (e.g., the most recent 100 messages).
PARTIAL and SAVE Interaction: The draft also defines how the new PARTIAL extension interacts with the SAVE extension.
IMAP XVIEW: Mentioned as a previous attempt to address similar problems but deemed too complex.

Any Other Business (AOB)

Sieve Implicit Conventions (Interoperability): Discussion around managing Sieve rules, especially those generated by webmail systems (e.g., FastMail, Horde). These often rely on implicit conventions (e.g., comments for rule names, specific ordering) that are not formally part of Sieve or JMAP Sieve, leading to interoperability issues when migrating or managing rules from different systems.
- JMAP Workaround: For JMAP Sieve, a workaround using JMAP capabilities (e.g., conveying a productID like "horde") was found to apply specific parsing logic for system-generated rules.
- Sieve Blob vs. Inline: Re-opened discussion on whether JMAP Sieve should allow fetching raw script text inline, similar to email body parts, in addition to using blob IDs. This could simplify implementation for certain use cases.

Decisions and Action Items

JMAP Blob

Decision: Explicitly reference RFC 4648 for Base64 encoding.
Decision: Remove asHex encoding due to lack of strong use cases and added complexity.
Decision: Remove the expires property due to undefined semantics.
Action Item (Ron): Update the JMAP Blob draft with the above changes and prepare for Working Group Last Call.
Action Item (Jim): Initiate Working Group Last Call for JMAP Blob next week after Ron's updates.

JMAP S/MIME (Received Mail)

Decision: Change default caching time for S/MIME verification to 1 day.
Decision: Rely on JMAP's capability-based extensibility for sMimeStatus values; no IANA registry will be created for this attribute.
Decision: Add the ability to query sMimeStatusAtDelivery in Email/query.
Decision: Keep the signed attribute for optimization, clarifying its meaning (syntactic presence).
Decision: Clarify the semantics of sMimeStatusAtDelivery to reflect trustworthiness at delivery, potential change with trust anchor updates, and specific signature checks (e.g., matching the From address).
Decision: Refine the descriptions for signedVerified and signedFailed to reference relevant RFCs and highlight important checks.
Action Item (Alexey): Implement all the above changes and post a new draft of the JMAP S/MIME (Received Mail) specification.

JMAP S/MIME (Sending Mail)

Action Item (Alexey): Define how to control multipart/signed vs. application/pkcs7-mime options on the JMAP Identity object.
Action Item (Alexey): Document how to list available keys for signing/encryption on the Identity object (without storing key material itself).
Action Item (Alexey): Add a boolean option to Email/get for clients to explicitly request automatic decryption of S/MIME messages.

JMAP Tasks

Action Item (Harjoth, Alexey): Continue refining the task system survey, incorporate feedback, and reach out to developers/vendors for input.
Action Item (Working Group): Explore defining a "core" set of task features and using JMAP capabilities for optional/complex features (e.g., recurrence, alerts, attachments).
Action Item (Working Group): Investigate if complex features like "history" or "comments" could be defined as generic JMAP data types applicable across tasks, events, and contacts.

JSContact

Action Item (Robert): Contact the IETF liaison manager for Unicode (Pete Resnick) to discuss alignment of JSContact name components with the Unicode Personal Name Formatting issue.
Action Item (Robert, Murray): Seek IETF/Unicode guidance on how to define and handle the vCard GENDER property in JSContact.
Action Item (Robert): Propose renaming personalName to given and additionalName to middle in JSContact to align with Unicode.
Action Item (Robert): Draft a generic history specification that could be applied across various JMAP data types (contacts, events, tasks).

IMAP Extended Search and Fetch (Extra WG)

Action Item (Alexey): Propose adoption of the IMAP Extended Search and Fetch draft in the Extra Working Group.
Action Item (Alexey): Review the old IMAP XVIEW extension for any salvageable ideas.

Any Other Business (Sieve)

Action Item (Alexey, Ken): Follow up on the Extra mailing list regarding the proposal for structured comments or annotations for Sieve rules to address interoperability issues and client UI management.
Action Item (Ken): Revisit the discussion on whether JMAP Sieve should allow fetching raw script text inline in Script/get in addition to using blob IDs.

Next Steps

JMAP Blob: Aim for Working Group Last Call (WGLC) next month, pending updates.
JMAP S/MIME: Alexey to post new drafts incorporating discussion feedback for both received and sending S/MIME.
JMAP Tasks: Continue survey and analysis, with a focus on defining core features and an extensible capability model.
JSContact: Focus on alignment with Unicode name formatting and seeking guidance on the gender property. Begin implementation experience gathering.
IMAP Extended Search/Fetch: Alexey will push for adoption in the Extra WG.
Sieve Interoperability: Discussions to continue on the Extra WG mailing list.
Milestones: Update working group milestones to reflect revised timelines for JMAP S/MIME (adopted), JMAP Access to Address Books (April 2022), JMAP Sieve (early next year), and JMAP Quotas (pending Extra Quotas).