Re: [imapext] [ietf-smtp] Fwd: Request to form a new WG: JMAP

[Ned Freed <[e-mail]>]

Without getting into whether or not this is in general a good idea, I want to
note that the proposal as written is self-contradictory, making it very
difficult to evaluate. In particular:

> Name:    JSON Mail Access Protocol
> Acronym: jmap
> Area:    Applications and Real-Time Area (art)

> Charter for Working Group

> Many companies and projects are developing their own JSON based
> representations of email which 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.

"Representation of email" would seem to imply that we're talking about a new
message format.

> The JMAP working group will specify an mechanism to allow clients to
> both view and send email from a server over a single stateless HTTPS
> channel with minimal round trips.

And now we appear to be talking about a replacment for both IMAP and SUBMIT.
This effectively means we're replacing all of the email protocol and format
suite with the exception of SMTP.

> The protocol will support
> out-of-band signaling of changes, and will give mobile clients
> significant benefits in terms of battery life and network usage.

And now we appear to be talking about server->client synchronization, which
is, in standards terms at least, new.

> 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.

So we're clearly aiming to replace multiple protocols here.

> The work of this group is limited to developing a protocol for a client
> synchronising data with a server.

Whoops! Now we're talking we're limiting ourselves to synchronization of
the client with the server. Which would seem to exclude SUBMIT, unless
you're doing SUBMIT with magic folders and header fields or something
similar.

> Any server-to-server issues or
> end-to-end encryption of messages are out of scope for this working
> group.

If you're talking about a new message format, you're going to have
to deal with end-to-end encryption issues whether you like it or not, either
by changing SMTP as well so that message in this new format can in fact
be transmitted end-to-end, by defining an encapsulation format, by allowing
servers to perform gateways, etc.

> The working group will coordinate with the Security Area on credential
> management and authentication.

Again, if you're talking about a new message format, this isn't going
to be remotely adequate.

> Input to working group discussions shall include:

> - Internet Message Format
> [RFC 5322]

This also would seem to imply the message format is in play.

> - 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 4409]

And SUBMIT is in play.

> - SMTP BURL
> [RFC 4468]

Again, I'm not prepared to offer an opinion as to whether or not this whole
thing is a good idea. But I will say that effectively replacing the entire
email protocol suite - which is entirely consistent with what's  been said here
- would at a minimum be a tremendous amount of work requiring a tremendous
amount of justification, and what's in this propsoal doesn't come close.

				Ned