ietf-smtp
[Top] [All Lists]

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

2016-11-10 13:59:23
(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.


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.

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


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.

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
out-of-band signaling of changes, and will give mobile clients
significant benefits in terms of battery life and network usage.

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


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

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


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.

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.


- A document describing how to use the extensible protocol over HTTPS
  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.


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

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

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [ietf-smtp] [dispatch] Request to form a new WG: JMAP, Dave Crocker <=