Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap)

Hi Dave,

I am mostly proxying proponents of the Charter, but I did some editing 
pass over it, so I am replying to some of your comments.

On 06/02/2017 19:25, Dave Crocker wrote:
> 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 <aamelnikov(_at_)fastmail(_dot_)fm>
> >
> > Applications and Real-Time Area Directors:
> >   Ben Campbell <ben(_at_)nostrum(_dot_)com>
> >   Alissa Cooper <alissa(_at_)cooperw(_dot_)in>
> >   Alexey Melnikov <aamelnikov(_at_)fastmail(_dot_)fm>
> >
> > Mailing list:
> >   Address: jmap(_at_)ietf(_dot_)org
> >   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.
I don't think there is intent to specify full mapping of RFC5322/MIME to 
JSON. IMAP has BODYSTRUCTURE element that contains parsed representation 
of message structure and most commonly used header fields for different 
body parts. The intent is to do the same here.
Additionally, it is still possible to retrieve full RFC5322/MIME 
payloads over JMAP.
I have tried to reflect your comments in the Charter, but I struggled a 
bit. If you can suggest how to make the above clearer, that would be 
much appreciated.
> 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'.
No, it is a representation. See above.
> There also needs to be clarity about the relationship between the JSON 
> encodings and the encodings in 'native' Internet Mail.
See drafts (and above).
> > 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.
I am not sure what kind of justification is needed. This is a clear 
deployment problem.
> 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.
There was a followup discussion about doing an IMAP extension for 
submission and how it should look like to remain compatible with SMTP 
Submission. I don't think this is an attempt to just ignore earlier 
discussions.
> > 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?
TLS is assumed. I think the Charter text says HTTPS elsewhere.
> ...
>
> > 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. 
Stateless lower level transport. The addition of "such as HTTPS" was 
trying to make this clearer.
> 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.
Presence of tools for manipulating JSON and ease of development. This 
was mentioned on the JMAP mailing list. I don't think this needs to be 
said here.
> Adding to this:
>
>    HTTP/HTTPS are not stateless, since they are connection-based.
Yeah, I struggled with this a bit. Each request/response can be sent on 
a separate connection and it is stateless in that sense.
> > - 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?
I don't mind deleting this, but I would like to see if IESG approves 
this as is ;-).
Best Regards,
Alexey
> d/
>
> [0] http://www.json.org/