Re: [Imap-protocol] If Crispin were creating IMAP today how would it be different?

Ladar Levison <[email protected]> wrote:

> On 3/7/2015 8:34 AM, Dave Cridland wrote:
> > But in the world of today, the elephant is that the bulk of mail is
> > under the control of a handful of huge providers, and a guy working in
> > a university lab somewhere is pretty unlikely to have the chance to
> > make any kind of difference, and probably wouldn't be interested.
> > Mark, in his twenties, tended to solve practical problems that he
> > encountered, like telnet issues, roaming mail users, etc. Those
> > problems are already solved, so I suspect he'd be solving some
> > entirely different problem today, like WebRTC signaling, or practical
> > end to end crypto, or secure file sharing, or heaven only knows what.
> 
> If all those big providers were using POP, and he wanted to solve a
> problem, like mobility, would he have approached it differently?

Mobility is more of a fact than a problem?  What's the particular
problem there?  Multiple end-points?  Intermittent connections?

> From an abstract standpoint, the programming language doesn't
> matter. IMAP is a protocol that can be implemented in any language,
> which holds true for JSON protocols as well.

Well...  JSON stands for "Javascript Object Notation", so Javascript
does have a bit of an alpha status there.  And it's harder to parse
than S-expressions :-).

> They are simply schemes for stateless client/server interactions
> (stateless because they have to go over HTTP)

There's no intrinsic reason things that have to go over HTTP have to be
stateless; it's just a tradition that comes from the now somewhat
archaic idea in HTTP 1.0 that you close the session identifier (the TCP
connection) after each request/response pair.  Sessions were almost
immediately re-defined via cookies, and many protocols over HTTP
are now stateful, using those cookies.

> and which happen to use JSON as the serialization scheme. They could
> just as easily have used SOAP/XML.

Yes.  However, SOAP, as it was originally designed by Microsoft, is a
pretty (IMO) bletcherous (i.e., tasteless) and bloated attempt to funnel
DCOM calls through firewalls in a way that wouldn't be immediately
interdicted by anti-virus software.  So, a LISP person wouldn't be able
to bring himself to use it (speaking as a former Lisp and RPC person).

JSON over HTTP is a somewhat (but not much) cleaner re-interpretation
of the same idea.

> I'm wondering if the future of mail protocols is to continue improving
> the line based protocols we have, or will they be replaced by something
> that is friendly to the web? Were seeing a number of vendor specific
> mail protocols already, and I'm wondering if convergence is in our
> future? In other words, if someone were to start working on a new
> protocol today, should they focus on the old line based scheme, or
> switch to the newer stateless, JSON paradigm common to the web?

JSON is just a Javascript convenience.  It's not a particularly
efficient way of sending data over the network.  I think your question
about line-based protocols is a good one, but the IETF still leans
towards observable-text based protocols.  So, if you wanted to design
an email protocol that would be blessed by the IETF, using a text-based
"line" protocol isn't a bad idea.

Personally, I'd do everything in binary, but that's just me obsessing
about packet sizes.  I'm thinking about designing a secure email
protocol built on CCNx (http://www.ccnx.org/), which provides digital
signatures, encryption, and router caching.  There's no concept of
a "connection" at all, or a "mail server"; just messages.  That's
the future.

Bill
_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol