7Network Working Group R. Gellens
8Request for Comments: 5423 QUALCOMM Inc.
9Category: Standards Track C. Newman
14 Internet Message Store Events
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
26 Copyright (c) 2009 IETF Trust and the persons identified as the
27 document authors. All rights reserved.
29 This document is subject to BCP 78 and the IETF Trust's Legal
30 Provisions Relating to IETF Documents in effect on the date of
31 publication of this document (http://trustee.ietf.org/license-info).
32 Please review these documents carefully, as they describe your rights
33 and restrictions with respect to this document.
37 One of the missing features in the existing Internet mail and
38 messaging standards is a facility for server-to-server and server-to-
39 client event notifications related to message store events. As the
40 scope of Internet mail expands to support more diverse media (such as
41 voice mail) and devices (such as cell phones) and to provide rich
42 interactions with other services (such as web portals and legal
43 compliance systems), the need for an interoperable notification
44 system increases. This document attempts to enumerate the types of
45 events that interest real-world consumers of such a system.
47 This document describes events and event parameters that are useful
48 for several cases, including notification to administrative systems
49 and end users. This is not intended as a replacement for a message
50 access facility such as IMAP.
58Gellens & Newman Standards Track [Page 1]
60RFC 5423 Internet Message Store Events March 2009
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
66 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
68 3. Event Model . . . . . . . . . . . . . . . . . . . . . . . . . 4
69 4. Event Types . . . . . . . . . . . . . . . . . . . . . . . . . 5
70 4.1. Message Addition and Deletion . . . . . . . . . . . . . . 5
71 4.2. Message Flags . . . . . . . . . . . . . . . . . . . . . . 7
72 4.3. Access Accounting . . . . . . . . . . . . . . . . . . . . 8
73 4.4. Mailbox Management . . . . . . . . . . . . . . . . . . . . 8
74 5. Event Parameters . . . . . . . . . . . . . . . . . . . . . . . 10
75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
77 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
80 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
81 Appendix A. Future Extensions . . . . . . . . . . . . . . . . . . 17
85 A message store is used to organize Internet Messages [RFC5322] into
86 one or more mailboxes (possibly hierarchical), annotate them in
87 various ways, and provide access to these messages and associated
88 metadata. Three different standards-based protocols have been widely
89 deployed to remotely access a message store. The Post Office
90 Protocol (POP) [RFC1939] provides simple download-and-delete access
91 to a single mail drop (which is a subset of the functionality
92 typically associated with a message store). The Internet Message
93 Access Protocol (IMAP) [RFC3501] provides an extensible feature-rich
94 model for online, offline, and disconnected access to a message store
95 with minimal constraints on any associated "fat-client" user
96 interface. Finally, mail access applications built on top of the
97 Hypertext Transfer Protocol (HTTP) [RFC2616] that run in standards-
98 based web browsers provide a third standards-based access mechanism
99 for online-only access.
101 While simple and/or ad-hoc mechanisms for notifications have sufficed
102 to some degree in the past (e.g., "Simple New Mail Notification"
103 [RFC4146], "IMAP4 IDLE Command" [RFC2177]), as the scope and
104 importance of message stores expand, the demand for a more complete
105 store notification system increases. Some of the driving forces
106 behind this demand include:
108 o Mobile devices with intermittent network connectivity that have
109 "new mail" or "message count" indicators.
114Gellens & Newman Standards Track [Page 2]
116RFC 5423 Internet Message Store Events March 2009
119 o Unified messaging systems that include both Internet and voice
120 mail require support for a message-waiting indicator on phones.
122 o Interaction with systems for event-based or utility-computing
125 o Simplification of the process of passing message store events to
126 non-Internet notification systems.
128 o A calendar system may wish to subscribe to MessageNew
129 notifications in order to support iMIP [RFC2447].
131 o Some jurisdictions have laws or regulations for information
132 protection and auditing that require interoperable protocols
133 between message stores built by messaging experts and compliance
134 auditing systems built by compliance experts.
136 Vendors who have deployed proprietary notification systems for their
137 Internet message stores have seen significant demand to provide
138 notifications for more and more events. As a first step towards
139 building a notification system, this document attempts to enumerate
140 the core events that real-world customers demand.
142 This document includes those events that can be generated by the use
143 of IMAP4rev1 [RFC3501] and some existing extensions. As new IMAP
144 extensions are defined, or additional event types or parameters need
145 to be added, the set specified here can be extended by means of an
146 IANA registry with update requirements, as specified in Section 6.
1481.1. Conventions Used in This Document
150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
152 document are to be interpreted as described in RFC 2119 [RFC2119].
153 When these words appear in lower-case or with initial capital
154 letters, they are not RFC 2119 key words.
158 The following terminology is used in this document:
161 A container for Internet messages and/or child mailboxes. A
162 mailbox may or may not permit delivery of new messages via a mail
170Gellens & Newman Standards Track [Page 3]
172RFC 5423 Internet Message Store Events March 2009
176 A mailbox identifier provides sufficient information to identify a
177 specific mailbox on a specific server instance. An IMAP URL can
178 be a mailbox identifier.
180 message access protocols
181 Protocols that provide clients (e.g., a mail user agent or web
182 browser) with access to the message store, including but not
183 limited to IMAP, POP, and HTTP.
186 As defined in [RFC3458].
189 As defined in IMAP4rev1 [RFC3501]. UIDVALIDITY is critical to the
190 correct operation of a caching mail client. When it changes, the
191 client MUST flush its cache. It's particularly important to
192 include UIDVALIDITY with event notifications related to message
193 addition or removal in order to keep the message data correctly
198 The events that are generated by a message store depend to some
199 degree on the model used to represent a message store. The model the
200 IETF has for a message store is implicit from IMAP4rev1 and
201 extensions, so that model is assumed by this document.
203 A message store event typically has an associated mailbox name and
204 usually has an associated user name (or authorization identity if
205 using the terminology from "Simple Authentication and Security Layer"
206 (SASL) [RFC4422]). Events referring to a specific message can use an
207 IMAP URL [RFC5092] to do so. Events referring to a set of messages
208 can use an IMAP URL to the mailbox plus an IMAP UID (Unique
211 Each notification has a type and parameters. The type determines the
212 type of event, while the parameters supply information about the
213 context of the event that may be used to adjust subscription
214 preferences or may simply supply data associated with the event. The
215 types and parameter names in this document are restricted to US-ASCII
216 printable characters, so these events can be easily mapped to an
217 arbitrary notification system. However, this document assumes that
218 arbitrary parameter values (including large and multi-line values)
219 can be encoded with the notification system. Systems which lack that
220 feature could only implement a subset of these events.
226Gellens & Newman Standards Track [Page 4]
228RFC 5423 Internet Message Store Events March 2009
231 This document does not indicate which event parameters are mandatory
232 or optional. That is done in documents that specify specific message
233 formats or bindings to a notification system.
235 For scalability reasons, some degree of filtering at event generation
236 is necessary. At the very least, the ability to turn on and off
237 groups of related events and to suppress inclusion of large
238 parameters (such as messageContent) is needed. A sophisticated
239 publish/subscribe notification system may be able to propagate
240 cumulative subscription information to the publisher.
242 Some of these events might be logically collapsed into a single event
243 type with a required parameter to distinguish between the cases
244 (e.g., QuotaExceed and QuotaWithin). However, until such time that
245 an event subscription model is formulated, it's not practical to make
246 such decisions. We thus note only the fact that some of these events
247 may be viewed as a single event type.
251 This section discusses the different types of events useful in a
252 message store event notification system. The intention is to
253 document the events sufficient to cover an overwhelming majority of
254 known use cases while leaving less common event types for the future.
255 This section mentions parameters that are important or specific to
256 the events described here. Event parameters likely to be included in
257 most or all notifications are discussed in the next section.
2594.1. Message Addition and Deletion
261 This section includes events related to message addition and
265 A message was appended or concatenated to a mailbox by a message
266 access client. For the most part, this is identical to the
267 MessageNew event type except that the SMTP envelope information is
268 not included as a parameter, but information about which protocol
269 triggered the event MAY be included. See the MessageNew event for
273 One or more messages were expired from a mailbox due to server
274 expiration policy and are no longer accessible by the end user.
276 The parameters include a mailbox identifier that MUST include
277 UIDVALIDITY and a UID set that describes the messages.
282Gellens & Newman Standards Track [Page 5]
284RFC 5423 Internet Message Store Events March 2009
287 Information about which server expiration policy was applied may
288 be included in the future.
291 One or more messages were expunged from a mailbox by an IMAP
292 CLOSE/EXPUNGE, POP3 DELE+QUIT, HTTP, or equivalent client action
293 and are no longer accessible by the end user.
295 The parameters include a mailbox identifier that MUST include
296 UIDVALIDITY, a UID set, and MAY also indicate which access
297 protocol triggered the event.
300 A new message was received into a mailbox via a message delivery
303 The parameters include a message identifier that, for IMAP-
304 accessible message stores, MUST include UIDVALIDITY and a UID.
305 The parameters MAY also include an SMTP envelope and other
306 arbitrary message and mailbox metadata. In some cases, the entire
307 new message itself may be included. The set of parameters SHOULD
308 be adjustable to the client's preference, with limits set by
309 server policy. An interesting policy, for example, would be to
310 include messages up to 2K in size with the notification, but to
311 include a URLAUTH [RFC4467] reference for larger messages.
314 An operation failed (typically MessageNew) because the user's
315 mailbox exceeded one of the quotas (e.g., disk quota, message
316 quota, quota by message context, etc.). The parameters SHOULD
317 include at least the relevant user and quota and, optionally, the
318 mailbox. Quota usage SHOULD be included if possible. Parameters
319 needed to extend this to support quota by context are not
320 presently described in this document but could be added in the
324 An operation occurred (typically MessageExpunge or MessageExpire)
325 that reduced the user's quota usage under the limit.
328 The user's quota was changed.
338Gellens & Newman Standards Track [Page 6]
340RFC 5423 Internet Message Store Events March 2009
345 This section includes events related to changes in message flags.
348 One or more messages in the mailbox were marked as read or seen by
349 a user. Note that POP has no concept of read or seen messages, so
350 these events are only generated by IMAP or HTTP clients (or
353 The parameters include a mailbox identifier and a set of message
357 One or more messages were marked for future deletion by the user
358 but are still accessible over the protocol (the user's client may
359 or may not make these messages accessible through its user
362 The parameters include a mailbox identifier and a set of message
366 One or more messages in the mailbox had one or more IMAP flags or
369 The parameters include a list of IMAP flag or keyword names that
370 were set, a mailbox identifier, and the set of UIDs of affected
371 messages. The flagNames MUST NOT include \Recent. For
372 compatibility with simpler clients, it SHOULD be configurable
373 whether setting the \Seen or \Deleted flags results in this event
374 or the simpler MessageRead/MessageTrash events. By default, the
375 simpler message forms SHOULD be used for MessageRead and
379 One or more messages in the mailbox had one or more IMAP flags or
382 The parameters include a list of IMAP flag or keyword names that
383 were cleared, a mailbox identifier, and the set of UIDs of
384 affected messages. The flagNames parameter MUST NOT include
394Gellens & Newman Standards Track [Page 7]
396RFC 5423 Internet Message Store Events March 2009
3994.3. Access Accounting
401 This section lists events related to message store access accounting.
404 A user has logged into the system via IMAP, HTTP, POP, or some
407 The parameters include the domain name and port used to access the
408 server and the user's authorization identity. Additional possible
409 parameters include the client's IP address and port, the
410 authentication identity (if different from the authorization
411 identity), the service name, the authentication mechanism,
412 information about any negotiated security layers, a timestamp, and
416 A user has logged out or otherwise been disconnected from the
417 message store via IMAP, HTTP, POP, or some other mechanism.
419 The parameters include the server domain name and the user's
420 authorization identity. Additional parameters MAY include any of
421 the information from the "Login" event as well as information
422 about the type of disconnect (suggested values include graceful,
423 abort, timeout, and security layer error), the duration of the
424 connection or session, and other information.
4264.4. Mailbox Management
428 This section lists events related to the management of mailboxes.
431 A mailbox has been created, or an access control changed on an
432 existing mailbox so that it is now accessible by the user. If the
433 mailbox creation caused the creation of new mailboxes earlier in
434 the hierarchy, separate MailboxCreate events are not generated, as
435 their creation is implied.
437 The parameters include the created mailbox identifier, its
438 UIDVALIDITY for IMAP-accessible message stores, and MAY also
439 indicate which access protocol triggered the event. Access and
440 permissions information (such as Access Control List (ACL)
441 [RFC4314] settings) require a standardized format to be included,
442 and so are left for future extension.
450Gellens & Newman Standards Track [Page 8]
452RFC 5423 Internet Message Store Events March 2009
456 A mailbox has been deleted, or an access control changed on an
457 existing mailbox so that it is no longer accessible by the user.
458 Note that if the mailbox has child mailboxes, only the specified
459 mailbox has been deleted, not the children. The mailbox becomes
460 \NOSELECT, and the hierarchy remains unchanged, as per the
461 description of the DELETE command in IMAP4rev1 [RFC3501].
463 The parameters include the deleted mailbox identifier and MAY also
464 indicate which access protocol triggered the event.
467 A mailbox has been renamed. Note that, per the description of the
468 RENAME command in IMAP4rev1 [RFC3501], special semantics regarding
469 the mailbox hierarchy apply when INBOX is renamed (child mailboxes
470 are usually included in the rename, but are excluded when INBOX is
471 renamed). When a mailbox other than INBOX is renamed and its
472 child mailboxes are also renamed as a result, separate
473 MailboxRename events are not generated for the child mailboxes, as
474 their renaming is implied. If the rename caused the creation of
475 new mailboxes earlier in the hierarchy, separate MailboxCreate
476 events are not generated for those, as their creation is implied.
477 When INBOX is renamed, a new INBOX is created. A MailboxCreate
478 event is not generated for the new INBOX, since it is implied.
480 The parameters include the old mailbox identifier, the new mailbox
481 identifier, and MAY also indicate which access protocol triggered
485 A mailbox has been added to the server-stored subscription list,
486 such as the one managed by the IMAP SUBSCRIBE and UNSUBSCRIBE
489 The parameters include the user whose subscription list has been
490 affected, the mailbox identifier, and MAY also indicate which
491 access protocol triggered the event.
494 A mailbox has been removed from the subscription list.
496 The parameters include the user whose subscription list has been
497 affected, the mailbox identifier, and MAY also indicate which
498 access protocol triggered the event.
506Gellens & Newman Standards Track [Page 9]
508RFC 5423 Internet Message Store Events March 2009
513 This section lists parameters included with these events.
516 Included with all events generated by message access protocols.
518 The authentication identity associated with this event, as
519 distinct from the authorization identity (see "user"). This is
520 not included when it is the same as the value of the user
524 May be included with MessageAppend and MessageNew.
526 The IMAP BODYSTRUCTURE of the message.
529 Included with all events generated by message access protocols.
531 The IPv4 or IPv6 address of the message store access client that
532 performed the action that triggered the notification.
535 Included with all events generated by message access protocols.
537 The port number of the message store access client that performed
538 an action that triggered the notification (the port from which the
539 connection occurred).
542 Included with QuotaExceed, QuotaWithin, and QuotaChange
543 notifications relating to a user or mailbox disk quota. May be
544 included with other notifications.
546 Disk quota limit in kilobytes (1024 octets).
549 Included with QuotaExceed and QuotaWithin notifications relating
550 to a user or mailbox disk quota. May be included with other
553 Disk space used in kilobytes (1024 octets). Only disk space that
554 counts against the quota is included.
562Gellens & Newman Standards Track [Page 10]
564RFC 5423 Internet Message Store Events March 2009
568 May be included with the MessageNew notification.
570 The message transfer envelope associated with final delivery of
571 the message for the MessageNew notification. This includes the
572 MAIL FROM and relevant RCPT TO line(s) used for final delivery
573 with CRLF delimiters and any ESMTP parameters.
576 Included with FlagsSet and FlagsClear events. May be included
577 with MessageAppend and MessageNew to indicate flags that were set
578 initially by the APPEND command or delivery agent, respectively.
580 A list (likely to be space-separated) of IMAP flag or keyword
581 names that were set or cleared. Flag names begin with a backslash
582 while keyword names do not. The \Recent flag is explicitly not
583 permitted in the list.
586 Included in events that affect mailboxes. A URI describing the
587 mailbox. In the case of MailboxRename, this refers to the new
591 Included with QuotaExceed and QuotaWithin notifications relating
592 to a user or mailbox message count quota. May be included with
595 Quota limit on the number of messages in the mailbox, for events
596 referring to a mailbox.
599 May be included with MessageAppend and MessageNew.
601 The entire message itself. Size-based suppression of this SHOULD
605 May be included with MessageAppend and MessageNew.
607 Size of the RFC 5322 message itself in octets. This value matches
608 the length of the IMAP literal returned in response to an IMAP
609 FETCH of BODY[] for the referenced message.
618Gellens & Newman Standards Track [Page 11]
620RFC 5423 Internet Message Store Events March 2009
624 Included with QuotaExceed and QuotaWithin notifications relating
625 to a user or mailbox message count quota. May be included with
628 Number of messages in the mailbox. This is typically included
629 with message addition and deletion events.
632 May be included with any notification referring to one message.
634 This is the 64-bit integer MODSEQ as defined in [RFC4551]. No
635 assumptions about MODSEQ can be made if this is omitted.
638 A URI describing the old name of a renamed or moved mailbox.
641 May be included with any notification.
643 The process ID of the process that generated the notification.
646 May be included with any notification.
648 The name of the process that generated the notification.
651 Included in Login and optionally in Logout or other events. The
652 domain name or IP address (v4 or v6) used to access the server or
656 Included in Login and optionally in Logout or other events. The
657 port number used to access the server. This is often a well-known
661 May be included with any notification.
663 The fully qualified domain name of the server that generated the
664 event. Note that this may be different from the server name used
665 to access the mailbox included in the mailbox identifier.
674Gellens & Newman Standards Track [Page 12]
676RFC 5423 Internet Message Store Events March 2009
680 May be included with any notification.
682 The name of the service that triggered the event. Suggested
683 values include "imap", "pop", "http", and "admincli" (for an
684 administrative client).
687 May be included with any notification.
689 A list of UTF-8 tags (likely to be comma-separated). One or more
690 tags can be set at the time a notification criteria or
691 notification subscription is created. Subscribers can use tags
692 for additional client-side filtering or dispatch of events.
695 May be included with any notification.
697 The time at which the event occurred that triggered the
698 notification (the underlying protocol carrying the notification
699 may contain a timestamp for when the notification was generated).
700 This MAY be an approximate time.
702 Timestamps are expressed in local time and contain the offset from
703 UTC (this information is used in several places in Internet mail)
704 and are normally in [RFC3339] format.
707 May be included with any notification referring to a mailbox.
709 The UID that is projected to be assigned next in the mailbox.
710 This is typically included with message addition and deletion
711 events. This is equivalent to the UIDNEXT status item in the IMAP
715 Included with MessageExpires, MessageExpunges, MessageRead,
716 MessageTrash, FlagsSet, and FlagsClear.
718 This includes the set of IMAP UIDs referenced.
721 Included with all notifications. A reference to the IMAP server,
722 a mailbox, or a message.
724 Typically an IMAP URL. This can include the name of the server
725 used to access the mailbox/message, the mailbox name, the
726 UIDVALIDITY of the mailbox, and the UID of a specific message.
730Gellens & Newman Standards Track [Page 13]
732RFC 5423 Internet Message Store Events March 2009
736 Included with all events generated by message access protocols.
738 This is the authorization identifier used when the client
739 connected to the access protocol that triggered the event. Some
740 protocols (for example, many SASL mechanisms) distinguish between
741 authorization and authentication identifiers. For events
742 associated with a mailbox, this may be different from the owner of
743 the mailbox specified in the IMAP URL.
7456. IANA Considerations
747 The IANA has created a new registry for "Internet Message Store
748 Events" that contains two sub-registries: event names and event
749 parameters. For both event names and event parameters, entries that
750 do not start with "vnd." are added by the IETF and are intended for
751 interoperable use. Entries that start with "vnd." are intended for
752 private use by one or more parties and are allocated to avoid
755 The initial values are contained in this document.
757 Using IANA Considerations [RFC5226] terminology, entries that do not
758 start with "vnd." are allocated by IETF Consensus, while those
759 starting with "vnd." are allocated First Come First Served.
7617. Security Considerations
763 Notifications can produce a large amount of traffic and expose
764 sensitive information. When notification mechanisms are used to
765 maintain state between different entities, the ability to corrupt or
766 manipulate notification messages could enable an attacker to modulate
767 the state of these entities. For example, if an attacker were able
768 to modify notifications sent from a message store to an auditing
769 server, he could modify the "user" and "messageContent" parameters in
770 MessageNew notifications to create false audit log entries.
772 A competent transfer protocol for notifications must consider
773 authentication, authorization, privacy, and message integrity, as
774 well as denial-of-service issues. While the IETF has adequate tools
775 and experience to address these issues for mechanisms that involve
776 only one TCP connection, notification or publish/subscribe protocols
777 that are more sophisticated than a single end-to-end TCP connection
778 will need to pay extra attention to these issues and carefully
779 balance requirements to successfully deploy a system with security
780 and privacy considerations.
786Gellens & Newman Standards Track [Page 14]
788RFC 5423 Internet Message Store Events March 2009
793 Alexey Melnikov, Arnt Gulbrandsen, and Zoltan Ordogh have reviewed
794 and offered improvements to this document. Richard Barnes did a nice
795 review during Last Call.
7999.1. Normative References
801 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
802 Requirement Levels", BCP 14, RFC 2119, March 1997.
804 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
805 4rev1", RFC 3501, March 2003.
807 [RFC5092] Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092,
810 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
811 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
8149.2. Informative References
816 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
817 STD 53, RFC 1939, May 1996.
819 [RFC2177] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997.
821 [RFC2447] Dawson, F., Mansour, S., and S. Silverberg, "iCalendar
822 Message-Based Interoperability Protocol (iMIP)", RFC 2447,
825 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
826 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
827 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
829 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
830 Internet: Timestamps", RFC 3339, July 2002.
832 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message
833 Context for Internet Mail", RFC 3458, January 2003.
835 [RFC4146] Gellens, R., "Simple New Mail Notification", RFC 4146,
842Gellens & Newman Standards Track [Page 15]
844RFC 5423 Internet Message Store Events March 2009
847 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
848 RFC 4314, December 2005.
850 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
851 Security Layer (SASL)", RFC 4422, June 2006.
853 [RFC4467] Crispin, M., "Internet Message Access Protocol (IMAP) -
854 URLAUTH Extension", RFC 4467, May 2006.
856 [RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional
857 STORE Operation or Quick Flag Changes Resynchronization",
860 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
898Gellens & Newman Standards Track [Page 16]
900RFC 5423 Internet Message Store Events March 2009
903Appendix A. Future Extensions
905 This document specifies core functionality based on events that are
906 believed to be well understood, have known use cases, and are
907 implemented by at least one deployed real-world Internet message
908 store. (A few events are exceptions to the last test only: FlagsSet,
909 FlagsClear, MailboxCreate, MailboxDelete, MailboxRename,
910 MailboxSubscribe, and MailboxUnSubscribe.)
912 Some events have been suggested but are postponed to future
913 extensions because they do not meet this criteria. These events
914 include messages that have been moved to archive storage and may
915 require extra time to access, quota by message context,
916 authentication failure, user mail account disabled, annotations, and
917 mailbox ACL or metadata change. The descriptions of several events
918 note additional parameters that are likely candidates for future
919 inclusion. See Section 6 for how the list of events and parameters
922 In order to narrow the scope of this document to something that can
923 be completed, only events generated from the message store (by a
924 message access module, administrative module, or message delivery
925 agent) are considered. A complete mail system is normally linked
926 with an identity system that would also publish events of interest to
927 a message store event subscriber. Events of interest include account
928 created/deleted/disabled and password changed/expired.
933 QUALCOMM Incorporated
939 EMail: rg+ietf@qualcomm.com
945 Monrovia, CA 91016-6347
949 EMail: chris.newman@sun.com
954Gellens & Newman Standards Track [Page 17]