From notifications-bounces@ietf.org Tue Jan 10 02:10:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwDeg-0007Do-BJ; Tue, 10 Jan 2006 02:10:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwDec-0007CE-On; Tue, 10 Jan 2006 02:10:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09803; Tue, 10 Jan 2006 02:09:29 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwDlG-00079p-Bj; Tue, 10 Jan 2006 02:17:42 -0500 X-IronPort-AV: i="3.99,349,1131339600"; d="scan'208"; a="25728929:sNHT60171408" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Jan 2006 02:10:34 -0500 Message-ID: <330A23D8336C0346B5C1A5BB1966664701F542C0@ATLANTIS.Brooktrout.com> Thread-Topic: Simple Message Notification Protocol (was RE: [lemonade] draft-ietf-lemonade-imap-sieve-00) Thread-Index: AcYIGDugRUkyC6xeS8mG2MKMTAW32QNi1Hsw From: "Burger, Eric" To: "Dave Cridland" , "Mark Crispin" X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: quoted-printable Cc: lemonade@ietf.org, notifications@ietf.org Subject: [Notifications] Simple Message Notification Protocol (was RE: [lemonade] draft-ietf-lemonade-imap-sieve-00) X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: notifications-bounces@ietf.org Errors-To: notifications-bounces@ietf.org [Copied to Notifications] On the concrete level, text describing this "simple protocol" would be welcome. A quick draft or pointer to a document somewhere would help the discussion. On the abstract level, would the 'notifications' community be happy with a protocol that 'just works for messaging' (note I did not say IMAP in particular), or does it have to work for 'everything'? -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On Behalf Of Dave Cridland Sent: Friday, December 23, 2005 6:11 PM To: Mark Crispin Cc: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] draft-ietf-lemonade-imap-sieve-00 On Fri Dec 23 22:19:24 2005, Mark Crispin wrote: > On Fri, 23 Dec 2005, Curtis King wrote: >> The simplest way to get notifications is have a new notification=20 >> protocol which IMAP servers, clients, sieve scripts, and out-band=20 >> push notifications can all use. This is simple to implement, no=20 >> extensions needed to IMAP, can reuse existing notification=20 >> technologies, etc. >=20 > I agree. >=20 >=20 Yes, same. The tricky bit is that IMAP servers need to implement=20 this, when the mail server package as a whole may already support=20 Sieve, and there are also multiple Sieve implementations available=20 easily. Arguably, adding some form of Sieve support to IMAP - possibly=20 including adding Sieve test or scripts as a SEARCH criterion -=20 effectively adds one item of bloat to IMAP, and passes the entire=20 problem onto Sieve implementors, who're working hard and actively to=20 develop Sieve, and solve many of the problems that IMAP would benefit=20 from being solved. (I phrase this in this awkward way to avoid you=20 thinking I mean "IMAP will die..." - because it won't. But it would=20 be better.) To give an example, I've yet to find a conclusive, efficient, method=20 of searching for messages with parts of a particular type without=20 searching for strings likely to be found in the type's content, and=20 then recutting the search locally - that's painful. The better=20 alternative is to use Sieve, but that's only available at the point=20 of delivery, so the method ends up being "tag mails with a user=20 defined flag on delivery, hope that this is done before we actually=20 need to find those parts". I'm not a huge fan of methods which=20 include the word "hope". Extending SEARCH to allow for Sieve would solve this, and every issue=20 Cyrus raised in his point 1. That all said, I think the interesting uses of Sieve are in=20 post-delivery filtering and SEARCH, and not notifications. >> I do believe you and Lyndon have suggested this before. I'm very=20 >> curious why there is no interest in implementing such a service? >=20 > I am interested in implementing such a service. >=20 >=20 I'm sort of. I think that developing a generalized notification=20 service is tricky. I think that developing a method for the IMAP=20 server to be made to issue notifications (on IDLE or NOOP) might be=20 possible. > In 2002, I even implemented a prototype of such a service. It was=20 > a nice, sweet protocol, easy to implement. What's more, it had=20 > working code. >=20 > I'm not the only person to have done something like this, either. >=20 >=20 The outline you kindly sent me in private mail had one line in it=20 that greatly interested me. You said, and I'm not quoting, something along the lines of using=20 URLAUTH as an authentication-by-proxy for notification access. I mentioned this in passing to Philip Guenther, and between us (but=20 mostly Philip), we arrived at the following concept: [Note this uses=20 Magic in the approved sense of non-IETF] 1) Client requests from GENURLAUTH some form of URL not currently=20 supported, such as SEARCH URLs, mailbox URLs, LIST URLs, etc. Server=20 signs these and returns. 2) Client hands these via Magical Means to a Magic Notification=20 Server. The interesting thing here is that said Magical Means might=20 be SMS, WAP, or TCP. (Mark's implementation is TCP, in fact). 3) Said Magic Notification Server then hands these to IMAP server,=20 using them to request notifications. These notifications are=20 content-free, much like existing in-band IMAP notifications. Should a=20 client which finally receives, or at least responds to, these=20 notifications require content, it must connect, authenticate, and=20 retrieve the content normally. This means that the nasty hideous part of notifications - that is,=20 actually getting the notifications to the client - is actually placed=20 neatly well out of scope of the servers. Thus a Magic Notification=20 Server could be provided by a mobile network operator, or a=20 mailserver ISV. Or even both, covering different actualy notification=20 protocols. The IMAP extensions needed are fairly minimal - yes, we're extending=20 the protocol, but we're not spending as much time extending the=20 software required. > The problem is that every time someone tries to produce a write up=20 > of such an effort, everybody immediately starts making the spurious=20 > "if protocol does not have functionality, then will=20 > die" argument to press to add everything but the kitchen sink. =20 > Each time this happens, the guy who did the work decides "I don't=20 > need this headache" and drops it. >=20 > This is, sadly, a systemic problem throughout the IETF. No, there's a worse systemic problem, but that involves the creation=20 of new protocols within the IETF. I think what you describe is merely=20 a minor symptom of it. But that's another story for another time. For now, Merry Christmas for those that intend getting merry, Happy=20 Yule for those willing to be happy, and best wishes for the new year,=20 for those that actually have a new year at roughly this time. Dave. --=20 You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications