[Notifications] Simple Message Notification Protocol (was RE: [lemonade] draft-ietf-lemonade-imap-sieve-00)

["Burger, Eric" <[e-mail]>]

[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: [e-mail] [mailto:[e-mail]] 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 
>> protocol which IMAP servers, clients, sieve scripts, and out-band 
>> push notifications can all use. This is simple to implement, no 
>> extensions needed to IMAP, can reuse existing notification 
>> technologies, etc.
> 
> I agree.
> 
> 
Yes, same. The tricky bit is that IMAP servers need to implement 
this, when the mail server package as a whole may already support 
Sieve, and there are also multiple Sieve implementations available 
easily.

Arguably, adding some form of Sieve support to IMAP - possibly 
including adding Sieve test or scripts as a SEARCH criterion - 
effectively adds one item of bloat to IMAP, and passes the entire 
problem onto Sieve implementors, who're working hard and actively to 
develop Sieve, and solve many of the problems that IMAP would benefit 
from being solved. (I phrase this in this awkward way to avoid you 
thinking I mean "IMAP will die..." - because it won't. But it would 
be better.)

To give an example, I've yet to find a conclusive, efficient, method 
of searching for messages with parts of a particular type without 
searching for strings likely to be found in the type's content, and 
then recutting the search locally - that's painful. The better 
alternative is to use Sieve, but that's only available at the point 
of delivery, so the method ends up being "tag mails with a user 
defined flag on delivery, hope that this is done before we actually 
need to find those parts". I'm not a huge fan of methods which 
include the word "hope".

Extending SEARCH to allow for Sieve would solve this, and every issue 
Cyrus raised in his point 1.

That all said, I think the interesting uses of Sieve are in 
post-delivery filtering and SEARCH, and not notifications.


>> I do believe you and Lyndon have suggested this before. I'm very 
>> curious why there is no interest in implementing such a service?
> 
> I am interested in implementing such a service.
> 
> 
I'm sort of. I think that developing a generalized notification 
service is tricky. I think that developing a method for the IMAP 
server to be made to issue notifications (on IDLE or NOOP) might be 
possible.


> In 2002, I even implemented a prototype of such a service.  It was 
> a nice, sweet protocol, easy to implement.  What's more, it had 
> working code.
> 
> I'm not the only person to have done something like this, either.
> 
> 
The outline you kindly sent me in private mail had one line in it 
that greatly interested me.

You said, and I'm not quoting, something along the lines of using 
URLAUTH as an authentication-by-proxy for notification access.

I mentioned this in passing to Philip Guenther, and between us (but 
mostly Philip), we arrived at the following concept: [Note this uses 
Magic in the approved sense of non-IETF]

1) Client requests from GENURLAUTH some form of URL not currently 
supported, such as SEARCH URLs, mailbox URLs, LIST URLs, etc. Server 
signs these and returns.

2) Client hands these via Magical Means to a Magic Notification 
Server. The interesting thing here is that said Magical Means might 
be SMS, WAP, or TCP. (Mark's implementation is TCP, in fact).

3) Said Magic Notification Server then hands these to IMAP server, 
using them to request notifications. These notifications are 
content-free, much like existing in-band IMAP notifications. Should a 
client which finally receives, or at least responds to, these 
notifications require content, it must connect, authenticate, and 
retrieve the content normally.

This means that the nasty hideous part of notifications - that is, 
actually getting the notifications to the client - is actually placed 
neatly well out of scope of the servers. Thus a Magic Notification 
Server could be provided by a mobile network operator, or a 
mailserver ISV. Or even both, covering different actualy notification 
protocols.

The IMAP extensions needed are fairly minimal - yes, we're extending 
the protocol, but we're not spending as much time extending the 
software required.


> The problem is that every time someone tries to produce a write up 
> of such an effort, everybody immediately starts making the spurious 
> "if <X> protocol does not have <Y> functionality, then <X> will 
> die" argument to press to add everything but the kitchen sink.  
> Each time this happens, the guy who did the work decides "I don't 
> need this headache" and drops it.
> 
> This is, sadly, a systemic problem throughout the IETF.

No, there's a worse systemic problem, but that involves the creation 
of new protocols within the IETF. I think what you describe is merely 
a minor symptom of it. But that's another story for another time.

For now, Merry Christmas for those that intend getting merry, Happy 
Yule for those willing to be happy, and best wishes for the new year, 
for those that actually have a new year at roughly this time.

Dave.
-- 
           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
[e-mail]
https://www1.ietf.org/mailman/listinfo/lemonade

_______________________________________________
Notifications mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/notifications