Skip to main content

JSON Mail Access Protocol
charter-ietf-jmap-01-01

The information below is for an older proposed charter
Document Proposed charter JSON Mail Access Protocol WG (jmap) Snapshot
Title JSON Mail Access Protocol
Last updated 2019-05-02
State External Review (Message to Community, Selected by Secretariat) Rechartering
WG State Active
IESG Responsible AD Murray Kucherawy
Charter edit AD Alexey Melnikov
Send notices to (None)

charter-ietf-jmap-01-01

The JMAP protocol defined in draft-ietf-jmap-core is designed to be
extensible to multiple datatypes which are useful for personal
information management related to email stores.

Now that draft-ietf-jmap-mail is completed, the working group will
produce specifications for related data types, begining with calendars.

The calendar work will be based on draft-ietf-calext-jscalandar as the
data format. This working group will consult with the CALEXT working
group to ensure that calendar access via JMAP remains compatible with
existing calendar standards.

Extensions to the existing core and mail JMAP specifications are also
within scope for this working group, for example any additional parts
of SIEVE, IMAP, SMTP submission, as well as transport of JMAP over
different protocols than HTTPS.

Work on JMAP extensions will be bound by the following constraints:

1) The work of this group is limited to developing protocols for a
client synchronising data with a server. Any server-to-server issues
are out of scope for this working group.

2) Object models will use existing IETF work where possible.

3) JMAP Extensions will be built following the core principles:

3.1) The server will not be required to perform work not explicitly
requested by the client, and the default should always be the
mode which requires the least server work.

3.2) The client can discover limits enforced by the server on
resources or request complexity.

3.3) Where side effects generated by the server are optional, the
protocol will default to no side effects, and the client must
explicitly request that those side effects happen (for example:
sending a calendar invitation or reply when updating an event)

4) New transports for transporting JMAP will have security properties
comparable to HTTPS. In particular they have to require TLS.

The working group will deliver documents for the following:

  • JMAP access to calendars using the JSCalendar format

  • accessing JMAP over Websockets

  • handling of S/MIME email messages (e.g. signature verification) over JMAP

  • Message Disposition Notifications (RFC 8098) via JMAP

  • other extensions which the working group considers related to email
    and compatible with the constraints listed above