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

[John C Klensin <[e-mail]>]

Ned,

A few questions about some of your comments (again, just
questions);

--On Wednesday, November 09, 2016 07:15 -0800 Ned Freed
<[e-mail]> wrote:

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

Which design model are you talking about?   It seems to me that
the original specs (through and including RFC 1064 and IIR 1176)
had only what we now call online mode and was optimized for
"kiosk" uses.  With the exception of the "walk up to someone
else's shared machine" part, that seems very similar to what we
have today with the assumption that everything is on the server,
the client keeps messages only on a transient basis, and one
cannot access messages unless one is online.    It seems to me
that is not very different from where we are headed now, whether
via "dumb MUA" or "MUA implemented on a web interface".   It may
be more complex than needed because it contains some
optimizations are what, by today's standards, are low-bandwidth
environments but some of those features also have security
advantages (that we haven't talked about very much recently).

Now, when we added offline (simulated POP3 on steroids) and
disconnected modes with IMAP4, things got more complex.  From my
personal perspective, disconnected mode (more or less the
ancient PCMAIL model) is the only thing that makes sense for
people with poor or intermittent connectivity, especially if
they need to work offline sometimes and use multiple machines.
However, it has never been broadly and well-supported in MUAs
(there are, IMO, a few "good enough" MUA implementations but no
really good ones) so maybe the marketplace has told us there
aren't enough users to count.  

Now, I've never been a fan of the LISP-like command and response
syntax, but that is much more a matter of taste than
functionality.

> (I note that the problem SMTP is intended to solve hasn't
> changed nearly as much.)

I agree with you but have heard claims that the multiple relay
and alternate destination (mail exhannge) models have outlived
their usefulness in today's highly-connected Internet.  I don't
see things as that highly connected (even looking to the future,
SMTP would work much better in the presence of a DTN than, e.g.,
HTTP[S} and for much the same reason it worked well for delivery
servers that were only connected a few hours a week) and I think
the robustness those features enable as important.  However,
there is no disputing that mail transport could be considerably
simplified if we allowed only endpoint-to-endpoint connections
with no alternatives.  Such connections would also permit
straightforward feature negotiation.  That would be a big help
for, e.g., EAI/SMTPUTP8 and similar arrangements and might even
help blur the boundary between transport-level and end0t9-end
encryption.

>  Getting rid of historical baggage will definitely simplify
things.

But that is my question.  I don't see IMAP disconnected mode as
historical baggage.  We've ended up with some redundant ways to
do things as a result of newer and more powerful options and
commands and the old ways could be cleared out.   We could
probably make some different choices about data structures and
maybe even standardize some things that today just add to the
complexity of the options.  But I'm not sure how significant
those actually would be -- what are you thinking of?

> IMAP also uses an unnnecessarily large number of format
> variants.

Yes.  See above.
 
> 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.

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

But, unless we can get rid of IMAP (and some of the
functionality, like disconnected mode, that can't obviously be
supported over a purely HTTPS/JSON interface) entirely, it seems
to me that an HTTPS/JOSN approach is additive, requiring the
mail environment to support both it and IMAP for (at least) a
very long time.  So, while I agree with your guess, I don't see
the need to support an additional as a net gain, especially in
the short to medium term.

   john