JSON Mail Access Protocol
charter-ietf-jmap-02-00

WG review announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: jmap@ietf.org 
Subject: WG Review: JSON Mail Access Protocol (jmap)

The JSON Mail Access Protocol (jmap) WG in the Applications and Real-Time
Area of the IETF is undergoing rechartering. The IESG has not made any
determination yet. The following draft charter was submitted, and is provided
for informational purposes only. Please send your comments to the IESG
mailing list (iesg@ietf.org) by 2019-11-04.

JSON Mail Access Protocol (jmap)
-----------------------------------------------------------------------
Current status: Active WG

Chairs:
  Bron Gondwana <brong@fastmailteam.com>
  Jim Fenton <fenton@bluepopcorn.net>

Assigned Area Director:
  Alexey Melnikov <aamelnikov@fastmail.fm>

Applications and Real-Time Area Directors:
  Adam Roach <adam@nostrum.com>
  Alexey Melnikov <aamelnikov@fastmail.fm>
  Barry Leiba <barryleiba@computer.org>

Mailing list:
  Address: jmap@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/jmap
  Archive: https://mailarchive.ietf.org/arch/search/?email_list=jmap

Group page: https://datatracker.ietf.org/group/jmap/

Charter: https://datatracker.ietf.org/doc/charter-ietf-jmap/

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, beginning with calendars
and contacts.

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.

The contact work will begin with a JSON format for contact data based
upon the work begun in draft-stepanek-jscontact, and in consultation with
other users of contact data within the IETF and outside to build an
extensible format.  Where possible, this format will retain the ability
to convert backwards and forwards to RFC6350 vCard format.  This format
will then be used as the basis of JMAP object types for contacts.

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
WSS (WebSocket over TLS, RFC 6455).

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)

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

Milestones:

  Sep 2019 - Submit JMAP over websockets document to the IESG

  Sep 2019 - Submit Message Disposition Notification document to the IESG

  Dec 2019 - Submit document with guidance for implementation of IMAP servers
  and proxies (Informational)


WG action announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: jmap@ietf.org,
    jmap-chairs@ietf.org,
    The IESG <iesg@ietf.org> 
Subject: WG Action: Rechartered JSON Mail Access Protocol (jmap)

The JSON Mail Access Protocol (jmap) WG in the Applications and Real-Time
Area of the IETF has been rechartered. For additional information, please
contact the Area Directors or the WG Chairs.

JSON Mail Access Protocol (jmap)
-----------------------------------------------------------------------
Current status: Active WG

Chairs:
  Bron Gondwana <brong@fastmailteam.com>
  Jim Fenton <fenton@bluepopcorn.net>

Assigned Area Director:
  Alexey Melnikov <aamelnikov@fastmail.fm>

Applications and Real-Time Area Directors:
  Adam Roach <adam@nostrum.com>
  Alexey Melnikov <aamelnikov@fastmail.fm>
  Barry Leiba <barryleiba@computer.org>

Mailing list:
  Address: jmap@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/jmap
  Archive: https://mailarchive.ietf.org/arch/search/?email_list=jmap

Group page: https://datatracker.ietf.org/group/jmap/

Charter: https://datatracker.ietf.org/doc/charter-ietf-jmap/

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, beginning with calendars
and contacts.

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.

The contact work will begin with a JSON format for contact data based
upon the work begun in draft-stepanek-jscontact, and in consultation with
other users of contact data within the IETF and outside to build an
extensible format.  Where possible, this format will retain the ability
to convert backwards and forwards to RFC6350 vCard format.  This format
will then be used as the basis of JMAP object types for contacts.

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
WSS (WebSocket over TLS, RFC 6455).

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)

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

Milestones:

  Sep 2019 - Submit JMAP over websockets document to the IESG

  Sep 2019 - Submit Message Disposition Notification document to the IESG

  Dec 2019 - Submit document with guidance for implementation of IMAP servers
  and proxies (Informational)


Ballot announcement