**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).