Hi Phillip,
On 06/02/2017 15:27, Phillip Hallam-Baker wrote:
I don't see much point if all that we do is simply re-invent IMAP in
JSON. To add value, a new protocol in this space needs to advance on
the old.
The current proposal is "advancing on the old". It is improving on some
IMAP use cases and there is also a proposal how to add calendaring.
However calendaring is currently out of scope in order to avoid boiling
the ocean.
Today we have many things that look like mail that are not mail but
could benefit from IMAP type interface. These include:
* Mailing lists
* Newsgroups
* Blog comments
* Git Pull requests
Note that all of these are messages that are frequently transported
over SMTP but handled very poorly as mail.
Mailing lists are not mail. They look like mail but they are not
because they represent a discussion that frequently begins before the
user has joined. They have semantics for subscription and
unsubscription. There is frequently an external archive.
I don't think it unreasonable to ask folk doing an 'X in JSON' project
to extend it.
It is not unreasonable to ask to extend, but we should be careful about
not asking for too much.
Best Regards,
Alexey
Because if the move to JSON does not make such extensions easier to
introduce, what was the point of varying the syntax in the first place.
Being able to connect to discussion forums via an IMAP like interface
would be very useful and allow a lot of mail volume to be culled.
On Fri, Feb 3, 2017 at 7:26 PM, The IESG <iesg-secretary(_at_)ietf(_dot_)org
<mailto:iesg-secretary(_at_)ietf(_dot_)org>> wrote:
A new IETF WG has been proposed in the Applications and Real-Time
Area.
The IESG has not made any determination yet. The following draft
charter
was submitted, and is provided for informational purposes only. Please
send your comments to the IESG mailing list (iesg(_at_)ietf(_dot_)org
<mailto:iesg(_at_)ietf(_dot_)org>) by
2017-02-13.
JSON Mail Access Protocol (jmap)
-----------------------------------------------------------------------
Current status: Proposed WG
Chairs:
TBD
Assigned Area Director:
Alexey Melnikov <aamelnikov(_at_)fastmail(_dot_)fm
<mailto:aamelnikov(_at_)fastmail(_dot_)fm>>
Applications and Real-Time Area Directors:
Ben Campbell <ben(_at_)nostrum(_dot_)com
<mailto:ben(_at_)nostrum(_dot_)com>>
Alissa Cooper <alissa(_at_)cooperw(_dot_)in
<mailto:alissa(_at_)cooperw(_dot_)in>>
Alexey Melnikov <aamelnikov(_at_)fastmail(_dot_)fm
<mailto:aamelnikov(_at_)fastmail(_dot_)fm>>
Mailing list:
Address: jmap(_at_)ietf(_dot_)org <mailto:jmap(_at_)ietf(_dot_)org>
To subscribe: https://www.ietf.org/mailman/listinfo/jmap
<https://www.ietf.org/mailman/listinfo/jmap>
Archive:
https://mailarchive.ietf.org/arch/search/?email_list=jmap
<https://mailarchive.ietf.org/arch/search/?email_list=jmap>
Group page: https://datatracker.ietf.org/group/jmap/
<https://datatracker.ietf.org/group/jmap/>
Charter: https://datatracker.ietf.org/doc/charter-ietf-jmap/
<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.
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.
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/
<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.
The working group will coordinate with the Security Area on credential
management and authentication.
Input to working group discussions shall include:
- CONDSTORE and QRESYNC
[RFC 7162]
- Collection Synchronisation for WebDav
[RFC 6578]
- LEMONADE and experiences from adoption of its output
[https://datatracker.ietf.org/wg/lemonade/charter/
<https://datatracker.ietf.org/wg/lemonade/charter/>]
- SMTP SUBMISSION
[RFC 6409]
- SMTP BURL
[RFC 4468]
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.
- 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.
Milestones: