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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxx>

Applications and Real-Time Area Directors:
  Ben Campbell <ben@xxxxxxxxxxx>
  Alissa Cooper <alissa@xxxxxxxxxx>
  Alexey Melnikov <aamelnikov@xxxxxxxxxxx>

Mailing list:
  Address: jmap@xxxxxxxx
  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/




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]