On 11/02/2012 4:09 a.m., Cyrus Daboo wrote:
Hi Thomas,
--On February 10, 2012 3:44:50 PM +0100 Thomas Koch <[email protected]>
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/
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
