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

[Dave Cridland <[e-mail]>]

On Thu Feb 16 10:58:51 2012, Adrien de Croy wrote:
> 
> 
> On 16/02/2012 11:41 p.m., Dave Cridland wrote:
>> On Thu Feb 16 10:15:04 2012, Adrien de Croy wrote:
>>> But SRV has issues, not every corporate runs their own DNS (at  
>>> least not for external).
>>> 
>>> 
>> Well, tough. There is a point at which we have to assume people  
>> will have to fix things. XMPP services get this fixed pretty  
>> quick, and mail is a much bigger juggernaut.
>> 
>> 
> how many corporates deploy XMPP services?
> 
> 
Approaching 10% and growing, at least by some metrics:

http://eggert.org/meter/xmpp.html


> SRV is great, but it's only marginally better than ACAP in terms of  
> conifguration points.  You still need a domain.  What happens when  
> you're using hosted mail?  Does your mail host have to give you a  
> sub-domain so you can have your own SRV record to point to your own  
> ACAP server to get your mail config?
> 
> 
You've gone off on one.

If you have a mail domain, then you can put in SRV records to point  
to the servers. If you use another mail domain, then they do that for  
you.


> How many points of failure there?
> 
> 
Lots - but no fewer than without. Unless you think that SRV might  
break when the rest of the DNS doesn't. I don't think that's been an  
issue for the past decade or so.


> That's why I keep going back to the 1 port like a broken record.   
> Maybe it should just be an SSH tunnel... but that;s back-pedalling  
> quickly and reducing potential user experience with it.
> 
> 
No, I think it's an orthogonal issue.



>>> ACAP is great too, but it's another port and set of creds.  And  
>>> the tie-in between ACAP and other services is probably manual on  
>>> the back-end right?
>>> 
>>> 
>> What tie-in? ACAP's just a simple store. The enhancement to the  
>> client is that a sysadmin can preconfigure the clients, and ACAP  
>> gives a bunch of wacky data inheritance tricks to make this easy.
> 
> as I said - manual.  You have to type in the settings, the IMAP  
> server can't publish them automatically to the ACAP server.
> 
> 
Oh, right.

Well, yes, it *can* - both WorldMail and CommuniGate work(ed) in this  
manner.

But given the sysadmin has to make precisely one STORE command on a  
real ACAP server, it's a bit of a non-issue - it no more manual than  
setting up any other server.

>>> Xtra is NZ's biggest ISP.  It blocks port 25.  So when I take my  
>>> laptop home I need to reconfigure it.  At least I know how to do  
>>> that.
>>> 
>>> 
>> Why would blocking port 25 be a problem? Unless you're running an  
>> MTA on your laptop, in which case you're presumably savvy-enough  
>> to deal with the consequences.
> 
> there are a myriad of reasons.  My MTA is Thunderbird.  At work, I  
> have my mail set to send to smtp.qbik.com with creds.  When I take  
> my laptop home, I can't connect any more.  I have to send my mail  
> through the ISP mail server.  Some companies don't like this.  Some  
> users have trouble configuring this.  We do actually get support  
> tickets created by this particular issue.
> 
> You go to a hotel, same issue.
> 
> Some companies use SPF as well, so mail starts to bounce when you  
> can't use your corporate MTA to send.
> 
> 
Right, sure, understood (after s/MTA/MUA/) but what has port 25 got  
to do with it?

>>> We're techies here, we forget how lost and confused the punters  
>>> get.
>> 
>> No matter how good the protocols involved are, it comes down to  
>> how good the deployment and implementations are. The client is the  
>> punter-facing component, and without good clients you're shot  
>> whatever you do.
>> 
> absolutely.  But good clients can be impossible to achieve if the  
> protocols don't allow it.
> 
>> To get "good" clients, you need mind-share, and you'll only get  
>> that if you start off with the status quo and figure out where to  
>> go - or if you base on another preexisting framework. Lots of folk  
>> are doing this very successfully with the web, of course, but I  
>> think there are other options, too.
> 
> Microsoft abandoned it all and wrote Exchange.  So did GMail.
> 
> 
GMail did it with the web - preexisting framework. Then they  
leveraged the deployed base of mobile IMAP clients - preexisting  
framework.


> They can afford to do that.  We aren't MS or Google.
> 
> 
Apparently not...


> Why do you think they did that?  Exchange server was delayed for  
> years.  It cost them.  But now it's almost the only game in town.
> 
> 
Exchange was largely an X.400 system, until recently. Again, they  
didn't make any real attempt to reinvent the wheel.

What they did do was carefully market it - Outlook was a very nice  
client, and it came free with Office, and only really worked  
tolerably with Exchange - where it worked really quite well. So they  
managed to leverage from Windows to Office, and from Office to  
Exchange.

The fact that it's a monolithic protocol has little to do with it.



>> All this talk of a boil-the-ocean brave-new-world is great fun,  
>> I'll be the first to admit, but I really don't see how it gets us  
>> anywhere useful.
> 
> I prefer my ocean at ATP.
> 
> We could just talk about what could be stripped out of IMAP.  But I  
> don't really see how that would get us anywhere useful either.

Sure.

What we need to do is identify the core problems to be solved,  
instead of finding solutions and trying to figure out how to use them.

But it's not nearly as much fun.

Dave.
-- 
Dave Cridland - mailto:[e-mail] - xmpp:[e-mail]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade