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]