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

["Adrien de Croy" <[e-mail]>]

I wouldn't necessarily read "representation of email" as meaning message 
format.

It could mean representation of email interface.

As for other things, there are plenty of things which could use 
improvement, and I doubt whether it will ever happen in the current IMAP 
framework due to the problem of there being too many complicated 
combinations of optional extensions.

IMAP5 could do something useful, but the last attempts to kick-start 
that were still-born.

Adrien

------ Original Message ------
From: "Ned Freed" <[e-mail]>
To: "Alexey Melnikov" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>; "'[e-mail]'" 
<[e-mail]>
Sent: 8/11/2016 7:05:06 AM
Subject: Re: [imapext] [ietf-smtp] Fwd: Request to form a new WG: JMAP

>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
>
>_______________________________________________
>imapext mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/imapext