Alexey,
These are just questions, not opposition, but the answers should
probably be clear in any charter or chartering effort.
(1) We've had a long history of variations on The Format to End
All Formats, none of which have lasted a very long time. I
think JSON is better than most, but, if yet another wonderful
format shows up in a few years and takes over, is it worth
thinking now about what a transition plan would look like?
(2) Some of us believe, at least on some days, that a key reason
why SMTP, the message formats that started with RFC 822, POP3,
and IMAP have survived against a large number of proprietary and
other SDO alternatives have been precisely because they operate
in plain text, with all but IMAP using very simple
command-argument or name:value syntax. Are we ready to give
that up? Do we really need interoperability between a server
and a captive Webmail interface? Arguably, standards of that
type are part of the province of the IETF only if someone is
contemplating generic webmail clients that can interact with the
servers of more than one organization.
(3) In terms of email models, this would presumably provides an
alternative to IMAP (or maybe POP3) on the mail receiving side.
Would it be equally sensible to define an IMAP extension that
would deliver responses (and maybe accept requests) in a
specified JSON format rather than the LISP-like IMAP one? Seems
to me that would promote much more compatibility and flexibility.
(4) Similarly, there is lots of practice about use of IMAP to
send. Is to time to make sure the standards for that
(presumably as an alternative to RFC 6409-style message
submission) and then provide a JSON format IMAP option to
support this form?
Again, just questions, but questions I think we need to ask
carefully before standardizing yet another alternative way to do
much the same thing.
john
--On Monday, November 07, 2016 17:31 +0000 Alexey Melnikov
<alexey(_dot_)melnikov(_at_)isode(_dot_)com> wrote:
Hi,
I am forwarding my email here, as I suspect people on these
two mailing lists might be interested in this.
Please post your comments/questions to dispatch(_at_)ietf(_dot_)org or
directly to me.
Best Regards,
Alexey
-------- Forwarded Message --------
Subject: Request to form a new WG: JMAP
Date: Mon, 07 Nov 2016 17:17:59 +0000
From: Alexey Melnikov <aamelnikov(_at_)fastmail(_dot_)fm>
To: DISPATCH <dispatch(_at_)ietf(_dot_)org>
Hi,
I have received a request to form a new WG: JSON Mail Access
Protocol
(JMAP). Draft charter is included below. Please send your
comments in
reply to this email or directly to me.
I am also looking for possible chairs for this work, so if you
are
interested, please contact me off-list.
Thank you,
Alexey
------------------------------------
Name: JSON Mail Access Protocol
Acronym: jmap
Area: Applications and Real-Time Area (art)
Charter for Working Group
Many companies and projects are developing their own JSON based
representations of email which 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 JMAP working group will specify an mechanism to allow
clients to
both view and send email from a server over a single stateless
HTTPS
channel with minimal round trips. The protocol will support
out-of-band signaling of changes, and will give mobile clients
significant benefits in terms of battery life and network
usage.
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 work of this group is limited to developing a protocol for
a client
synchronising data with a server. Any server-to-server issues
or
end-to-end encryption of messages are out of scope for this
working
group.
The working group will coordinate with the Security Area on
credential
management and authentication.
Input to working group discussions shall include:
- Internet Message Format
[RFC 5322]
- 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/]
- SMTP SUBMISSION
[RFC 4409]
- 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 which
supports stateless use, flood control and batched
operations.
- 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.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp