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

[Alexey Melnikov <[e-mail]>]

Hi Ned,

If this work goes forward, there is definitely some wordsmithing to do 
to address your comments. Quick answers to some of them below:


On 07/11/2016 18:05, Ned Freed wrote:
> 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.
No, the email format is unchanged.
>
>> 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.
Yes, at least this is the proposal.
>
>> 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.
This might be web push, but I agree that this is not clear.
>
>> 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.
Yes.
>> 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.
Yes, basically the IMAP side of things.
> Which would seem to exclude SUBMIT, unless
> you're doing SUBMIT with magic folders
Most likely, yes.
> 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.
No, see above.
>
>> 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