Re: [imap5] Feature set? - was Re: Designing a new replacement protocol for IMAP

[Adrien de Croy <[e-mail]>]

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