On 2/8/2017 1:16 PM, Ted Lemon wrote:
On Feb 8, 2017, at 4:08 PM, Alexey Melnikov
<alexey(_dot_)melnikov(_at_)isode(_dot_)com
<mailto:alexey(_dot_)melnikov(_at_)isode(_dot_)com>>
wrote:
Neil Jenkins did a very good summary of existing problems and how
JMAP is trying to improve over IMAP:
<https://www.ietf.org/mail-archive/web/imapext/current/msg05820.html>
Wow, this is _really_ useful. Thank you for pointing it out.
Sure is.
This, and Pete's note, have finally given me enough to be able to
suggest specific changes to the charter.
The underlying concern I've been pressing is that a working group
charter needs to make its case in pragmatic terms, with enough detail to
aid someone who is not already onboard to assess the proposed effort.
So I suggest replacing:
A number of JSON-based representations of email have been developed
that are proprietary, non-standard, and incompatible with each other.
...
The JMAP working group will specify a mechanism to allow clients to
both view and send email from a server over a single HTTPS
channel with minimal round trips. A single protocol for receipt and
...
with:
JMAP specifies the interactions between email clients and mail
stores, providing an alternative to IMAP and SMTP submission. JMAP
allows clients to both view and send email via a server, over a
single HTTPS channel, with significantly reduced computational and
communication resource consumption.
>
Currently it is difficult to write a good MUA using standards; it is
especially problematic for embedded web clients. IMAP suffers the
combination of semantic bottleneck and leakage: It constrains the
semantics that can be communicated across the pipe in some ways
(hence the myriad of extensions required to have a workable IMAP
implementation), but leaks various server-specific semantics (e.g.,
the storage model, the constraints on network resources) through to
the client instead of having a clean protocol. Further, the protocols
perform poorly over constrained channels.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net