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

[Adrien de Croy <[e-mail]>]

On 11/02/2012 4:09 a.m., Cyrus Daboo wrote:
> Hi Thomas,
>
> --On February 10, 2012 3:44:50 PM +0100 Thomas Koch <[e-mail]> 
> 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.
>

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.

Finally, one of the things I am keen to see disappear with IMAP5 (for 
want of a better name) is the requirement for clients, admins etc to 
deploy multiple protocols - e.g. allow submission in IMAP.  This is 
because it's frankly a large (and should be unnecessary) admin burden 
trying to support 2 protocols for mail (e.g. SMTP + POP3/IMAP4).  Mail 
users don't understand the significance, they just submit support 
tickets because they can retrieve mail but not send.  Firewalls block 
ports, ISPs intercept / block port 25 (NZ largest ISP does this), 
multiple protocols = multiple realms for credentials, multiple 
implementations of authentication and authorization etc.

Having to have another protocol to implement to get notifications back 
probably over another channel etc makes this issue worse not better.

Adrien

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/