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

Cyrus Daboo <cyrus@daboo.name> Mon, 13 February 2012 15:21 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 A472521F8539 for <imap5@ietfa.amsl.com>; Mon, 13 Feb 2012 07:21:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.601
X-Spam-Level:
X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, SARE_RMML_Stock10=0.13, 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 h05LI-s8pxiJ for <imap5@ietfa.amsl.com>; Mon, 13 Feb 2012 07:21:07 -0800 (PST)
Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5C79221F850D for <imap5@ietf.org>; Mon, 13 Feb 2012 07:20:57 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id B71A021DBD61; Mon, 13 Feb 2012 10:20:56 -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 qXrwS8twprSh; Mon, 13 Feb 2012 10:20:52 -0500 (EST)
Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 897F421DBD56; Mon, 13 Feb 2012 10:20:51 -0500 (EST)
Date: Mon, 13 Feb 2012 10:20:45 -0500
From: Cyrus Daboo <cyrus@daboo.name>
To: Adrien de Croy <adrien@qbik.com>
Message-ID: <B764BD8C8B6047E659EABBE2@caldav.corp.apple.com>
In-Reply-To: <4F3835A1.7060804@qbik.com>
References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com>
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="2281"
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: Mon, 13 Feb 2012 15:21:15 -0000

Hi Adrien,

--On February 13, 2012 10:56:49 AM +1300 Adrien de Croy <adrien@qbik.com> 
wrote:

>> 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.
>>
>
> I don't think that's a workable approach.
>
> Getting such a protocol together, which enables notifications from any
> other application protocol I think will take a very long time, if it can
> even succeed.  It's hard enough getting consensus within one protocol
> working group, let alone all of them working together.
>
> Also every different protocol has different notification requirements.
> trying to cover all that in a single protocol I think would be difficult.

I disagree because what I envisage for the generic notification service is 
an OS-level api (supplied by OS or 3rd party libraries) that implement the 
"internet push service protocol". What that means is that client developers 
only have to implement a simple api to get push notifications. What is more 
anyone implementing more than one protocol in their client (e.g. IMAP, 
CalDAV and CardDAV) would only have to implement that once, albeit with 
some minor differences in regard to how to get protocol specific pieces for 
registering for notifications.

Your point about actually getting this done is valid. But realistically, do 
you really think IMAP5 is going to deploy overnight? Frankly, anyone who 
has a reasonably solid IMAP4 implementation today is going to question the 
need to work on something new, particularly if that something new brings 
nothing to the table (and simply fixing interop problems will probably not 
be seen as something "new"). If you can actually show that IMAP5 adds 
significant value by doing things like helping centralize push 
notifications, simplifying submission etc, then maybe, just maybe, those 
existing implementors might actually consider throwing out their current 
investment in IMAP4 for the new thing. But, IMHO, you are really going to 
have to up-sell IMAP5 to get buy-in from the major email providers. Now 
that does not mean it is not worth doing, but it does mean having to do 
more than just fixing perceived or real deficiencies.

-- 
Cyrus Daboo