[Top] [All Lists]

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

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

Jacob Palme professor emeritus Stockholm University
for more info see

On 07 Nov 2016, at 19:05, Ned Freed <ned(_dot_)freed(_at_)mrochek(_dot_)com> 

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

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

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.

[RFC 7162]

- Collection Synchronisation for WebDav
[RFC 6578]

- LEMONADE and experiences from adoption of its output

[RFC 4409]

And SUBMIT is in play.

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


ietf-smtp mailing list

ietf-smtp mailing list