Subject: [lemonade] Text on server to client notifications (per Paris AI).

From: "Stephane H. Maes" <[email-masked]>
Date: Tue, 13 Sep 2005 19:35:51 -0700

Per my action item in Paris, I have drafted a first set of sentences on server to client notifications. It's a first pass but it passed Eric's and Glenn's initial review :)

"Server to Client notifications for e-mail:

The purpose of this activity is to provide and specify mechanisms to pass, outside the IMAP band, IMAP / e-mail events from a IMAP server
(MSA) to registered MUAs in addition or in lieu of IMAP exchanges that would otherwise be requested by the MUA or provided within the IMAP band by the MSA. The purpose of these events is to improve efficiencies of exchanges, reduce delays in reflections of MSA changes in MUAs and allow MUA wake up. IMAP should take advantage of events that have reached the MUA but present robustness when some are lost or delayed. The transport of the events should be out of scope of the specification but it should be compatible with IETF notification transport protocols (e.g. SIP notification, .)."

Thanks

Stephane

_____
Stephane H. Maes, PhD,
Director of Architecture - OCS & Mobile, Oracle Corporation.
Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296.
e-mail: [email-masked]
IM: shmaes (AIM/Y!/skype) or [email-masked] (MSN Messenger)

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 14 Sep 2005 06:29:41 -0700

Hi Stephane,

--On September 13, 2005 7:35:51 PM -0700 "Stephane H. Maes" 
<[email-masked]> wrote:

> The purpose of this activity is to provide and specify mechanisms to
> pass, outside the IMAP band, IMAP / e-mail events from a IMAP server
> (MSA) to registered MUAs in addition or in lieu of IMAP exchanges that
> would otherwise be requested by the MUA or provided within the IMAP band
> by the MSA. The purpose of these events is to improve efficiencies of
> exchanges, reduce delays in reflections of MSA changes in MUAs and allow
> MUA wake up. IMAP should take advantage of events that have reached the
> MUA but present robustness when some are lost or delayed. The transport
> of the events should be out of scope of the specification but it should
> be compatible with IETF notification transport protocols (e.g. SIP
> notification, .)."

This may be out of scope for lemonade specifically, but this specification 
should be general enough that it can be applicable to other protocols, e.g. 
SIEVE notifications, or calendar scheduling event notifications with CalDAV.

-- 
Cyrus Daboo

---

From: Mark Crispin <[email-masked]>
Date: Wed, 14 Sep 2005 10:49:16 -0700 (PDT)

> be compatible with IETF notification transport protocols (e.g. SIP 

I request that the above be rewritten into comprehensible English.  As it 
stands, it reads like something generated in the bowels of the EU 
bureaucracy.

In particular:
  . break up run-on sentences
  . use correct syntax and grammar
  . use proper diction; e.g., "be robust" instead of "present robustness"
  . correct technical inaccuracies; e.g., IMAP is not an MSA
  . eschew jargon; e.g., "purpose of this activity", "provide and specify",
     "improve efficiencies of exchanges", etc.
  . use the correct wording, not its second cousin; e.g., "is" instead of
     "should be", "similar to" instead of "compatible with"

For example:

Define a mechanism to deliver events from the MDA of a mail store to an 
MUA which has registered itself as wanting to receive these events.  This 
mechanism will be external to IMAP, and does not require an active IMAP 
session between the MUA and the mail store.  The goal is to improve 
efficiency and reduce delays by avoiding the need to poll in IMAP. 
Eliminating polling also means that the MUA can idle until an event is 
delivered.  This mechanism should be usable within IMAP; but IMAP must 
remain robust if an event is lost or delayed.  The precise means of 
transporting events is not defined here, but it should be similar to SIP 
notification and other IETF notification transport protocols.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

---

From: Chris Newman <[email-masked]>
Date: Wed, 14 Sep 2005 14:24:35 -0700

Mark Crispin wrote on 9/14/05 10:49 -0700:
> Define a mechanism to deliver events from the MDA of a mail store to an MUA
> which has registered itself as wanting to receive these events.  This
> delivered.  This mechanism should be usable within IMAP; but IMAP must remain
> robust if an event is lost or delayed.  The precise means of transporting
> events is not defined here, but it should be similar to SIP notification and
> other IETF notification transport protocols.

This is a good start.  Two nits:

* While the most critical events are generated by the MDA, some events can also 
be triggered by the IMAP server itself -- for example an IMAP APPEND to INBOX 
would change the number of messages in INBOX which is one of the things clients 
might want to track through the notification mechanism.

* I suggest we delete the word "transport" and simply use "IETF notification 
protocols".  Using ISO nomenclature, the IETF has only two transport protocols: 
TCP and UDP.

What I'd like to see us do is:

1. Describe the events we believe important for Internet Mail/Messaging client
   and server notifications.
2. Define a format for those events.
3. Document the security considerations for server-server and server-client
   notifications (and the two differ significantly).
4. Describe a binding of the event format to at least one IETF transfer
   protocol, but not to preclude the use of other transport protocols.

We should not work on 4 as a group until 1-3 are complete, but I do believe 
it's important to have at least one concrete protocol binding for any data 
format before that data format should advance to draft standard.

                - Chris

---

From: Mark Crispin <[email-masked]>
Date: Wed, 14 Sep 2005 14:46:48 -0700 (PDT)

For what it's worth, I agree with all of Chris' comments.  My post was not 
to advocate a particular position, but rather to restate Stephane's 
message in an easier-to-understand form.

It looks like addressing Chris' nits results in further simplification; 
changing "the MDA of a mail store" to "a mail store"; "transporting" to 
"conveying", and "IETF notification transport protocols" to "IETF 
notification protocols".  That looks good to me.

I also very much agree on Chris' 4-item action list, and in deferring 
action on the fourth item until the first three are complete.

-- Mark --

http://panda.com/mrc

---

From: "Stephane H. Maes" <[email-masked]>
Date: Wed, 14 Sep 2005 16:26:14 -0700

Cyrus,

I will try to incorporate. However, there is danger that then people will say that it is a notification protocol instead of figuring out of notification can be integrated with IMAP it self. As I understand this was the problem of last time. This time we want to explicitly focus on how IMAP can take advantage of it in some operations.

However, let me see if I can find text that addresses also your comments. A priori I definitively agree on SIEVE. On calendar I need to think a bit. Do you have a suggestion.

Stephane

_____
Stephane H. Maes, PhD,

-----Original Message-----
From: Cyrus Daboo [mailto:[email-masked]] 
Sent: Wednesday, September 14, 2005 6:30 AM
To: Stephane H. Maes; [email-masked]
Subject: Re: [lemonade] Text on server to client notifications (per Paris AI).

Hi Stephane,

--
Cyrus Daboo

---

From: "Stephane H. Maes" <[email-masked]>
Date: Wed, 14 Sep 2005 16:38:22 -0700

Mark,

Thanks for the improvements, away from the EU verbage :) I do any update starting from your text.

Stephane

_____
Stephane H. Maes, PhD,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Crispin
Sent: Wednesday, September 14, 2005 10:49 AM
To: Stephane H. Maes
Cc: [email-masked]
Subject: Re: [lemonade] Text on server to client notifications (per Paris AI).

In particular:

For example:

-- Mark --

http://panda.com/mrc

---

From: Mark Crispin <[email-masked]>
Date: Wed, 14 Sep 2005 16:46:09 -0700 (PDT)

On Wed, 14 Sep 2005, Stephane H. Maes wrote:
> I will try to incorporate. However, there is danger that then people 
> will say that it is a notification protocol instead of figuring out of 
> notification can be integrated with IMAP it self. As I understand this 
> was the problem of last time. This time we want to explicitly focus on 
> how IMAP can take advantage of it in some operations.

I think that you may misunderstand the problem.

IMAP should NOT be extended to be a notification service.  There is 
nothing in IMAP's scope that enables it to be a notification service.  It 
would be very strange to tell a POP3 or NNTP client that it must support 
IMAP in order to obtain notifications.

However, there is no reason why an IMAP server can not be a client of a 
notification service.  The effective result seen by an IMAP client 
programmer would be the same.

Put another way: you will get strong pushback from IMAP server vendors 
against any proposal that requires IMAP to be a notification service.  You 
will not get such negative pushback on a separate notification service 
that (among other things) happens to be accessible via IMAP.

As for why previous efforts at notifications have not progressed: do not 
be deluded into believing that there is any simple explanation or 
solution.  Notifications are a difficult problem.  They do not fit within 
the scope of any existing protocol or service.  Attempts to do "something 
simple" within an existing protocol or service are doomed to failure.

-- Mark --

http://panda.com/mrc

---

From: "Stephane H. Maes" <[email-masked]>
Date: Wed, 14 Sep 2005 16:46:19 -0700

Chris thanks for the feedback,

I will try to add to the text built on Mark's input.

Stephane

_____
Stephane H. Maes, PhD,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Newman
Sent: Wednesday, September 14, 2005 2:25 PM
To: Mark Crispin; Stephane H. Maes
Cc: [email-masked]
Subject: Re: [lemonade] Text on server to client notifications (per Paris AI).

                - Chris

---

From: "Stephane H. Maes" <[email-masked]>
Date: Wed, 14 Sep 2005 17:09:13 -0700

BTW I am not suggesting extending IMAP to become a notification server. I am however suggesting that IMAP can take advantage of a notification service to provide a push experience. I think as part of the work we should do this.

Stephane

_____
Stephane H. Maes, PhD,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Crispin
Sent: Wednesday, September 14, 2005 4:46 PM
To: Stephane H. Maes
Cc: [email-masked]; Cyrus Daboo
Subject: RE: [lemonade] Text on server to client notifications (per Paris AI).

-- Mark --

http://panda.com/mrc