Re: WG Review: JSON Mail Access Protocol (jmap)

Hi Phillip,

On 06/02/2017 15:27, Phillip Hallam-Baker wrote:

> I don't see much point if all that we do is simply re-invent IMAP in 
> JSON. To add value, a new protocol in this space needs to advance on 
> the old.
The current proposal is "advancing on the old". It is improving on some 
IMAP use cases and there is also a proposal how to add calendaring. 
However calendaring is currently out of scope in order to avoid boiling 
the ocean.
> Today we have many things that look like mail that are not mail but 
> could benefit from IMAP type interface. These include:
>
> * Mailing lists
> * Newsgroups
> * Blog comments
> * Git Pull requests
>
> Note that all of these are messages that are frequently transported 
> over SMTP but handled very poorly as mail.
>
> Mailing lists are not mail. They look like mail but they are not 
> because they represent a discussion that frequently begins before the 
> user has joined. They have semantics for subscription and 
> unsubscription. There is frequently an external archive.
>
>
> I don't think it unreasonable to ask folk doing an 'X in JSON' project 
> to extend it.
It is not unreasonable to ask to extend, but we should be careful about 
not asking for too much.

Best Regards,
Alexey
> Because if the move to JSON does not make such extensions easier to 
> introduce, what was the point of varying the syntax in the first place.
>
> Being able to connect to discussion forums via an IMAP like interface 
> would be very useful and allow a lot of mail volume to be culled.
>
>
>
> On Fri, Feb 3, 2017 at 7:26 PM, The IESG <iesg-secretary@ietf.org 
> <mailto:iesg-secretary@ietf.org>> wrote:
>
>     A new IETF WG has been proposed in the Applications and Real-Time
>     Area.
>     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
>     <mailto:iesg@ietf.org>) by
>     2017-02-13.
>
>     JSON Mail Access Protocol (jmap)
>     -----------------------------------------------------------------------
>     Current status: Proposed WG
>
>     Chairs:
>       TBD
>
>     Assigned Area Director:
>       Alexey Melnikov <aamelnikov@fastmail.fm
>     <mailto:aamelnikov@fastmail.fm>>
>
>     Applications and Real-Time Area Directors:
>       Ben Campbell <ben@nostrum.com <mailto:ben@nostrum.com>>
>       Alissa Cooper <alissa@cooperw.in <mailto:alissa@cooperw.in>>
>       Alexey Melnikov <aamelnikov@fastmail.fm
>     <mailto:aamelnikov@fastmail.fm>>
>
>     Mailing list:
>       Address: jmap@ietf.org <mailto:jmap@ietf.org>
>       To subscribe: https://www.ietf.org/mailman/listinfo/jmap
>     <https://www.ietf.org/mailman/listinfo/jmap>
>       Archive:
>     https://mailarchive.ietf.org/arch/search/?email_list=jmap
>     <https://mailarchive.ietf.org/arch/search/?email_list=jmap>
>
>     Group page: https://datatracker.ietf.org/group/jmap/
>     <https://datatracker.ietf.org/group/jmap/>
>
>     Charter: https://datatracker.ietf.org/doc/charter-ietf-jmap/
>     <https://datatracker.ietf.org/doc/charter-ietf-jmap/>
>
>     A number of JSON-based representations of email 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 can not send new messages).
>     This is further exacerbated if the different protocols are
>     authenticated separately.
>
>     The JMAP working group will specify a mechanism to allow clients to
>     both view and send email from a server over a single stateless 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/
>     <https://www.w3.org/TR/eventsource/>) for direct connection to
>     clients that can support persistent TCP connections.
>
>     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.
>     New end-to-end encryption mechanisms are out of scope, but the work
>     should
>     consider how to integrate with existing standards such as S/MIME and
>     OpenPGP.
>
>     The working group will coordinate with the Security Area on credential
>     management and authentication.
>
>     Input to working group discussions shall include:
>
>     - CONDSTORE and QRESYNC
>     [RFC 7162]
>
>     - Collection Synchronisation for WebDav
>     [RFC 6578]
>
>     - LEMONADE and experiences from adoption of its output
>     [https://datatracker.ietf.org/wg/lemonade/charter/
>     <https://datatracker.ietf.org/wg/lemonade/charter/>]
>
>     - SMTP SUBMISSION
>     [RFC 6409]
>
>     - SMTP BURL
>     [RFC 4468]
>
>     The working group will deliver the following:
>
>     - A problem statement detailing the deployment environment and
>       situations that motivate work on a new protocol for client to
>       server email synchronisation.  The working group may choose
>       not to publish this as an RFC.
>
>     - A document describing an extensible protocol and data
>     structures, with
>       support for flood control and batched operations, and operating over
>       a stateless connection such as HTTPS.
>
>     - A document describing how to use the extensible protocol over HTTPS
>       with the data structures expressed as JSON.
>
>     - A document describing a data model for email viewing, management,
>       searching, and submission on top of the extensible protocol.
>
>     - An executable test suite and documented test cases to assist
>       developers of JMAP servers to ensure they conform to the
>       specifications.
>
>     Milestones:
>
>
>