Subject: [Jmap] Proposed new charter

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 06 Nov 2018 04:36:30 -0500

Here's a first draft at the text. I've kept bits of the existing charter, chopped out a lot of the stuff which was just constraints on the -mail work, since that one is basically done, and kept it fairly open ended about which extensions can be accepted so long as the group agrees that the work is in scope for either email or related things which would plausibly be part of a client which also does email. 
 
I've put the master copy in git at: https://github.com/jmapio/jmap/blob/master/charter.txt 
 
Please give feedback here, or at the session tomorrow at IETF103. I will speak to the charter there and expect to do at least one round of discussion and edits before submitting this. 
 
Cheers, 
 Bron
 
--- 
 
A number of JSON-based email access protocols have been developed that 
are proprietary, non-standard, and incompatible with each other. These 
protocols are proliferating due to existing standards being insufficient 
or poorly suited to the environments they are operating in, particularly 
mobile and webmail. 
 
The use of multiple protocols to perform actions within a single 
application creates significant support challenges, as users may get a 
variety of partial failure modes (for example, can receive email but 
cannot send new messages). This is further exacerbated if the different 
protocols are authenticated separately. 
 
JMAP specifies the interactions between email clients and mail stores, 
providing an alternative to IMAP and SMTP submission. The JMAP working 
group will specify a mechanism to allow clients to both view and send 
email from a server over a single HTTPS channel with minimal round 
trips. A single protocol for receipt and submission will resolve long- 
standing difficulties users face setting up clients to talk to servers. 
 
The protocol will support push notification of changes using the 
mechanism defined in RFC 8030. This will give mobile clients benefits in 
terms of battery life and network usage. It will also support push 
notifications via server-sent events 
(https://www.w3.org/TR/eventsource/) for direct connection to clients 
that can support persistent TCP connections. 
 
Once draft-ietf-jmap-core and draft-ietf-jmap-mail have been completed, 
taking into account the value to client software of having a single 
authentication method and single endpoint for all its interactions with 
a server, the working group will work on other extension for related data 
types, including (but not limited to) calendars, contacts and files. 
 
Other extensions may be created to allow for access to advanced features 
provided by some mail servers, for example any additional parts of SIEVE, 
IMAP, SMTP submission, as well as for 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 a protocol 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, for 
 example the JSCalendar work being done in the CALEXT working group 
 will for the basis for jmap-calendar. 
 
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 any 
 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 the following: 
 
- a specification based on JSCalendar for JMAP access to calendars 
 
- a specification for JMAP access to contacts, either defining a new 
 JSON format for contacts, or working with another working group on 
 developing the format first. 
 
- a specification for JMAP access to a filesystem tree which can be 
 integrated with the jmap-core upload mechanism. 
 
- other extensions which the working group considers related to email 
 and compatible with the constraints listed above. 

-- 
 Bron Gondwana, CEO, FastMail Pty Ltd 
 [email-masked]

---

From: Sudi <[email-masked]>
Date: Tue, 06 Nov 2018 09:03:17 -0800

Per a previous conversation with the group, I’ve learnt to see JMAP (JSON Meta Application Protocol) as a generic protocol; and JMAP Mail, JMAP Contacts, JMAP Calendar, etc as specific implementations for said applications.

Would it be possible to distinguish JMAP vs JMAP XXX in the writeup below? It seems to imply JMAP as equivalent to JMAP Mail.  For example:

> JMAP specifies the interactions between email clients and mail stores, providing an alternative to IMAP and SMTP submission. 

-Sudi 

> On Nov 6, 2018, at 1:36 AM, Bron Gondwana <[email-masked]> wrote:
> 
> I've put the master copy in git at: https://github.com/jmapio/jmap/blob/master/charter.txt <https://github..com/jmapio/jmap/blob/master/charter.txt>
> 
> (https://www.w3.org/TR/eventsource/ <https://www.w3.org/TR/eventsource/>) for direct connection to clients
>   [email-masked] <mailto:[email-masked]>
> 
> 
> _______________________________________________
> Jmap mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/jmap <https://www.ietf.org/mailman/listinfo/jmap>