Hi Dave
I agree with the things you've said about generic protocols, and trying
to fix all the worlds problems - e.g. scoping something too big to be
doable.
This all started when Brom sent an email around about a replacement
protocol for IMAP.
One of the main problems with the current suite of protocols used for
mail, is that even if one could implement them all, providing a better
user experience than Exchange or Gmail would not be the result.
Add to that the fact that specifying a new mail protocol is a heap of
work, the obvious question was why limit ourselves to only providing a
replacement.
Forever is a long time.
That's why I proposed a layered approach.
If you look at a mail client even like Thunderbird, which I'm using to
write this mail.
There are settings for:
SMTP: specification of server, choice of authentication method, choice
of security (SSL vs STARTTLS vs none), username and password.
IMAP: specification of server, choice of authentication method, choice
of security (SSL vs STARTTLS vs none), username and password.
LDAP: specification of server(s), choice of authentication method,
choice of security (SSL vs STARTTLS vs none), username and password.
If I want a calendar I need to add in something like Lightning (current
version not compatible with TB11), or something else. Presumably it
uses CalDAV, which goes over WebDAV which goes over HTTP, so I've got
credentials to deal with for that, and possibly some intermediary proxy
with credentials as well.
This all adds up to a complete clusterxxxx - it's an appalling user
experience, and supporting it is costly as well.
Any one of these settings if wrong is a support call. That's why I
proposed condensing all the choice of server, port, auth and security to
1 protocol, and layer the facilities on top. Even if all we did was
layer the existing protocols on top of this, we'd be a lot further ahead.
Last time I checked it was 2012. Email is supposed to be (or have been)
the "killer" internet application - the most important one.
To provide such a poor user experience is shameful. Especially after 30
odd years.
And of course I understand it's the result of an evolutionary process
over time. So of course it's messy and ugly.
But unless we do something about it, it will be that way forever, or
until someone in future deals with it. Or it gets replaced out from
under us by web-based services which are able to independently provide
an acceptable user experience.
Seems to me that in the context of discussion of a new mail protocol,
could be a good time to consider these things.
Hence the kitchen sink :)
Cheers
Adrien
On 16/02/2012 9:49 p.m., Dave Cridland wrote:
On Thu Feb 16 06:56:07 2012, Arnt Gulbrandsen wrote:
On 02/15/2012 11:25 PM, Dave Cridland wrote:
> This mailing list is "Discussion on drastically slimming-down
IMAP", and
> you've listed the properties of ACAP, SIEVE, IMAP, CalDAV, CardDAV
*and*
> Submission, and then thrown in a kitchen sink too.
As I see it, he's listed features which are in the Exchange protocol and
in the unnamed protocol spoken by gmail's javascript heap and its
mothership.
That makes them worthy of discussion.
I'm mostly revelling in the irony.
I know IETF dogma is that protocols shouldn't overlap. But it's a weak
kind of dogma: IMAP overlaps with POP, POP overlaps with Submission,
various IMAP extensions with ACAP and what's that about IMSP? I could
go on.
There's two huge problems with the approach.
Firstly, using a generic data model, or a generic protocol,
automatically produces compromise. I've learnt to mistrust genericity
in protocols - it all seems like such a lovely idea, and then
everything turns into the bastard offspring of SQL. And the thing with
SQL is that you can do useful things like indices and whotsits, which
let you specialize the data store, but nobody ever gets that far. The
only cases where this has worked is to partially specialize the
datastore - LDAP/X.500 does this, as did ACAP - but only one of those
has succeeded by any metric.
I'd note that, similarly, METADATA and ANNOTATE should have done well,
if it weren't for the fact they expanded beyond a simple dumping
ground for "everything else", and people tried to use them as the One
True Datastore.
Secondly, the broader the scope, the bigger the task - I don't see any
likelyhood of getting such a protocol sorted out before the end of the
decade, or beyond. The phrase "boil the ocean" springs to mind.
Remember, Exchange and the like are not successful because they do
calendaring and mail, they're successful because they seamlessly blend
calendaring and mail - the result is more than the sum of its parts,
but making that blend will not be easy.
Aside from anything else - you want configuration storage services in
$NEWPROTO? Well, I surely want these to have all the facilities that
ACAP gives me. Calendaring? I'm sure that Cyrus will want it to have
parity with, or exceed, CalDAV. Mail? There's any number of folk here
who'll want their own special sauce in. And they'd be right, from
their perspective, and the net result would be unimplementable.
Dave.
--
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
