Re: [imapext] [ietf-smtp] Fwd: Request to form a new WG: JMAP

[Ned Freed <[e-mail]>]

> > 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, ... because they operate
> > in plain text, ...

> I thought JSON was 7-bit, and required encoding to use 8-bit data portable.

JSON is almost always UTF-8. So no, it's unabashedly 8-bit. But so is 
the overwhelming major of the existing email infrastructure, so this is 
a wash.

> So, if I am correct, then JSON is not a gain when it comes to non-text data?

This is also a wash.

Binary MIME has been around for almost 25 years. SMTP was extended to
handle it not long after it was defined. And note that it's entirely
possible to use binary MIME only on SUBMIT and not depend on the
rest of the infrastructure handling it.

IMAP has had the ability to transfer parts in binary for a long time. And
IMAP also offers the ability to decode and transfer a encoded part on
the server side.

JSON doesn't support binary, but there are various extensions that do.

> > (3) ...  Seems
> > to me that would promote much more compatibility and flexibility.

> The complexity of the requests and replies are the issue. If its mostly
> converting IMAP to JSON, the same problems are going to exist.

Yes and no. Part of the problem with IMAP is that it was designed for
a very different sort of client than what we have now. (I note that the
problem SMTP is intended to solve hasn't changed nearly as much.) Getting
rid of historical baggage will definitely simplify things.

IMAP also uses an unnnecessarily large number of format variants.

OTOH, there's absolutely no doubt that there's considerable intrinisic
complexity in the message access space. Especially given the desire to
push more and more of the problem to the server.

On the flip side, basing things on HTTPS adds an enormous amount of inherent
complexity. But most of that complexity is hidden from the majority of
developers, who won't code HTTPS support directly, preferring instead to
use any one of the bazillion libraries out there that does it all for you.

My guestimate is that - and here I'm speaking only of the message access space
- that a HTTPS/JSON approach wins in terms of effective implementation
complexity, although it is far from clear to me by how much.

				Ned