**Session Date/Time:** 21 Mar 2022 13:30

# jmap

## Summary

The jmap and extra session covered updates and discussions on several drafts. Key discussions included clarifications and proposed changes for JMAP Blob (renaming `blobSet` to `blobUpload`, removing `concatenate`, and discussing `blob/query` and metadata retrieval), JMAP Calendars (concept of "server as source," default calendar behavior, default alerts, and per-user properties), and JMAP Tasks (new properties, progress state extensions, and grouping properties into capabilities). S/MIME signing and encryption for JMAP, Sieve Action Registry, Sieve Snooze, Sieve IMAP Process, and IMAP Partial/Message Limit were also reviewed, with several approaching Working Group Last Call or publication.

## Key Discussion Points

### JMAP S/MIME
*   **Status:** All feedback addressed, minor formatting (XML v3 emphasis) pending.
*   **Outlook:** Expected to be published soon.

### JMAP Blob
*   **`blobSet` to `blobUpload`:** Renamed as it only supports creation, not updates or destruction. Creation IDs are still used for back-referencing.
*   **`concatenate` removal:** The concept was removed; uploads are now always a list of byte/octet sources, simplifying the model.
*   **Capabilities:** Simplified maximum upload size specification.
*   **Metadata Retrieval:** Discussion on explicitly noting that `blob/get` can retrieve only the size property, allowing clients to get metadata without server reading the full file.
*   **`blob/query`:** Proposal for a `blob/query` to list all blobs (e.g., for replication/migration). Concerns raised regarding its fit with JMAP principles (no state string for change tracking, large data implications, pagination challenges). It was suggested that references from actual JMAP objects (`Email`, `CalendarEvent`, etc.) remain the encouraged way to find blobs.
*   **JMAP for Files:** Confirmed as a separate, future document that would likely leverage JMAP Blob for upload.

### JMAP Quotas
*   **Simplifications:** Removed Quota IDs (fetchable via `quota/get`), simplified scope and resource type extensions, and renamed `size` to `octets` and `limit` to a more generic definition.
*   **Review:** Alexey Melnikov to review for consistency with the upcoming JMAP Core Quota RFC.

### JMAP Sharing
*   **Status:** Near completion, requiring some wordsmithing.
*   **Outlook:** Expected to progress to Working Group Last Call soon.

### JMAP Calendars
*   **"Server is Source" Concept:**
    *   Proposed adding a new property (`isController` or similar) to `CalendarEvent` to indicate if the server creating/storing the event is its primary "controller" (e.g., responsible for sending invitations). This helps clients determine appropriate UI behavior.
    *   Naming: `isSource` was deemed potentially confusing due to `source` in JMAP Tasks. `isController` was suggested.
*   **Default Calendars:**
    *   CalDAV mandates a default calendar; it was largely agreed JMAP Calendars should align.
    *   If a default calendar is deleted, the server should automatically promote another read-write calendar as the new default. This behavior should be explicit in the spec.
    *   The `defaultCalendarId` in user preferences *could* be null if no scheduling is intended for the account.
*   **Default Alerts:**
    *   Server may have vendor-specific behavior for copying default alerts when a new calendar is created (e.g., from the user's current default calendar), provided the server returns the set defaults to the client.
    *   Clarification needed on whether default alerts can be set on a calendar if the user does not have `mayUpdatePrivateACL`.
*   **Calendar Preferences Object:** Discussion on adding `firstDayOfWeek` and preferred date/time format to the `CalendarPreferences` object.
*   **Per-User Properties:** Proposal to modify the `js-calendar` spec registry to explicitly mark properties that are treated as per-user (e.g., alerts in a shared calendar) to clarify server behavior in team mode.

### JMAP Tasks
*   **New Properties:**
    *   `source`: String indicating origin (e.g., "email", "mobile app").
    *   `estimatedWork`: Abstract estimation of work (distinct from `estimatedDuration`).
    *   `impact`: String for issue tracking (e.g., "major", "block").
    *   `relatedTo`: Extension of `relation` object to include values like `blockedBy`.
*   **Extended `progress` Property:** Added new values (e.g., `done`, `notDone`, `deferred`, `waiting`, `resolved`, `feedback`) to better map diverse task system states. Clarification requested on the distinction between `resolved` and `completed`.
*   **Grouping Properties into Capabilities:**
    *   Acknowledging the heterogeneity of task systems (e.g., some don't need recurrence), a capability-based approach was proposed.
    *   Properties would be grouped into feature sets (e.g., "common," "time estimation," "advanced scheduling").
    *   Servers would advertise supported capabilities (e.g., `supportsTimeEstimation: true/false`), allowing clients to adapt.
    *   Proposed a new `notSupported` set error for properties a server knows about but chooses not to implement, distinct from `invalidProperties` for unknown properties.
*   **Blob Created Timestamp:** For attachments linked to tasks, the "created" timestamp should be a property on the `Link` object itself, representing the time the link was created within the JMAP system, rather than the blob's intrinsic creation time.
*   **Keywords/Categories with Colors:** Explored adding keyword/category properties for task lists with associated colors, potentially aligning with calendar categories.
*   **Feedback on new properties:** Discussion points raised on the interoperability and value of free-text fields for `source`, the distinction between `estimatedWork` and `estimatedDuration`, and the necessity of `impact` when `priority` exists.

### JMAP S/MIME Signing & Encryption
*   **Functionality:** Extension to allow signing and/or encrypting messages on send via JMAP.
*   **Open Issues:**
    *   Control over S/MIME message generation (`multipart/signed` vs. `application/pkcs7-mime`).
    *   Header protection: Default value (true vs. false) for protecting headers. Recommendation from Lamps WG to default to `true` was discussed.
    *   Decryption: Complementary feature that would require a different approach (e.g., via decrypted blobs).
*   **Trust Model:** Delegating secret keys to the JMAP server implies a trust model where the client and server are considered part of the user's trusted "end."

### EXTRA Quota
*   **Status:** Ready for publication, pending an IANA website text update.

### Sieve Action Registry
*   **Status:** Template and initial registrations are complete.
*   **Pending:** Adding comments about `reject` conflicts.

### Sieve Snooze
*   **Status:** No updates, implemented in Cyrus IMAP and deployed at Fastmail. Works as intended.

### Sieve IMAP Process
*   **Functionality:** A mechanism for users to control how the IMAP server processes iTIP (calendar) messages (e.g., accepting invites, processing updates, removing on cancel), leveraging Sieve.
*   **Options:** Includes specifying external addresses for processing, a default calendar for new invites, options to only process updates (not new invites from untrusted sources), and variables to store the outcome or error messages.
*   **Feedback:** Suggestions to split `update` and `cancel` as distinct outcome values. The architectural implications for varying IMAP server implementations were noted, but the approach standardizes user control.

### IMAP Partial / Message Limit
*   **Partial:** An IMAP extension to request a subset (page/range) of messages in search and UID FETCH responses, especially useful for large mailboxes. Supports negative numbers for "from end of mailbox."
*   **Message Limit:** Server-imposed limit on the number of messages an operation can apply to (e.g., 10,000 messages). This helps servers avoid resource-intensive operations on extremely large mailboxes.
*   **Interaction with COPY/UID COPY:**
    *   **Problem:** If a client requests copying more messages than the `MESSAGE-LIMIT`, how should the server respond?
    *   **Decision:** The server should reject (`NO`) the operation outright rather than performing a partial copy and returning `OK`. This avoids misleading clients and ensures clients that understand `MESSAGE-LIMIT` can perform batch copies. Naive clients would fail safely.
*   **Interaction with RENAME INBOX:** It was suggested that `RENAME INBOX` (which often involves copying) should be an exception and proceed regardless of `MESSAGE-LIMIT`.

## Decisions and Action Items

### Decisions
*   **JMAP S/MIME:** Ready for publication.
*   **JMAP Blob:**
    *   `blobSet` renamed to `blobUpload`.
    *   `concatenate` removed.
    *   Spec to explicitly mention `blob/get` can retrieve only size metadata.
*   **JMAP Calendars:**
    *   A new property (`isController` or similar) will be added to `CalendarEvent` to indicate server control.
    *   Servers should ensure at least one read-write calendar for scheduling. If the default is deleted, the server may auto-promote another.
    *   Vendor-specific behavior for copying default alerts on calendar creation is allowed, provided the server returns what it set.
    *   The `js-calendar` registry will be modified to mark per-user properties.
*   **JMAP Tasks:**
    *   Extend existing progress value registry for `progress` property.
    *   Adopt a capability-based approach with feature sets for JMAP Tasks.
    *   `created` timestamp for blobs (attachments) should be a property on the `Link` object.
*   **EXTRA Quota:** Ready for publication.
*   **Sieve Snooze:** Ready for Working Group Last Call.
*   **IMAP Partial / Message Limit:** Server should reject COPY/UID COPY requests that exceed `MESSAGE-LIMIT` (not partially succeed).

### Action Items
*   **Bron:** Post responses to JMAP Blob mailing list, update draft with `blob/get` advice, then request WGLC for JMAP Blob.
*   **Alexey Melnikov:** Review JMAP Quota document for consistency with JMAP Core Quota RFC; implement and test `partial` in client; request WGLC for JMAP S/MIME Signing/Encryption; request WGLC for Sieve Action Registry.
*   **Rene:** Request WGLC for JMAP Quotas after Alexey's review.
*   **Neil Jenkins:** Update JMAP Sharing document, then request WGLC. Make changes to JMAP Calendars based on discussion, add examples, aim for WGLC.
*   **Joris Baum:** Clarify `resolved` vs `completed` for JMAP Tasks `progress` property; refine grouping of JMAP Tasks properties into capabilities; consider feedback on `estimatedWork`, `impact`, and `source` properties.
*   **Robert M\u00fcller:** Draft a `notSupported` set error for JMAP; explore a general property change tracking spec across JMAP object types.
*   **Ken Murchison:** Post call for adoption of Sieve IMAP Process on mailing list; update Sieve IMAP Process draft (e.g., split outcome values, add to `sieve-action` document).
*   **Working Group:** Provide feedback on JMAP Blob, JMAP Quotas, Sieve Action Registry, and Sieve IMAP Process. Discuss default value for JMAP S/MIME header protection.
*   **Alexey Melnikov:** Add an explicit statement to IMAP Message Limit spec regarding `RENAME INBOX` as an exception to message limits.

## Next Steps

*   **JMAP Blob:** After updates and WGLC, submit to IESG (target Q3 2023).
*   **JMAP S/MIME:** Publication pending.
*   **JMAP Quotas:** WGLC pending review.
*   **JMAP Sharing:** WGLC pending update.
*   **JMAP Calendars:** WGLC pending updates and examples (target Q3 2023).
*   **JMAP Tasks:** Continue refinement based on feedback, focusing on capability grouping and property clarifications.
*   **Sieve Action Registry:** WGLC pending update.
*   **Sieve Snooze:** WGLC to be requested.
*   **Sieve IMAP Process:** Seek working group adoption.
*   **IMAP Partial / Message Limit:** `partial` ready for WGLC after client testing; `message-limit` may require further work and discussion on mailing list.
*   **JMAP Address Book:** Updates in progress (target Q3 2023).
*   **EXTRA Charter:** The milestone to update the EXTRA charter will be deleted, as discussions on email core charter are happening in the Dispatch WG.