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/