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

[Jacob Palme <[e-mail]>]

The MHTML format may be of interest as input to this group. It compiles encapsulation of various parts in MIME-formatted e-mail.

See:
https://en.wikipedia.org/wiki/MHTML
https://tools.ietf.org/html/rfc2557
— 
Jacob Palme professor emeritus Stockholm University
for more info see https://people.dsv.su.se/~jpalme/


> On 07 Nov 2016, at 19:05, Ned Freed <[e-mail]> 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.
> 
>> 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
> 
> _______________________________________________
> ietf-smtp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf-smtp