Subject: [dispatch] Request to form a new WG: JMAP

From: Alexey Melnikov <[email-masked]>
Date: Mon, 07 Nov 2016 17:17:59 +0000

Hi,
I have received a request to form a new WG: JSON Mail Access Protocol
(JMAP). Draft charter is included below. Please send your comments in
reply to this email or directly to me.

I am also looking for possible chairs for this work, so if you are
interested, please contact me off-list.

Thank you,
Alexey

------------------------------------

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.

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

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.

The work of this group is limited to developing a protocol for a client
synchronising data with a server. Any server-to-server issues or
end-to-end encryption of messages are out of scope for this working
group.

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

Input to working group discussions shall include:

- Internet Message Format
[RFC 5322]

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

- SMTP BURL
[RFC 4468]

The working group will deliver the following:

- A problem statement detailing the deployment environment and
  situations that motivate work on a new protocol for client to
  server email synchronisation.  The working group may choose
  not to publish this as an RFC.

- A document describing an extensible protocol and data structures which
  supports stateless use, flood control and batched operations.

- A document describing how to use the extensible protocol over HTTPS
  with the data structures expressed as JSON.

- A document describing a data model for email viewing, management,
  searching, and submission on top of the extensible protocol.

- An executable test suite and documented test cases to assist
  developers of JMAP servers to ensure they conform to the
  specifications.

---

From: Julien ÉLIE <[email-masked]>
Date: Mon, 7 Nov 2016 22:56:08 +0100

Hi all,

> (2) Some of us believe, at least on some days, that a key reason
> why SMTP, the message formats that started with RFC 822, POP3,
> and IMAP have survived against a large number of proprietary and
> other SDO alternatives have been precisely because they operate
> in plain text, with all but IMAP using very simple
> command-argument or name:value syntax.  Are we ready to give
> that up?  Do we really need interoperability between a server
> and a captive Webmail interface?  Arguably, standards of that
> type are part of the province of the IETF only if someone is
> contemplating generic webmail clients that can interact with the
> servers of more than one organization.

My two cents here:  someone proposed 2 years ago a similar model for 
NNTP.  It was named... JNTP (Json News Transfer Protocol).

Here is its current "specification" (in French):
   http://www.nemoweb.net/?page_id=75

with even an RFC-like format:
   http://www.nemoweb.net/?p=1295

And, as John hinted at, people get then stuck in exchanges between an 
NNTP server and a captive webnews interface like:
   http://news.nemoweb.net/

Since 2014, no much move for JNTP, which is still used only by his creator.
Like SMTP and IMAP, NNTP operates in plain text.  A great advantage over 
other alternatives.

> Again, just questions, but questions I think we need to ask
> carefully before standardizing yet another alternative way to do
> much the same thing.

+1

-- 
Julien ÉLIE

« – Vous ramassez des champignons sans les connaître ?
   – Et alors ? Ce n'est pas pour les manger mais pour les vendre. »

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 8 Nov 2016 09:45:22 +1100

> On 8 Nov. 2016, at 4:17 am, Alexey Melnikov <[email-masked]> wrote:
> 
> incompatible with each other. These protocols are proliferating

It would be helpful to see some examples of this.

--
Mark Nottingham   https://www.mnot.net/

---

From: S Moonesamy <[email-masked]>
Date: Tue, 08 Nov 2016 00:24:46 -0800

Hi Alexey,
At 09:31 07-11-2016, Alexey Melnikov wrote:
>Please post your comments/questions to [email-masked] or directly to me.

I dropped the other two mailing lists from the Cc.

>interested, please contact me off-list.

I did a quick search and I could not find the "many companies and 
projects".  Could you or someone else please provide URIs so that the 
first sentence in the proposed charter can be verified?

Regards,
S. Moonesamy

---

From: Dave Crocker <[email-masked]>
Date: Fri, 11 Nov 2016 04:58:55 +0900

(I hadn't seen the draft charter text until now, due to some 
unfortunately behavior in my email filters.)

As with others, I think the draft charter has a number of very basic 
problems.  I think there are several real issues and that some efforts 
to respond to them could be useful, but that we need far more clarity 
about needs and associated responses, and we need far more narrow 
sequencing of those efforts to respond.  In its current form, this draft 
charter is, IMO, far too scatter-shot and complex, and has far too 
little justifying foundation.

> environments they are operating in, particularly mobile and webmail.

As with others, I take 'representations' to mean formats.  And given 
what JSON is[0] that seems an appropriate interpretation even without 
that word.  So I take this asserted need as having a form of email data 
format that is an alternative to RFC 5322/MIME.

Prior to chartering, we should document just how extensive the current 
problem of multiple JSON email formats is, to establish the practical 
benefit of unifying it. The theoretical benefit should be obvious, but 
that's not enough to justify the cost of a working group.  We should 
establish real market need.

Having spent quite a bit of my early career on email gatewaying, I'll 
comment that getting a common interchange format is especially powerful. 
  The active protocols aren't irrelevant, but stabilizing the message 
object itself is, IMO, far more important. I'm more than a little biased 
about this strategic approach: It provided the unifying base for email, 
during the Internet's early growth into commercial markets.  And it 
happens that focusing on this narrow requirement permits end-to-end -- 
and I mean the real kind:  author to recipient, not just originating 
operator to receiving operator -- benefits without having to change the 
infrastructure, other than insertion of gateways.

Working groups need task serialization.  So I'll suggest that having an 
effort to standardize an JSON representation of an RFC5322/MIME object 
would be the highest-leverage first task.

And not a trivial effort...

As for the remaining effort(s)...

> channel with minimal round trips.

There is no justification given for this approach.  For each activity, 
there needs to be a clear and solid need documented, based on actual 
industry activities or at least industry statements.  Besides clarifying 
/what/ needs doing, it should serve to indicate likely industry uptake 
after the work is done.

> The protocol will support

So, that sounds like some sort of need, but it isn't clear to me what it 
means.

> different protocols are authenticated separately

Ditto.  Worse, any claim that an alternative would be better needs to be 
justified both in terms of its considerable effort and its purported 
improvement.  Unification efforts have a habit of re-creating complexity 
and providing little actual benefit.

Note, for example, that the IETF email community debated whether 
submission should be independent of IMAP or integrated into it.  It was 
a one-year debate and, IMO, was conducted in a highly informed, diligent 
and constructive fashion.  That the result was to maintain separation 
should not be ignored...

>   supports stateless use, flood control and batched operations.

Since client/server email access typically benefits from having the 
server retain state about the client's activities, I can't tell whether 
this actually means stateless lower-level transport or whether it really 
does mean a stateless email protocol.  So this needs to be made much 
more clear, as to the what and the why, as well as to the benefit that 
will accrue.

>   with the data structures expressed as JSON.

Given the considerable complexity of HTTP, I continue to fail to see why 
making it be a universal, lower-layer transport is so popular.  Again, 
the need and the benefit need to be documented.

>   developers of JMAP servers to ensure they conform to the

This last is useful, but I think it's not typically an IETF work product?

A charter is more than a work statement.  It is a marketing tool for 
recruiting industry support.  Hence the need for explanatory text that 
makes needs and benefits clear, as well as specification of deliverables.

d/

[0] http://www.json.org/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net