Internet Message Store Events
RFC 5423
Network Working Group R. Gellens
Request for Comments: 5423 QUALCOMM Inc.
Category: Standards Track C. Newman
Sun Microsystems
March 2009
Internet Message Store Events
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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) and 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 that interest real-world consumers of such a system.
This document describes events and event parameters that are useful
for several cases, including notification to administrative systems
and end users. This is not intended as a replacement for a message
access facility such as IMAP.
Gellens & Newman Standards Track [Page 1]
RFC 5423 Internet Message Store Events March 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Event Model . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Event Types . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Message Addition and Deletion . . . . . . . . . . . . . . 5
4.2. Message Flags . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Access Accounting . . . . . . . . . . . . . . . . . . . . 8
4.4. Mailbox Management . . . . . . . . . . . . . . . . . . . . 8
5. Event Parameters . . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Future Extensions . . . . . . . . . . . . . . . . . . 17
1. Introduction
A message store is used to organize Internet Messages [RFC5322] into
one or more mailboxes (possibly hierarchical), annotate them in
various ways, and provide access to these messages and associated
metadata. Three different standards-based protocols have been widely
deployed to remotely access a message store. The 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). The 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 the
Hypertext Transfer Protocol (HTTP) [RFC2616] that 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 expand, 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
Show full document text