IETF Logo Mail Archive

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

Dave Cridland <dave@cridland.net> Thu, 16 February 2012 19:52 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 4F26221F86A0 for <imap5@ietfa.amsl.com>; Thu, 16 Feb 2012 11:52:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.418
X-Spam-Level:
X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 d8noXmLjaMkr for <imap5@ietfa.amsl.com>; Thu, 16 Feb 2012 11:52:37 -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 43FA121E8094 for <imap5@ietf.org>; Thu, 16 Feb 2012 11:52:37 -0800 (PST)
Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 5F08A1168087; Thu, 16 Feb 2012 19:52:36 +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 5sSd18KGRfsn; Thu, 16 Feb 2012 19:52:32 +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 334001168067; Thu, 16 Feb 2012 19:52:32 +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><307.1329382177.374908@puncture> <4F3CCA6C.3020004@qbik.com> <3077.1329386263.642278@puncture> <1329386650.31621.140661037282969@webmail.messagingengine.com> <3077.1329387922.639535@puncture> <340DCA8DBA39E16EA1E0835C@caldav.corp.apple.com>
In-Reply-To: <340DCA8DBA39E16EA1E0835C@caldav.corp.apple.com>
MIME-Version: 1.0
Message-Id: <3077.1329421952.185715@puncture>
Date: Thu, 16 Feb 2012 19:52:32 +0000
From: Dave Cridland <dave@cridland.net>
To: Cyrus Daboo <cyrus@daboo.name>, Bron Gondwana <brong@fastmail.fm>, 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 19:52:38 -0000

On Thu Feb 16 15:34:57 2012, Cyrus Daboo wrote:
> Hi Dave,
> 
> --On February 16, 2012 10:25:22 AM +0000 Dave Cridland  
> <dave@cridland.net> wrote:
> 
>>> Which is a vote from me for "yes, SRV option makes sense".
>> 
>> Oh, totally agree. Discovery is awesome, user-configuration is  
>> insane. I
>> don't see there's any valid argument the other way.
> 
> Practical experience with SRV has shown that, whilst it is fine for  
> large service providers to do that sort of thing (c.f., Google,  
> iCloud etc), the practicalities of actually being able to setup SRV  
> records and have proper SSL cert validation is heard, particularly  
> for "hosted domain" type applications.
> 
> 
I agree with what you're saying, but I think it's getting  
substantially easier as time goes on.

It used to be a rarity for XMPP services to have SRV records, and  
very rare to have them relied upon, but it's now commonplace, and the  
numbers of systems that require SRV resolution for them to be  
reachable is increasing.


> Having discussed with several engineers who have implemented SRV it  
> is clear that having each app do it separately is problematic  
> because there are a bunch of awkward issues. Not in the least is  
> the simple issue of even getting SRV from standard DNS libraries  
> (e.g. one Android developer mentioned that the size of his app  
> increased significantly when he had to bring in libraries to do  
> SRV). Then there is all the certificate verification stuff that  
> needs to be done to properly implement discovery. Overall this is  
> much harder than it needs to be, and other non-standard approaches  
> have proved that.

Again, I think SRV resolution in software is increasingly common, and  
becoming generally easier.

It used to be next to impossible in many environments, whereas it's  
now merely awkward.

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

v2.23.0 | Report a Bug | By Email