Re: IDLEPLUS extension
Martin Konold <martin.konold@erfrakon.de> Tue, 21 November 2006 11:07 UTC
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kALB7ehc044480; Tue, 21 Nov 2006 04:07:40 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kALB7epG044479; Tue, 21 Nov 2006 04:07:40 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kALB7csu044471 for <ietf-imapext@imc.org>; Tue, 21 Nov 2006 04:07:39 -0700 (MST) (envelope-from SRS0=Qu+Q=FB=erfrakon.de=martin.konold@srs.kundenserver.de)
Received: from [84.160.156.59] (helo=noname) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1GmTT70iLG-0007V9; Tue, 21 Nov 2006 12:07:16 +0100
From: Martin Konold <martin.konold@erfrakon.de>
Organization: erfrakon
To: Dave Cridland <dave@cridland.net>
Subject: Re: IDLEPLUS extension
Date: Tue, 21 Nov 2006 12:07:09 +0100
User-Agent: KMail/1.9.5
Cc: ietf-imapext@imc.org
References: <200611210130.28311.martin.konold@erfrakon.de> <31755.1164103010.550395@peirce.dave.cridland.net>
In-Reply-To: <31755.1164103010.550395@peirce.dave.cridland.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200611211207.10500.martin.konold@erfrakon.de>
X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b04c3ed30b43fd5a3d557b6dbc75a710
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>
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
- Re: IDLEPLUS extension Martin Konold
- Re: IDLEPLUS extension Martin Konold
- Re: IDLEPLUS extension Cyrus Daboo
- Re: IDLEPLUS extension Arnt Gulbrandsen
- Re: IDLEPLUS extension Arnt Gulbrandsen
- Re: IDLEPLUS extension Martin Konold
- Re: IDLEPLUS extension Dave Cridland
- Re: IDLEPLUS extension Martin Konold
- Re: IDLEPLUS extension Martin Konold
- Re: IDLEPLUS extension Dave Cridland
- Re: IDLEPLUS extension Martin Konold
- Re: IDLEPLUS extension Dave Cridland
- Re: IDLEPLUS extension Dan Karp
- Re: IDLEPLUS extension Mark Crispin
- IDLEPLUS extension Martin Konold