Re: New imap ext to replace idle: IDLEPLUS ?

["M." Karpelès <karpeles@xxxxxxxxx>]

Hi,

Replying to myself, I found on google that some guy proposed the exact
same extension with the exact same name and got redirected to LEMONADE
WG.

I see that LEMONADE WG gave birth to NOTIFY [RFC5465], which seems to
accomplish the expected goal (except it is maybe too complex to
implement, while a "IDLEPLUS" command as described here and in
http://www.erfrakon.de/konold/draft-konold-imap-idleplus-05.txt could be
implemented with more ease).

Anyway please ignore this email.


Mark

Le samedi 26 juin 2010 à 19:18 +0900, M. Karpelès a écrit :
> Hi,
> 
> I initially didn't find the IETF WG for imapext, and submitted a draft
> as a independant individual.
> 
> The draft in question:
> 
> http://tools.ietf.org/html/draft-magicaltux-imap4-idleplus-01
> 
> Basically this came to me after I noticed a lot of clients connected on
> my imap server. I checked and found out that most common clients (apple
> mail, mozilla thunderbird, etc) will connect many times to IMAP servers
> to be able to idle in each folder (so they connect once per existing
> folder).
> 
> Since my imap server was also written by me I am familiar with RFC 3501
> and related (RFC 2177 for IDLE), and here is the idea: implement a new
> method for clients to get notified of messages in more than one folder,
> and of changes made by other clients (that's why I added the "STORED"
> event).
> 
> Since this is my very first time redacting and submitting a draft I'd
> like some feedback from experienced people. I don't think this is a bad
> idea especially nowaday where IDLE (commercially known as imap push) is
> heavily marketted, and people are relying on it.
> 
> For people already familiar with IDLE [RFC2177], here are the main
> differences with IDLEPLUS:
> 
> - All subscribed folders are monitored
> - Untagged responses contains the message UID and no longer the ID
> - Untagged responses contains the folder name
> - New untagged response STORED for flag changes (you read a message on a
> client, you instantly see it lose its "unread" status on the other)
> 
> 
> Mark Karpeles
>