Re: [imap5] Designing a new replacement protocol for IMAP

Cyrus Daboo <cyrus@daboo.name> Fri, 10 February 2012 15:10 UTC

Return-Path: <cyrus@daboo.name>
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 0DE1A21F85A3 for <imap5@ietfa.amsl.com>; Fri, 10 Feb 2012 07:10:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.156
X-Spam-Level:
X-Spam-Status: No, score=-102.156 tagged_above=-999 required=5 tests=[AWL=-1.046, BAYES_05=-1.11, USER_IN_WHITELIST=-100]
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 3ukia5Xkljet for <imap5@ietfa.amsl.com>; Fri, 10 Feb 2012 07:10:01 -0800 (PST)
Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 363B821F859F for <imap5@ietf.org>; Fri, 10 Feb 2012 07:10:01 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 4339221BAAEE; Fri, 10 Feb 2012 10:10:00 -0500 (EST)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qu272O3v9Lfs; Fri, 10 Feb 2012 10:09:54 -0500 (EST)
Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id A2F1421BAAE3; Fri, 10 Feb 2012 10:09:53 -0500 (EST)
Date: Fri, 10 Feb 2012 10:09:48 -0500
From: Cyrus Daboo <cyrus@daboo.name>
To: thomas@koch.ro, Adrien de Croy <adrien@qbik.com>
Message-ID: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com>
In-Reply-To: <201202101544.51364.thomas@koch.ro>
References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro>
X-Mailer: Mulberry/4.1.0a3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size="1181"
Cc: imap5@ietf.org
Subject: Re: [imap5] 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: Fri, 10 Feb 2012 15:10:02 -0000

Hi Thomas,

--On February 10, 2012 3:44:50 PM +0100 Thomas Koch <thomas@koch.ro> wrote:

>> * updates.  Would need to poll or use long polling to get real-time
>> updates (e.g. notification of incoming mail).
> Could Websockets or http://en.wikipedia.org/wiki/Comet_(programming) be
> of  help here?

For CalDAV and CardDAV we (Apple, http://calendarserver.org) have used XMPP 
pubsub and our own APNS to implement a push notification service. Frankly I 
think the IETF should have developed a proper notification protocol for use 
alongside other protocols a long time ago - simply "blessing" XMPP pubsub 
as the solution for that would be fine from a standards point, but perhaps 
something else (new) coukld be done too. What then needs to be defined are 
the hooks in each underlying protocol to allow clients to discover the 
appropriate pubsub service. In CalDAV/CardDAV that is simply done using 
WebDAV properties to advertise the essential client push configuration.

So, in my opinion, whilst push notifications should be a requirement for 
imap5, we should not define that protocol and instead push the IETF to 
provide such a protocol for general use.

-- 
Cyrus Daboo