Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-msgevent-00.txt

From: [email-masked]
Date: Wed, 07 Jun 2006 15:50:02 -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		: Internet Message Store Events
	Author(s)	: C. Newman
	Filename	: draft-ietf-lemonade-msgevent-00.txt
	Pages		: 14
	Date		: 2006-6-7
	
One of the missing features in the existing Internet mail and
messaging standards is a facility for server-to-server and server-to-
client event notifications related to message store events.  As the
scope of Internet mail expands to support more diverse media (such as
voice mail), devices (such as cell phones) and to provide rich
interactions with other services (such as web portals and legal
compliance systems), the need for an interoperable notification
system increases.  This document attempts to enumerate the types of
events which interest real-world consumers of such a system.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-msgevent-00.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-msgevent-00.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-msgevent-00.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: Thu, 8 Jun 2006 11:58:11 +0300

Hi all,
A few comments/questions:
 - General: it is unclear which events will go to the clients and which ones for admins (or both). Take OverQuota or Login as an example. Perhaps the reason is that this draft is simply a collection of event definitions without context? If so, it is fine, but then the bis (or the notification draft needs to put each and every one of these into context).
 - OverQuota and UnderQuota does not quite belong to "4.1.  Message Addition and Deletion" . Should we move it to "4.3.  Access Accounting"?
 - Can we add more events? Like MailboxCreated (name), MailboxRenamed (name, newname), MailboxDeleted (name), MailboxMoved (name, targetmailbox)? - This is for 'folder' management, but there could be a lot more.
 - Extension mechanism? (To define custom events and parameters when needed?)
Thank You.

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

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: 07 June, 2006 22:50
To: [email-masked]
Cc: [email-masked]
Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-msgevent-00.txt 

	
One of the missing features in the existing Internet mail and messaging standards is a facility for server-to-server and server-to- client event notifications related to message store events.  As the scope of Internet mail expands to support more diverse media (such as voice mail), devices (such as cell phones) and to provide rich interactions with other services (such as web portals and legal compliance systems), the need for an interoperable notification system increases.  This document attempts to enumerate the types of events which interest real-world consumers of such a system.

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-msgevent-00.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:

---

From: Randall Gellens <[email-masked]>
Date: Thu, 15 Jun 2006 16:01:17 -0700

Thanks, Chris, for (re)submitting this.

A few requested clarifications for Section 5 (Event Parameters):

The 'service' parameter is interesting in the case where the the user 
accesses the mail store via one protocol (such as HTTP) which itself 
accesses the mail store via another protocol (such as IMAP).  As an 
example, there are a number of popular webmail products which use 
IMAP (or even POP!) to access mail.  From the mail store's 
perspective, all such access is via IMAP and likely from an IP 
address that is not especially interesting (such as 127.0.0.1).  I'm 
not sure how to accommodate this in a general event framework, 
though.  A 'pass-through' parameter would be useful, but there isn't 
anything I can think of off-hand in IMAP to pass such information 
through, so it might be best left for future extension, perhaps with 
a note about it.

The 'timestamp' parameter should be specified as to its form.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
There will be no lasting peace on our earth as long as politicians and
dictators continue to lead masses of people who are endemically
neurotic and sexually sick.                            --Wilhelm Reich

---

From: Randall Gellens <[email-masked]>
Date: Thu, 15 Jun 2006 16:08:27 -0700

At 11:58 AM +0300 6/8/06, <[email-masked]> wrote:

>   - General: it is unclear which events will go to the clients and 
> which ones for admins (or both).

I think this is a question for the filtering mechanism, the 
subscribe/publish mechanism, and the event delivery protocol.

>   Take OverQuota or Login as an example. Perhaps the reason is that 
> this draft is simply a collection of event definitions without 
> context? If so, it is fine, but then the bis (or the notification 
> draft needs to put each and every one of these into context).

As the Abstract mentions, this draft describes the events that 
real-world customers ask their mail stores to provide.  How such 
events are used is the scope of the using protocols.

>   - OverQuota and UnderQuota does not quite belong to "4.1.  Message 
> Addition and Deletion" . Should we move it to "4.3.  Access 
> Accounting"?

I don't much care in which section quota events go, but it seems most 
likely for these to be generated by the addition and deletion of 
messages.  (The other cases include administrative changes to the 
quota, but those probably a lot of common.)

>   - Can we add more events? Like MailboxCreated (name), 
> MailboxRenamed (name, newname), MailboxDeleted (name), MailboxMoved 
> (name, targetmailbox)? - This is for 'folder' management, but there 
> could be a lot more.

I'll let others comment on this.

>   - Extension mechanism? (To define custom events and parameters when needed?)

It seems to me that new events and parameters can be created by 
additional documents, but perhaps an explicit mention of this would 
be a good idea.

Are these events to be maintained in an IANA registry or simply in 
the published RFCs?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
    "And what will you do when you grow up to be as big as me?"
asked the father of his little son.
    "Diet."

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 16 Jun 2006 15:39:42 +0100

[email-masked] wrote:

> - Can we add more events? Like MailboxCreated (name), MailboxRenamed (name, newname), MailboxDeleted (name), MailboxMoved (name, targetmailbox)?
>
I am not sure what MailboxMoved means, but I agree about the rest.

> - This is for 'folder' management, but there could be a lot more.
>  
>

---

From: <[email-masked]>
Date: Tue, 20 Jun 2006 13:19:09 +0300

It was supposed to refer to folders, but I read on the mailing list before that the word folder should be avoided - did You find a better word?  So I just used mailbox (but I guess You understood what I meant anyway).