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

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.

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. 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> 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) by
> 2017-02-13.
>
> JSON Mail Access Protocol (jmap)
> -----------------------------------------------------------------------
> Current status: Proposed WG
>
> Chairs:
>   TBD
>
> Assigned Area Director:
>   Alexey Melnikov <aamelnikov@fastmail.fm>
>
> Applications and Real-Time Area Directors:
>   Ben Campbell <ben@nostrum.com>
>   Alissa Cooper <alissa@cooperw.in>
>   Alexey Melnikov <aamelnikov@fastmail.fm>
>
> 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/
>
> 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/) 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/]
>
> - 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:
>
>
>