Re: IDLEPLUS extension

[Martin Konold <martin.konold@xxxxxxxxxxx>]

Am Dienstag, 21. November 2006 10:56 schrieb Dave Cridland:

Dave,

> Clients won't miss a notification even on one channel

Thanks for the insight though I don't fully understand it. So understand my 
further questions.

I consider updating the text accordingly:

"In order to avoid the poll at half hour intervals the client may send another 
IDLEPLUS command before the older is timed out. In order to receive 
notifications out-of band a client may make sure that always an IDLEPLUS 
connection in addition to the normal imap data connection is established. 
Please note that an additional connection is not required in order not to 
miss any notifications. This is due to the fact that  the server queues the 
events until the client is idle.

> - the server 
> merely might not send them unless the client is IDLE, but the client
> will get them almost immediately anyway. 

C: A01 IDLEPLUS
S: + Idling
C: DONE
C: A02 COMMAND
C: A03 IDLEPLUS
S: A01 OK Completed
S: * DATA
S: A02 OK Command completed
S: + Idling

> Even if the client doesn't pipeline the A03 IDLE, no events get
> missed, merely delayed for a few seconds.

What happens in case of an extremly slow client? E.g. imagine the client is 
subscribed to a very busy shared folder. Will this cause the server side 
process to grow indefinetly because it will not be able to deliver the 
events? If I understand you correctly you mean that the server must 
internally queue any event in case later the client is requesting it via a 
IDLEPLUS command? How shall the server know if it will ever be able to 
deliver the queued event. I think it must be consider that even though the 
server implements the CAPABILITY IMAPPLUS it never knows if the client will 
ot will not eventually make use of it. Due to the fact that the syntax of 
IDLEPLUS is different from IMAP4r1 imho a server may not send these 
unsolicited notifications without being requested.

Is this a potential denial of service issue?

In addition the out-of-band solution using an additional IMAP connection would 
allow me to create a separate idleplusd server process which is specialized 
in only handling the idleplus functionality. This has the advantage of easier 
integration in exsting server offerings, better scalability and robustness.

> > Is anyone else working on something similar?
>
> As Mark says, the Lemonade WG is examining this kind of work at the
> moment. New people are always welcome and valuable, and while your
> draft is largely addressed by, for example, NOTIFY

I tried to figure out what the Lemonade WG is doing. I found 
draft-ietf-lemonade-msgevent-00.txt which is a high level description not 
proving anything which defines an extension which can be implemented 
currently. I am alos aware of 
draft-ietf-lemonade-notification-protocol-00.txt which is also a very high 
level corporate architecture document but does not adress the actual protocol 
to be implemented on the wire.

> > Any hints to a novice internet draft author?
>
> Implement it. No protocol or extension will ever get worse because
> someone implements it, the vast majority improve dramatically on
> their first implementation attempts.

Yes, I fully agree. Actually I am currently in the process of implementing it 
for Cyrus Imapd in order to learn more about it. I am also implementing it in 
an experimental IMAP client.

I already implemented lemonade drafts like 
draft-ietf-imapext-list-extensions-17. 

See also: https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2875

Do you think I should stop discussing IDLEPLUS or imap notifications on this 
mailing linst and instead move to the lemonade WG discussion list?

(I have some doubts with regards to the goals of the lemonade WG as I have the 
impression that they try to solve a different problem)

Yours,
-- martin

-- 
http://www.erfrakon.com/
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker