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