Subject: Re: New imap ext to replace idle: IDLEPLUS ?
From: "M." Karpelès <[email-masked]>
To: [email-masked]
Date: Sat, 26 Jun 2010 19:31:46 +0900
List-Id: <ietf-imapext.imc.org>

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
> 

Subject: New imap ext to replace idle: IDLEPLUS ?
From: "M." =?ISO-8859-1?Q?Karpel=E8s?= <[email-masked]>
To: [email-masked]
Organization: ooKoo.org
Date: Sat, 26 Jun 2010 19:18:39 +0900
Sender: [email-masked]

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

Subject: Re: New imap ext to replace idle: IDLEPLUS ?
From: "M." =?ISO-8859-1?Q?Karpel=E8s?= <[email-masked]>
To: [email-masked]
Organization: ooKoo.org
Date: Sat, 26 Jun 2010 19:31:46 +0900
Sender: [email-masked]

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
> 

Subject: New imap ext to replace idle: IDLEPLUS ?
From: "M." =?ISO-8859-1?Q?Karpel=E8s?= <[email-masked]>
To: [email-masked]
Organization: ooKoo.org
Date: Sat, 26 Jun 2010 19:18:39 +0900
Sender: [email-masked]

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