Internet DRAFT - draft-newman-lemonade-msgevent
draft-newman-lemonade-msgevent
Network Working Group C. Newman
Internet-Draft Sun Microsystems
Expires: March 23, 2006 September 19, 2005
Internet Message Store Events
draft-newman-lemonade-msgevent-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 23, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
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.
Newman Expires March 23, 2006 [Page 1]
Internet-Draft Internet Message Store Events September 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Event Model . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Event Types . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1 Message Addition and Deletion . . . . . . . . . . . . . . 5
4.2 Message Flags . . . . . . . . . . . . . . . . . . . . . . 7
4.3 Access Accounting . . . . . . . . . . . . . . . . . . . . 7
5. Event Parameters . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1 Normative References . . . . . . . . . . . . . . . . . . . 10
7.2 Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
A. Future Extensions . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 13
Newman Expires March 23, 2006 [Page 2]
Internet-Draft Internet Message Store Events September 2005
1. Introduction
A message store is used to organize Internet Messages [RFC2822] into
one or more mailboxes, annotate them in various ways and provide
access to these messages and associated meta-data. Three different
standards-based protocols have been widely deployed to remotely
access a message store. Post Office Protocol (POP) [RFC1939]
provides simple download-and-delete access to a single mail drop
(which is a subset of the functionality typically associated with a
message store). Internet Message Access Protocol (IMAP) [RFC3501]
provides an extensible feature-rich model for online, offline and
disconnected access to a message store with minimal constraints on
any associated "fat-client" user interface. Finally, mail access
applications built on top of Hypertext Transfer Protocol (HTTP)
[RFC2616] which run in standards-based web browsers provide a third
standards-based access mechanism for online-only access.
While simple and/or ad-hoc mechanisms for notifications have sufficed
to some degree in the past (e.g. Simple New Mail Notification
[RFC4146], IMAP4 IDLE command [RFC2177]), as the scope and importance
of message stores expands, the demand for a more complete store
notification system increases. Some of the driving forces behind
this demand include:
o Mobile devices with intermittent network connectivity that have
"new mail" or "message count" indicators
o Unified messaging systems which include both Internet and voice
mail require support for a message waiting indicator on phones
o Interaction with systems for event-based or utility-computing
billing
o Simplify the process of gatewaying message store events to non-
Internet notification systems
o A calendar system may wish to subscribe to NewMessage
notifications in order to support iMIP [RFC2447].
o Recent laws for information protection and auditing will require
interoperable protocols between message stores built by messaging
experts and compliance auditing systems built by compliance
experts.
Vendors who have deployed proprietary notification systems for their
Internet message stores have seen significant demand to provide
notifications for more and more events. As a first step towards
building a notification system, this document attempts to enumerate
Newman Expires March 23, 2006 [Page 3]
Internet-Draft Internet Message Store Events September 2005
the core events that real-world customers demand.
2. Terminology
The following terminology will be used in this document:
mailbox
A folder which contains Internet messages and may or may not
permit delivery of new messages via a mail delivery agent.
mailbox identifier
A mailbox identifier provides sufficient information to identify a
specific mailbox on a specific server instance. An IMAP URL can
be a mailbox identifier.
message access protocols
Protocols which provide clients (e.g. a mail user agent or web
browser) with access the message store including but not limited
to IMAP, POP and HTTP.
message context
As defined in [RFC3458].
UIDVALIDITY
As defined in IMAP4rev1 [RFC3501]. UIDVALIDITY is critical to the
correct operation of a caching mail client. When it changes, the
client must flush its cache. It's particularly important to
include UIDVALIDITY with event notifications related to message
addition or removal in order to keep the message data correctly
synchronized.
3. Event Model
The events that are generated by a message store depend to some
degree on the model used to represent a message store. The model the
IETF has for a message store is implicit from IMAP4rev1 and
extensions, so that model is assumed by this document.
A message store event typically has an associated mailbox name and
usually has an associated user name (or authorization identity if
using the terminology from SASL [RFC2222]). Events referring to a
specific message can use an IMAP URL [RFC2192] to do so. Events
referring to a set of messages can use an IMAP URL to the mailbox
plus an IMAP UID set.
Each notification has a type and parameters. The type determines the
type of event, while the parameters supply information about the
Newman Expires March 23, 2006 [Page 4]
Internet-Draft Internet Message Store Events September 2005
context of the event that may be used to adjust subscription
preferences or may simply supply data associated with the event. The
types and parameter names in this document are restricted to US-ASCII
printable characters so these events can be easily mapped to an
arbitrary notification system. However, this document assumes
arbitrary parameter values (including large and multi-line values)
can be encoded with the notification system. Systems which lack that
feature could only implement a subset of these events.
This document does not yet take a position on which event parameters
are mandatory or optional. That will be done when actual message
formats or bindings to a notification system are completed.
For scalability reasons, some degree of filtering at event generation
is necessary. At the very list, the ability to turn on and off
groups of related events and to suppress inclusion of large
parameters (such as messageContent) is needed. A sophisticated
publish/subscribe notification system may be able to propagate
cumulative subscription information to the publisher.
some of these events might be logically collapsed into a single event
type with a required parameter to distinguish between the cases
(e.g., OverQuota and UnderQuota). However until such time that an
event subscription model is formulated, it's not practical to make
such decisions. We thus note only the fact that some of these events
may be viewed as a single event type.
4. Event Types
This section discusses the different types of events useful in a
message store event notification system. The intention is to
document the events sufficient to cover about 95% of the known use
cases while leaving less common event types for the future. This
section mentions parameters which are important or specific to the
events described here. Event parameters likely to be included in
most or all notifications are discussed in the next section.
4.1 Message Addition and Deletion
This section includes events related to message addition and
deletion.
AppendMessage
A message was appended or concatenated to a mailbox by a message
access client. For the most part, this is identical to the
NewMessage event type, except that the SMTP envelope information
is not included as a parameter, but information about which
protocol triggered the event may be included. See the NewMessage
Newman Expires March 23, 2006 [Page 5]
Internet-Draft Internet Message Store Events September 2005
event for more information.
ExpireMessage
One or more messages were expired from a mailbox due to server
expiration policy and are no longer accessible by the end-user.
The parameters include a mailbox identifier which must include
UIDVALIDITY. A UID set references the messages. Information
about which server expiration policy was applied may be included
as parameters in a future version.
ExpungeMessage
One or more messages were expunged from a mailbox by an IMAP
CLOSE/EXPUNGE, POP3 DELE+QUIT, HTTP or equivalent client action
and are no longer accessible by the end-user. The parameters
include a mailbox identifier which must include UIDVALIDITY, a UID
set, and may also indicate which access protocol triggered the
event.
NewMessage
A new message was received into a mailbox via a message delivery
agent. The parameters include a message identifier which must
include UIDVALIDITY and UID for IMAP-accessible message stores.
The parameters may also include the entire new message itself,
possibly an SMTP envelope and other arbitrary message and mailbox
meta-data. The set of parameters included should be adjustable to
the client's preference with limits set by server policy. An
interesting policy, for example, would be to include messages up
to 2K in size with the notification, but for larger messages to
include a URLAUTH [I-D.ietf-lemonade-urlauth] reference.
OverQuota
An operation failed (typically NewMessage) because the user's
mailbox exceeded one of the quotas (e.g., disk quota, message
quota, quota by message context, etc). The parameters should
include at least the relevant user and quota, and optionally the
mailbox. Quota usage should be included if possible. Parameters
needed to extend this to support quota by context are not
presently described in this document, but could be added in the
future.
UnderQuota
An operation occurred (typically ExpungeMessages or
ExpireMessages) which reduced the user's quota usage under their
limit.
Newman Expires March 23, 2006 [Page 6]
Internet-Draft Internet Message Store Events September 2005
4.2 Message Flags
This section includes events related to changes in message flags.
ReadMessages
One or more messages in the mailbox were marked as read or seen by
a user. Note that POP has no concept of read or seen messages, so
these events will only be generated by IMAP or HTTP clients (or
equivalent). The parameters include a mailbox identifier and a
set of message UIDs.
TrashMessages
One or more messages were marked for future deletion by the user
but are still accessible over protocol (the user's client may or
may not make these messages accessible through its user
interface). The parameters include a mailbox identifier and a set
of message UIDs.
4.3 Access Accounting
This section includes events related to message store access
accounting.
Login
A user has logged in to the system via IMAP, HTTP, POP or some
other mechanism. The parameters include a the server domain name
and port and the user's authorization identity. Additional
possible parameters include the client's IP address and port, the
authentication identity (if different from the authorization
identity), the service name, the authentication mechanism,
information about any negotiated security layers, a timestamp and
other information.
Logout
A user has logged out or otherwise been disconnected from the
message store via IMAP, HTTP, POP or some other mechanism. The
parameters include the server domain name and the user's
authorization identity. Additional parameters may include any of
the information from the "Login" event as well as information
about the type of disconnect (graceful, abort, timeout, security
layer error), the duration of the connection or session and other
information.
Newman Expires March 23, 2006 [Page 7]
Internet-Draft Internet Message Store Events September 2005
5. Event Parameters
This section lists parameters that may be useful to include with
these events.
admin
Included with all events generated by message access protocols.
The authentication identity associated with this event, as
distinct from the authorization identity (see "user"). This is
not included when it is the same as the value of the user
parameter.
bodyStructure
May be included with AppendMessage and NewMessage.
The IMAP BODYSTRUCTURE of the message.
clientIP
Included with all events generated by message access protocols.
The IP address of the message store access client which performed
an action which triggered the notification.
clientPort
Included with all events generated by message access protocols.
The port number of the message store access client which performed
an action which triggered the notification.
diskQuota
Included with OverQuota and UnderQuota notifications relating to a
user or mailbox disk quota. May be included with other
notifications.
Disk quota limit in kilobytes.
diskUsed
Included with OverQuota and UnderQuota notifications relating to a
user or mailbox disk quota. May be included with other
notifications.
Disk quota used in kilobytes.
maxMessages
Included with OverQuota and UnderQuota notifications relating to a
user or mailbox message count quota. May be included with other
notifications.
Quota limit on the number of messages in the mailbox, for events
referring to a mailbox.
Newman Expires March 23, 2006 [Page 8]
Internet-Draft Internet Message Store Events September 2005
messageContent
May be included with AppendMessage and NewMessage.
The entire message itself. Size based suppression of this should
be available.
messageSize
May be included with AppendMessage and NewMessage.
Size of the RFC 2822 message itself in octets. This value would
match the length of the IMAP literal which would be returned in
response to an IMAP FETCH of BODY[] for the referenced message.
messages
Included with OverQuota and UnderQuota notifications relating to a
user or mailbox message count quota. May be included with other
notifications.
Number of messages in the mailbox. This is typically included
with message addition and deletion events.
pid
May be included with any notification.
The process id of the process which generated the notification.
process
May be included with any notification.
The name of the process which generated the notification.
serverFQDN
May be included with any notification.
The fully-qualified-domain-name of the server which generated the
event. Note that this may be different from the server name used
to access the mailbox included in the mailbox identifier.
service
May be included with any notification.
The name of the service which triggered the event. Suggested
values include "imap", "pop", "http", "admincli".
envelope
May be included with the NewMessage notification.
The message transfer envelope associated with final delivery of
the message for the NewMessage notification. This will include
the MAIL FROM and relevant RCPT TO line(s) used for final delivery
with CRLF delimiters and any ESMTP parameters.
timestamp
May be included with any notification.
When the notification was generated.
Newman Expires March 23, 2006 [Page 9]
Internet-Draft Internet Message Store Events September 2005
uidnext
May be included with any notification referring to a mailbox.
The next UID that will be assigned in the mailbox. This is
typically included with message addition and deletion events.
This is equivalent to the UIDNEXT status item in the IMAP STATUS
command.
uidset
Included with ExpireMessages, ExpungeMessages, ReadMessages and
TrashMessages.
This includes the set of IMAP UIDs referenced.
uri
Included with all notifications and refers to the IMAP server, a
mailbox or a message.
Typically an IMAP URL. This can include the name of the server
used to access the mailbox/message, the mailbox name, the
UIDVALIDITY of the mailbox, and the UID of a specific message.
user
Included with all events generated by message access protocols.
This is the SASL authorization identifier used when the user
connected to the access protocol which triggered the event. For
events associated with a mailbox, this may be different from the
owner of the mailbox specified in the IMAP URL.
6. Security Considerations
Notifications can produce a large amount of traffic and expose
sensitive information. A competent transfer protocol for
notifications must address authentication, authorization and privacy,
as well as denial-of-service issues. While the IETF has adequate
tools and experience to address these issues for mechanisms which
involve only one TCP connection, notification or publish/subscribe
protocols which are more sophisticated than a single end-to-end TCP
connection will need to pay extra attention to these issues and
carefully balance requirements to successfully deploy a system with
security and privacy considerations.
7. References
7.1 Normative References
[RFC2192] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
[RFC2342] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
May 1998.
Newman Expires March 23, 2006 [Page 10]
Internet-Draft Internet Message Store Events September 2005
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
7.2 Informative References
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996.
[RFC2177] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997.
[RFC2222] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[RFC2447] Dawson, F., Mansour, S., and S. Silverberg, "iCalendar
Message-Based Interoperability Protocol (iMIP)", RFC 2447,
November 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message
Context for Internet Mail", RFC 3458, January 2003.
[RFC4146] Gellens, R., "Simple New Mail Notification", RFC 4146,
August 2005.
[I-D.ietf-lemonade-urlauth]
Crispin, M., "Internet Message Access Protocol (IMAP) -
URLAUTH Extension", draft-ietf-lemonade-urlauth-07 (work
in progress), June 2005.
Author's Address
Chris Newman
Sun Microsystems
3401 Centerlake Dr Ste. 410
Ontario, CA 91761
US
Email: chris.newman@sun.com
Newman Expires March 23, 2006 [Page 11]
Internet-Draft Internet Message Store Events September 2005
Appendix A. Future Extensions
The "core" functionality is based on events which are believed to be
well understood, have known use cases and are implemented by at least
one deployed real-world Internet message store. Some events have
been suggested, but are postponed to future extensions because they
do not meet this criteria. These events include messages which have
been moved to archive storage and may require extra time to access,
other IMAP flag changes, quota by message context, authentication
failure, user mail account disabled and mailbox create/delete/rename.
In order to narrow the scope of this document to something that can
be completed, only events generated from the message store (by a
message access module, administrative module or message delivery
agent) are considered. A complete mail system will be linked with an
identity system which would also publish events of interest to a
message store event subscriber. Events of interest include account
created/deleted/disabled and password changed/expired.
Newman Expires March 23, 2006 [Page 12]
Internet-Draft Internet Message Store Events September 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Newman Expires March 23, 2006 [Page 13]
