Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-notifications-02.txt

From: [email-masked]
Date: Tue, 30 May 2006 18:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF.

	Title		: Lemonade notifications and filters
	Author(s)	: R. Cromwell, S. Maes
	Filename	: draft-ietf-lemonade-notifications-02.txt
	Pages		: 25
	Date		: 2006-5-30
	
This document discusses how to provide notification and filtering 
   mechanisms to IMAP [RFC3501] as part the Lemonade profile 
   [LEMONADEPROFILEBIS].  
    
   This document also discusses the use of Lemonade notifications to 
   implement server to server notifications.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-notifications-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-lemonade-notifications-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-lemonade-notifications-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: <[email-masked]>
Date: Wed, 31 May 2006 16:56:23 +0300

Hi Stephane,
a great step forward, thank You for the update.
A few comments:
- "generates a outband" -> "generates an outband"
- "If the MUA is not connected, and outband notification is disabled, the client must perform..." I do not see how this is a must. The client may connect the determine the changes?
- "If the MUA has only momentarily lost connection, it should also attempt to use [RECONNECT]." The client has no control over loosing a connection momentarily or otherwise, so I do not see how it helps the notifications - what if it disconnected it intentionally? Outband notifications will kick in anyway, right? I do not think such cases are to be discussed in this draft - the RECONNECT draft is a better place to do so. Also, this paragraph discusses the case when the client is offline, so it should not be here anyway.
 - "appropriate format to a particular IP address and port." No MSIDN/MDN? No SIP address? IP address might work for IP-based networks. Or, was it meant to be the IP address of an "aggregator server" which is ultimately responsible for sending out the notification for the right place using the appropriate bearer? If so, how is it configured?
 - "The payload for wake-up notifications is the OMA EMN format" Is this a must, should or a may?
 - "The mailbox URI formats are defined in [OMN-EN]" - no reference found for OMN-EN: OMA-EN perhaps?.
 - "Example extended payload" This is not an extended payload, this is the normal payload.
 -  "the server MAY stop sending outband notifications" Can we change it to something like "adaptively" stop? I mean that the notifications would slow down (fade out) after a while, and in the end they might stop?
 - "10. Provisioning..." Is there any way for the server to indicate that provisioning is not done using ANNOTATEMORE, but relies on an external mechanism? (like OMA DM?) - "A client only needs to access provision information once" Is this valid? Some things might be changed on the server over time. We should not encourage this since it might cause IOP problems in the long run.
 - "10.3. Preference Entries" Are these per-session settings? I mean: can the client set it up its own settings for the current session only and several sessions may co-exist with different preferences?
 - ""filter.priv"  = "ALL" / "NEW" / "NONE"" I though that a SIEVE script would do this. Should it be the filename (or some other identifier) of a SIEVE script? (NIL if no filter, otherwise the ID of the active filter.) SIEVE scripts could be stored on the server in a common storage for the user, and the user could select for each session separately which one is active during the current session. Or, am I missing something?
 - Section 13, general question: I have difficulties understanding some of the sentences here because I do not know what exactly the "messaging system" in this context. Would it be possible to clarify this?
 - "which describe potential notification events" What makes a notification event "potential"?
 - "sent to a notification mechanisms" -> "sent to a notification mechanism" or "sent to notification mechanisms"
 - "while allowing the messaging system, not to be familiar with the end user's notification preferences" -> "without the messaging system having knowledge about the end user's notification preferences" What I do not understand here is that how does the server know that a notification is to be sent if it does not know what my preferences are. Or perhaps the outband notification format and bearer settings are meant to be said here?
 - "mechanisms are the entities which is familiar" -> "mechanisms are the entities which are familiar"
 - "Using server to server notifications, allow the messaging system to provide the end user, a unified notification experience" -> "The server to server notifications allow the messaging system to provide the end user a unified notification experience"
 - "suite of Internet mail protocols (POP3, IMAP4)" -> "suite of Internet mail protocols (POP3, IMAP4, WebDAV, etc)"
 - "server to server notifications do not deal with the communications" -> "server to server notifications do not deal directly with the communications"
 - Figure 3 - should there be an additional box there which indicates that the Notification Mechanism retrieves user preferences from the server before choosing the appropriate notification route?
 - "notification request SHOULD contain data regarding" Isn't this a MUST?
 - 13.3 terminology - should we move this up in the document? Would have been more helpful in the beginning of this chapter.
 - "Within the context of Lemonade profile (Figure 1)," Isn't it supposed to say Lemonade bis?
 - "Realize the messaging mecanisms'" -> "Realize the messaging mechanisms'"
 - "The notification mechanisms SHOULD notify the messaging system whenever" Why is it only a SHOULD?
 - "or generic server to server notifications, the order may matter" How does a server determine about another server that the order does matter?
  -"MUST buffer the notifications" Does it apply to all notifications? I mean, what's the benefit of buffering and providing "new mail" notifications after the client connected and performed synch?
- "It should be possible to authenticate sender and" -> "It should be possible to authenticate the sender of the notification and"
Thank You.

Best regards: Zoltán Ördögh
E-mail: zoltan.ordogh at nokia.com
Phone: +358 50 386 0566

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: 31 May, 2006 01:50
To: [email-masked]
Cc: [email-masked]
Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-notifications-02.txt 

	

To remove yourself from the I-D Announcement list, send a message to [email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then
	"get draft-ietf-lemonade-notifications-02.txt".

A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Send a message to:
	[email-masked].
In the body type: