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

Dave Cridland <dave@cridland.net> Thu, 16 February 2012 10:41 UTC

Return-Path: <dave@cridland.net>
X-Original-To: imap5@ietfa.amsl.com
Delivered-To: imap5@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627A321F876D for <imap5@ietfa.amsl.com>; Thu, 16 Feb 2012 02:41:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.422
X-Spam-Level:
X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpzlfHNAF2l0 for <imap5@ietfa.amsl.com>; Thu, 16 Feb 2012 02:41:52 -0800 (PST)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id ACB3721F8770 for <imap5@ietf.org>; Thu, 16 Feb 2012 02:41:51 -0800 (PST)
Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id AA6EA1168087; Thu, 16 Feb 2012 10:41:47 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net
Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzmdzyMBeKLI; Thu, 16 Feb 2012 10:41:39 +0000 (GMT)
Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 643411168067; Thu, 16 Feb 2012 10:41:39 +0000 (GMT)
References: <B764BD8C8B6047E659EABBE2@caldav.corp.apple.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <alpine.LSU.2.00.1202151405550.30682@hermes-2.csi.cam.ac.uk> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <4F3BC7DA.5070803@gulbrandsen.priv.no> <20120215181047.GB13906@launde.brong.net> <alpine.OSX.2.00.1202151020140.38441@hsinghsing.panda.com> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> <4F3CA887.9050509@gulbrandsen.priv.no> <3077.1329382177.374908@puncture> <4F3CCA6C.3020004@qbik.com> <3077.1329386263.642278@puncture> <4F3CD728.3010203@qbik.com>
In-Reply-To: <4F3CD728.3010203@qbik.com>
MIME-Version: 1.0
Message-Id: <3077.1329388899.383165@puncture>
Date: Thu, 16 Feb 2012 10:41:39 +0000
From: Dave Cridland <dave@cridland.net>
To: Adrien de Croy <adrien@qbik.com>, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>, "Discussion on drastically slimming-down IMAP." <imap5@ietf.org>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Subject: Re: [imap5] Feature set? - was Re: Designing a new replacement protocol for IMAP
X-BeenThere: imap5@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion on drastically slimming-down IMAP." <imap5.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imap5>, <mailto:imap5-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imap5>
List-Post: <mailto:imap5@ietf.org>
List-Help: <mailto:imap5-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imap5>, <mailto:imap5-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Feb 2012 10:41:57 -0000

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.


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

I wouldn't worry too much about ACAP anyway - even I think it's  
dead-end. The key portions could be slammed into almost any other  
convenient protocol, and it's one case where I think bolting it onto  
an existing protocol makes sense.

This wasn't the case when it was the only viable solution for  
handling address books, mind, and you'd lose the multi-account  
capability, but I think people are basically OK with such things now.


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

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

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.

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.

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