Re: WG Review: JSON Mail Access Protocol (jmap)

[Dave Crocker <[e-mail]>]

On 2/3/2017 4:26 PM, The IESG wrote:
> A new IETF WG has been proposed in the Applications and Real-Time Area.

A November version of this charter was circulated and while there have 
been some changes to produce the current draft charter, some issues 
noted earlier have not been reflected here (and did not receive comments 
in November.)


> JSON Mail Access Protocol (jmap)
> -----------------------------------------------------------------------
> Current status: Proposed WG
>
> Chairs:
>   TBD
>
> Assigned Area Director:
>   Alexey Melnikov <[e-mail]>
>
> Applications and Real-Time Area Directors:
>   Ben Campbell <[e-mail]>
>   Alissa Cooper <[e-mail]>
>   Alexey Melnikov <[e-mail]>
>
> Mailing list:
>   Address: [e-mail]
>   To subscribe: https://www.ietf.org/mailman/listinfo/jmap
>   Archive: https://mailarchive.ietf.org/arch/search/?email_list=jmap
>
> Group page: https://datatracker.ietf.org/group/jmap/
>
> Charter: https://datatracker.ietf.org/doc/charter-ietf-jmap/
>
> A number of JSON-based representations of email have been developed
> that 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.

 From my November comments:

      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.

Adding to this:

JSON is a meta-format.  It isn't a 'protocol'.  Something encoded in 
JSON is a format, not a protocol.  Hence one of the tasks apparently 
being chartered would be to create a new message access protocol, 
encoded in JSON.  While that might be worth doing, there needs to be 
clarity that this is more than a 'representation'.  There also needs to 
be clarity about the relationship between the JSON encodings and the 
encodings in 'native' Internet Mail.


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

 From my November comments:

      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.

Adding to this:

The IETF email technical community looked at the question of making 
email submission part of IMAP or keeping it separate.  It took an entire 
year to debate this point extensively and (imo) constructively, and 
decided to keep them separate.  The current charter draft appears to 
have decided otherwise, but offers only the barest of justifications, 
which I suspect has not factored in the earlier evaluation.


> The JMAP working group will specify a mechanism to allow clients to
> both view and send email from a server over a single stateless HTTPS
> channel with minimal round trips. A single protocol for receipt and
> submission will resolve long-standing difficulties users face
> setting up clients to talk to servers.
>
> The protocol will support
> push notification of changes using the mechanism defined in RFC 8030.
> This will give mobile clients benefits in terms of battery life and
> network usage. It will also support push notifications via server-sent
> events (https://www.w3.org/TR/eventsource/) for direct connection to
> clients that can support persistent TCP connections.
>
> The work of this group is limited to developing a protocol for a client
> synchronising data with a server. Any server-to-server issues
> are out of scope for this working group.
> New end-to-end encryption mechanisms are out of scope, but the work
> should
> consider how to integrate with existing standards such as S/MIME and
> OpenPGP.

Why not TLS, also?


...

> 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, with
>   support for flood control and batched operations, and operating over
>   a stateless connection such as HTTPS.

'flood control'?  what does this mean, since I assume the target 
protocol won't be using a flooding algorithm.  If it really means 
'congestion control', that's not typically part of an application 
protocol, so why would it be an issue here?

 From the November comments

      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.

      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.

Adding to this:

    HTTP/HTTPS are not stateless, since they are connection-based.


> - 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 the November comments:

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



d/

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

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net