idnits 2.17.1 draft-ietf-lemonade-msgevent-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 969. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 980. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 987. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 993. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o Corrected occurrences of "MUST not" to be "MUST NOT". -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2, 2008) is 5654 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 2447 (Obsoleted by RFC 6047) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 4551 (Obsoleted by RFC 7162) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lemonade R. Gellens 3 Internet-Draft QUALCOMM Incorporated 4 Expires: May 6, 2009 C. Newman 5 Sun Microsystems 6 November 2, 2008 8 Internet Message Store Events 9 draft-ietf-lemonade-msgevent-07.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 6, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 One of the missing features in the existing Internet mail and 43 messaging standards is a facility for server-to-server and server-to- 44 client event notifications related to message store events. As the 45 scope of Internet mail expands to support more diverse media (such as 46 voice mail), devices (such as cell phones) and to provide rich 47 interactions with other services (such as web portals and legal 48 compliance systems), the need for an interoperable notification 49 system increases. This document attempts to enumerate the types of 50 events which interest real-world consumers of such a system. 52 This document describes events and event parameters which are useful 53 for several cases, including notification to administrative systems 54 and end users. This is not intended as a replacement for a message 55 access facility such as IMAP. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Conventions Used in this Document . . . . . . . . . . . . 4 61 1.2. Change History . . . . . . . . . . . . . . . . . . . . . . 4 62 1.2.1. Changes from -06 to -07 . . . . . . . . . . . . . . . 4 63 1.2.2. Changes from -05 to -06 . . . . . . . . . . . . . . . 5 64 1.2.3. Changes from -04 to -05 . . . . . . . . . . . . . . . 5 65 1.2.4. Changes from -03 to -04 . . . . . . . . . . . . . . . 6 66 1.2.5. Changes from -02 to -03 . . . . . . . . . . . . . . . 6 67 1.2.6. Changes from -01 to -02 . . . . . . . . . . . . . . . 6 68 1.2.7. Changes from -00 to -01 . . . . . . . . . . . . . . . 7 69 1.2.8. Changes from draft-newman-lemonade-msgevent-00.txt 70 to draft-ietf-lemonade-msgevent-00.txt . . . . . . . . 7 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3. Event Model . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 4. Event Types . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.1. Message Addition and Deletion . . . . . . . . . . . . . . 9 75 4.2. Message Flags . . . . . . . . . . . . . . . . . . . . . . 11 76 4.3. Access Accounting . . . . . . . . . . . . . . . . . . . . 11 77 4.4. Mailbox Management . . . . . . . . . . . . . . . . . . . . 12 78 5. Event Parameters . . . . . . . . . . . . . . . . . . . . . . . 13 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 81 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 84 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 85 Appendix A. Future Extensions . . . . . . . . . . . . . . . . . . 20 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 87 Intellectual Property and Copyright Statements . . . . . . . . . . 22 89 1. Introduction 91 A message store is used to organize Internet Messages [RFC2822] into 92 one or more mailboxes, possibly hierarchical, annotate them in 93 various ways and provide access to these messages and associated 94 meta-data. Three different standards-based protocols have been 95 widely deployed to remotely access a message store. Post Office 96 Protocol (POP) [RFC1939] provides simple download-and-delete access 97 to a single mail drop (which is a subset of the functionality 98 typically associated with a message store). Internet Message Access 99 Protocol (IMAP) [RFC3501] provides an extensible feature-rich model 100 for online, offline and disconnected access to a message store with 101 minimal constraints on any associated "fat-client" user interface. 102 Finally, mail access applications built on top of Hypertext Transfer 103 Protocol (HTTP) [RFC2616] which run in standards-based web browsers 104 provide a third standards-based access mechanism for online-only 105 access. 107 While simple and/or ad-hoc mechanisms for notifications have sufficed 108 to some degree in the past (e.g., Simple New Mail Notification 109 [RFC4146], IMAP4 IDLE command [RFC2177]), as the scope and importance 110 of message stores expands, the demand for a more complete store 111 notification system increases. Some of the driving forces behind 112 this demand include: 114 o Mobile devices with intermittent network connectivity that have 115 "new mail" or "message count" indicators 117 o Unified messaging systems which include both Internet and voice 118 mail require support for a message waiting indicator on phones 120 o Interaction with systems for event-based or utility-computing 121 billing 123 o Simplify the process of passing message store events to non- 124 Internet notification systems 126 o A calendar system may wish to subscribe to MessageNew 127 notifications in order to support iMIP [RFC2447]. 129 o Some jurisdictions have laws or regulations for information 130 protection and auditing which require interoperable protocols 131 between message stores built by messaging experts and compliance 132 auditing systems built by compliance experts. 134 Vendors who have deployed proprietary notification systems for their 135 Internet message stores have seen significant demand to provide 136 notifications for more and more events. As a first step towards 137 building a notification system, this document attempts to enumerate 138 the core events that real-world customers demand. 140 This document includes those events which can be generated by the use 141 of IMAP4Rev1 [RFC3501] and some existing extensions. As new IMAP 142 extensions are defined, or additional event types or parameters need 143 to be added, the set specified here can be extended by means of an 144 IANA registry with update requirements, as specified in Section 6. 146 1.1. Conventions Used in this Document 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in RFC 2119 [RFC2119] 151 When these words appear in lower-case or with initial-capital 152 letters, they are not RFC 2119 key words. 154 1.2. Change History 156 This section to be removed if/when this draft is published as an RFC. 158 1.2.1. Changes from -06 to -07 160 o Corrected occurrences of "MUST not" to be "MUST NOT". 162 o Clarified that an "IP address" can be IPv4 or IPv6. 164 o Updated RFC 2434 to RFC 5226. 166 o Clarified "subscription list" in MailboxSubscribe description. 168 o Changed specification of the timestamp parameter to be when the 169 event which triggered the notification occurred, not when the 170 notification was generated. 172 o Clarified that the timestamp parameter is expressed in local time 173 and offset from UTC, and is normally in RFC 3339 format. 175 o Clarified the description of the flagNames parameter so that 176 space-separation is not normative. 178 o Clarified the description of the tags parameter so that comma- 179 separation is not normative. 181 o Clarified the description of the user parameter to not rely on 182 SASL. 184 o Added new paragraph to Abstract explaining that the notfications 185 described here are not intended as a substitute for a message 186 access facility such as IMAP. 188 o Clarified that the timestamp parameter MAY be an approximate 189 value. 191 1.2.2. Changes from -05 to -06 193 o Added discussion of message integrity to Security Considerations 194 (Section 7). 196 o Reviewed use of "may", "must" and "should" for conversion to 197 "MAY", "MUST" and "SHOULD". 199 o Reworded MessageNew and MessageExpire text. 201 o Additional clarifying text added to Future Extensions 202 (Appendix A). 204 o Added explicit prohibition on \Recent in FlagsSet to match the one 205 in FlagsClear (\Recent was also explicitly excluded from 206 flagNames). 208 o Clarified that Logout disconnection types are suggestions only. 210 o Added serverDomain and serverPort parameters, and clarified 211 clientPort. 213 o Clarified that a kilobyte is 1024 octets. 215 o Clarified that FlagSet and FlagClear include one or more flags or 216 keywords. 218 o Changed "cover about 95% of the known use cases" to "an 219 overwhelming majority of known use cases" in Event Types 220 (Section 4). 222 1.2.3. Changes from -04 to -05 224 o Reworded statement on optional versus mandatory and removed Anchor 225 11. 227 o Included mailbox admin events in list of exceptions in Appendix A, 228 and deleted Anchor 23. 230 1.2.4. Changes from -03 to -04 232 o Added QuotaChange event. 234 1.2.5. Changes from -02 to -03 236 o Fix typo in Login event 238 o Remove UIDVALIDITY from MailboxRename event. 240 o Made event names hierarchical: Changed AppendMessage to 241 MessageAppend, ExpireMessage to MessageExpire, ExpungeMessage to 242 MessageExpunge, NewMessage to MessageNew, OverQuota to 243 QuotaExceed, UnderQuota to QuotaWithin, ReadMessages to 244 MessageRead, TrashMessages to MessageTrash, SetFlags to FlagsSet, 245 and ClearFlags to FlagsClear; deleted Editor's Note asking if this 246 should be done. 248 o Made ACL information a future extension in MailboxCreate. 250 1.2.6. Changes from -01 to -02 252 o Add text indicating that mailboxes may contain Internet messages 253 and/or child mailboxes. 255 o Remove word "folder" from definition of "mailbox." 257 o Add editor's note regarding optionality in this document. 259 o Add editor's note regarding optional vs. mandatory events. 261 o Add editor's note regarding event names. 263 o Remove U.S.-centric wording regarding laws. 265 o Review uses of "will" and change as appropriate. 267 o Clarification of server address in login event. 269 o Add MailboxCreate, MailboxDelete, MailboxRename, and 270 MailboxSubscribe events. 272 o Add mailboxName and oldMailboxName parameter.s 274 o Move RFC2822 from normative to informative. 276 o Add IANA Considerations and reference to RFC 2434. 278 o Minor grammatical improvements. 280 o Incorporate edits from Alexey Melnikov. 282 o Add editor's note regarding deployment of mailbox admin events. 284 o Add Acknowledgments section. 286 o Fix formatting to add blank line between paragraphs in event and 287 parameter lists. 289 o Add reference to RFC 2119 and "Conventions" section. 291 o Update RFC 2222 to RFC 4422. 293 1.2.7. Changes from -00 to -01 295 o Add modseq event parameter. 297 o Add tags event parameter. 299 1.2.8. Changes from draft-newman-lemonade-msgevent-00.txt to 300 draft-ietf-lemonade-msgevent-00.txt 302 o Rename draft title 304 o Add Change History section. 306 o Update reference to URLAUTH. 308 o Add FlagsSet, FlagsClear events and flagNames parameter. Update 309 future events section to reflect this change. 311 o Removed unnecessary normative reference to NAMESPACE. 313 2. Terminology 315 The following terminology is used in this document: 317 mailbox 318 A container for Internet messages and/or child mailboxes. A 319 mailbox may or may not permit delivery of new messages via a mail 320 delivery agent. 322 mailbox identifier 323 A mailbox identifier provides sufficient information to identify a 324 specific mailbox on a specific server instance. An IMAP URL can 325 be a mailbox identifier. 327 message access protocols 328 Protocols which provide clients (e.g., a mail user agent or web 329 browser) with access to the message store including but not 330 limited to IMAP, POP and HTTP. 332 message context 333 As defined in [RFC3458]. 335 UIDVALIDITY 336 As defined in IMAP4rev1 [RFC3501]. UIDVALIDITY is critical to the 337 correct operation of a caching mail client. When it changes, the 338 client MUST flush its cache. It's particularly important to 339 include UIDVALIDITY with event notifications related to message 340 addition or removal in order to keep the message data correctly 341 synchronized. 343 3. Event Model 345 The events that are generated by a message store depend to some 346 degree on the model used to represent a message store. The model the 347 IETF has for a message store is implicit from IMAP4rev1 and 348 extensions, so that model is assumed by this document. 350 A message store event typically has an associated mailbox name and 351 usually has an associated user name (or authorization identity if 352 using the terminology from SASL [RFC4422]). Events referring to a 353 specific message can use an IMAP URL [RFC5092] to do so. Events 354 referring to a set of messages can use an IMAP URL to the mailbox 355 plus an IMAP UID set. 357 Each notification has a type and parameters. The type determines the 358 type of event, while the parameters supply information about the 359 context of the event that may be used to adjust subscription 360 preferences or may simply supply data associated with the event. The 361 types and parameter names in this document are restricted to US-ASCII 362 printable characters so these events can be easily mapped to an 363 arbitrary notification system. However, this document assumes 364 arbitrary parameter values (including large and multi-line values) 365 can be encoded with the notification system. Systems which lack that 366 feature could only implement a subset of these events. 368 This document does not indicate which event parameters are mandatory 369 or optional. That is done in documents which specify specific 370 message formats or bindings to a notification system. 372 For scalability reasons, some degree of filtering at event generation 373 is necessary. At the very least, the ability to turn on and off 374 groups of related events and to suppress inclusion of large 375 parameters (such as messageContent) is needed. A sophisticated 376 publish/subscribe notification system may be able to propagate 377 cumulative subscription information to the publisher. 379 Some of these events might be logically collapsed into a single event 380 type with a required parameter to distinguish between the cases 381 (e.g., QuotaExceed and QuotaWithin). However until such time that an 382 event subscription model is formulated, it's not practical to make 383 such decisions. We thus note only the fact that some of these events 384 may be viewed as a single event type. 386 4. Event Types 388 This section discusses the different types of events useful in a 389 message store event notification system. The intention is to 390 document the events sufficient to cover an overwhelming majority of 391 known use cases while leaving less common event types for the future. 392 This section mentions parameters which are important or specific to 393 the events described here. Event parameters likely to be included in 394 most or all notifications are discussed in the next section. 396 4.1. Message Addition and Deletion 398 This section includes events related to message addition and 399 deletion. 401 MessageAppend 402 A message was appended or concatenated to a mailbox by a message 403 access client. For the most part, this is identical to the 404 MessageNew event type, except that the SMTP envelope information 405 is not included as a parameter, but information about which 406 protocol triggered the event MAY be included. See the MessageNew 407 event for more information. 409 MessageExpire 410 One or more messages were expired from a mailbox due to server 411 expiration policy and are no longer accessible by the end-user. 413 The parameters include a mailbox identifier which MUST include 414 UIDVALIDITY, and a UID set which describes the messages. 416 Information about which server expiration policy was applied may 417 be included in the future. 419 MessageExpunge 420 One or more messages were expunged from a mailbox by an IMAP 421 CLOSE/EXPUNGE, POP3 DELE+QUIT, HTTP or equivalent client action 422 and are no longer accessible by the end-user. 424 The parameters include a mailbox identifier which MUST include 425 UIDVALIDITY, a UID set, and MAY also indicate which access 426 protocol triggered the event. 428 MessageNew 429 A new message was received into a mailbox via a message delivery 430 agent. 432 The parameters include a message identifier which for IMAP- 433 accessible message stores MUST include UIDVALIDITY and UID. The 434 parameters MAY also include SMTP envelope and other arbitrary 435 message and mailbox meta-data. In some cases, the entire new 436 message itself may be included. The set of parameters SHOULD be 437 adjustable to the client's preference with limits set by server 438 policy. An interesting policy, for example, would be to include 439 messages up to 2K in size with the notification, but for larger 440 messages to include a URLAUTH [RFC4467] reference. 442 QuotaExceed 443 An operation failed (typically MessageNew) because the user's 444 mailbox exceeded one of the quotas (e.g., disk quota, message 445 quota, quota by message context, etc). The parameters SHOULD 446 include at least the relevant user and quota, and optionally the 447 mailbox. Quota usage SHOULD be included if possible. Parameters 448 needed to extend this to support quota by context are not 449 presently described in this document, but could be added in the 450 future. 452 QuotaWithin 453 An operation occurred (typically MessageExpunges or 454 MessageExpires) which reduced the user's quota usage under their 455 limit. 457 QuotaChange 458 The user's quota was changed. 460 4.2. Message Flags 462 This section includes events related to changes in message flags. 464 MessageRead 465 One or more messages in the mailbox were marked as read or seen by 466 a user. Note that POP has no concept of read or seen messages, so 467 these events are only generated by IMAP or HTTP clients (or 468 equivalent). 470 The parameters include a mailbox identifier and a set of message 471 UIDs. 473 MessageTrash 474 One or more messages were marked for future deletion by the user 475 but are still accessible over protocol (the user's client may or 476 may not make these messages accessible through its user 477 interface). 479 The parameters include a mailbox identifier and a set of message 480 UIDs. 482 FlagsSet 483 One or more messages in the mailbox had one or more IMAP flags or 484 keyword sets. 486 The parameters include a list of IMAP flag or keyword names that 487 were set, a mailbox identifier and a set of message UIDs that were 488 impacted. The flagNames MUST NOT include \Recent. For 489 compatibility with simpler clients, it SHOULD be configurable 490 whether setting the \Seen or \Deleted flags results in this event 491 or the simpler MessageRead/MessageTrash events. By default, the 492 simpler message forms SHOULD be used for MessageRead and 493 MessageTrash. 495 FlagsClear 496 One or more messages in the mailbox had one or more IMAP flags or 497 keywords cleared. 499 The parameters include a list of IMAP flag or keyword names that 500 were cleared, a mailbox identifier and a set of message UIDs that 501 were impacted. The flagNames parameter MUST NOT include \Recent. 503 4.3. Access Accounting 505 This section lists events related to message store access accounting. 507 Login 508 A user has logged in to the system via IMAP, HTTP, POP or some 509 other mechanism. 511 The parameters include the domain name and port used to access the 512 server and the user's authorization identity. Additional possible 513 parameters include the client's IP address and port, the 514 authentication identity (if different from the authorization 515 identity), the service name, the authentication mechanism, 516 information about any negotiated security layers, a timestamp and 517 other information. 519 Logout 520 A user has logged out or otherwise been disconnected from the 521 message store via IMAP, HTTP, POP or some other mechanism. 523 The parameters include the server domain name and the user's 524 authorization identity. Additional parameters MAY include any of 525 the information from the "Login" event as well as information 526 about the type of disconnect (suggested values include graceful, 527 abort, timeout, and security layer error), the duration of the 528 connection or session and other information. 530 4.4. Mailbox Management 532 This section lists events related to the management of mailboxes. 534 MailboxCreate 535 A mailbox has been created, or an access control changed on an 536 existing mailbox so that it is now accessible by the user. If the 537 mailbox creation caused the creation of new mailboxes earlier in 538 the hierarchy, separate MailboxCreate events are not generated for 539 those as their creation is implied. 541 The parameters include the created mailbox identifier, its 542 UIDVALIDITY for IMAP-accessible message stores, and MAY also 543 indicate which access protocol triggered the event. Access/ 544 permissions information (such as ACL [RFC4314] settings) require a 545 standardized format to be included, and so are left for future 546 extension. 548 MailboxDelete 549 A mailbox has been deleted, or an access control changed on an 550 existing mailbox so that it is no longer accessible by the user. 551 Note that if the mailbox has child mailboxes, only the specified 552 mailbox has been deleted, not the children. The mailbox becomes 553 \NOSELECT and the hierarchy remains unchanged, as per the 554 description of the DELETE command in RFC 3501IMAP4rev1 [RFC3501]. 556 The parameters include the deleted mailbox identifier, and MAY 557 also indicate which access protocol triggered the event. 559 MailboxRename 560 A mailbox has been renamed. Note that, per the description of the 561 RENAME command in RFC 3501IMAP4rev1 [RFC3501], special semantics 562 regarding the mailbox hierarchy apply when INBOX is renamed (child 563 mailboxes are usually included in the rename, but are excluded 564 when INBOX is renamed). When a mailbox other than INBOX is 565 renamed and its child mailboxes are also renamed as a result, 566 separate MailboxRename events are not generated for the child 567 mailboxes, as their renaming is implied. If the rename caused the 568 creation of new mailboxes earlier in the hierarchy, separate 569 MailboxCreate events are not generated for those as their creation 570 is implied. When INBOX is renamed, a new INBOX is created. A 571 MailboxCreate event is not generated for the new INBOX, since it 572 is implied. 574 The parameters include the old mailbox identifier, the new mailbox 575 identifier, and MAY also indicate which access protocol triggered 576 the event. 578 MailboxSubscribe 579 A mailbox has been added to the server-stored subscription list, 580 such as the one managed by the IMAP SUBSCRIBE and UNSUBSCRIBE 581 commands. 583 The parameters include the user whose subscription list has been 584 affected and the mailbox identifier, and MAY also indicate which 585 access protocol triggered the event. 587 MailboxUnSubscribe 588 A mailbox has been removed from the subscription list. 590 The parameters include the user whose subscription list has been 591 affected and the mailbox identifier, and MAY also indicate which 592 access protocol triggered the event. 594 5. Event Parameters 596 This section lists parameters included with these events. 598 admin 600 Included with all events generated by message access protocols. 602 The authentication identity associated with this event, as 603 distinct from the authorization identity (see "user"). This is 604 not included when it is the same as the value of the user 605 parameter. 607 bodyStructure 609 May be included with MessageAppend and MessageNew. 611 The IMAP BODYSTRUCTURE of the message. 613 clientIP 615 Included with all events generated by message access protocols. 617 The IPv4 or IPv6 address of the message store access client which 618 performed the action which triggered the notification. 620 clientPort 622 Included with all events generated by message access protocols. 624 The port number of the message store access client which performed 625 an action which triggered the notification (the port from which 626 the connection occurred). 628 diskQuota 630 Included with QuotaExceed, QuotaWithin, and QuotaChange 631 notifications relating to a user or mailbox disk quota. May be 632 included with other notifications. 634 Disk quota limit in kilobytes (1024 octets). 636 diskUsed 638 Included with QuotaExceed and QuotaWithin notifications relating 639 to a user or mailbox disk quota. May be included with other 640 notifications. 642 Disk space used in kilobytes (1024 octets). Only disk space which 643 counts against the quota is included. 645 envelope 647 May be included with the MessageNew notification. 649 The message transfer envelope associated with final delivery of 650 the message for the MessageNew notification. This includes the 651 MAIL FROM and relevant RCPT TO line(s) used for final delivery 652 with CRLF delimiters and any ESMTP parameters. 654 flagNames 656 Included with FlagsSet and FlagsClear events. May be included 657 with MessageAppend and MessageNew to indicate flags which were set 658 initially by the APPEND command or delivery agent respectively. 660 A list (likely to be space-separated) of IMAP flag or keyword 661 names that were set or cleared. Flag names begin with backslash 662 while keyword names do not. The \Recent flag is explicitly not 663 permitted in the list. 665 mailboxID 667 Included in events which affect mailboxes. URI describing the 668 mailbox. In the case of MailboxRename, this refers to the new 669 name. 671 maxMessages 673 Included with QuotaExceed and QuotaWithin notifications relating 674 to a user or mailbox message count quota. May be included with 675 other notifications. 677 Quota limit on the number of messages in the mailbox, for events 678 referring to a mailbox. 680 messageContent 682 May be included with MessageAppend and MessageNew. 684 The entire message itself. Size based suppression of this SHOULD 685 be available. 687 messageSize 689 May be included with MessageAppend and MessageNew. 691 Size of the RFC 2822 message itself in octets. This value matches 692 the length of the IMAP literal returned in response to an IMAP 693 FETCH of BODY[] for the referenced message. 695 messages 697 Included with QuotaExceed and QuotaWithin notifications relating 698 to a user or mailbox message count quota. May be included with 699 other notifications. 701 Number of messages in the mailbox. This is typically included 702 with message addition and deletion events. 704 modseq 706 May be included with any notification referring to one message. 708 This is the 64-bit integer MODSEQ as defined in [RFC4551]. No 709 assumptions about MODSEQ can be made if this is omitted. 711 oldMailboxID 713 URI describing the old name of a renamed or moved mailbox. 715 pid 717 May be included with any notification. 719 The process ID of the process which generated the notification. 721 process 723 May be included with any notification. 725 The name of the process which generated the notification. 727 serverDomain Included in Login, and optionally in Logout or other 728 events. The domain name or IP address (v4 or v6) used to access 729 the server or mailbox. 731 serverPort Included in Login, and optionally in Logout or other 732 events. The port number used to access the server. This is often 733 a well-known port. 735 serverFQDN 737 May be included with any notification. 739 The fully qualified domain name of the server which generated the 740 event. Note that this may be different from the server name used 741 to access the mailbox included in the mailbox identifier. 743 service 745 May be included with any notification. 747 The name of the service which triggered the event. Suggested 748 values include "imap", "pop", "http", and "admincli" (for an 749 administrative client). 751 tags 753 May be included with any notification. 755 A list of UTF-8 tags (likely to be comma-separated). One or more 756 tags can be set at the time a notification criteria or 757 notification subscription is created. Subscribers can use tags 758 for additional client-side filtering or dispatch of events. 760 timestamp 762 May be included with any notification. 764 The time at which the event occurred which triggered the 765 notification (the underlying protocol carrying the notification 766 may contain a timestamp for when the notification was generated). 767 This MAY be an approximate time. 769 Timestamps are expressed in local time and contain the offset from 770 UTC (this information is used in several places in Internet mail), 771 and would normally be in [RFC3339] format. 773 uidnext 775 May be included with any notification referring to a mailbox. 777 The UID that is projected to be assigned next in the mailbox. 778 This is typically included with message addition and deletion 779 events. This is equivalent to the UIDNEXT status item in the IMAP 780 STATUS command. 782 uidset 784 Included with MessageExpires, MessageExpunges, MessageRead, 785 MessageTrash, FlagsSet and FlagsClear. 787 This includes the set of IMAP UIDs referenced. 789 uri 791 Included with all notifications and refers to the IMAP server, a 792 mailbox or a message. 794 Typically an IMAP URL. This can include the name of the server 795 used to access the mailbox/message, the mailbox name, the 796 UIDVALIDITY of the mailbox, and the UID of a specific message. 798 user 800 Included with all events generated by message access protocols. 802 This is the authorization identifier used when the client 803 connected to the access protocol which triggered the event. Some 804 protocols (for example, many SASL mechanisms) distinguish between 805 authorization and authentication identifiers. For events 806 associated with a mailbox, this may be different from the owner of 807 the mailbox specified in the IMAP URL. 809 6. IANA Considerations 811 The IANA is requested to create a new registry for "Internet Message 812 Store Events" containing two sub-registries: event names and event 813 parameters. For both event names and event parameters, entries which 814 do not start with "vnd." are added by the IETF and intended for 815 interoperable use. Entries which start with "vnd." are intended for 816 private use by one or more parties and are allocated to avoid 817 collisions. 819 The initial values are contained in this document. 821 Using IANA Considerations [RFC5226] terminology, entries which do not 822 start with "vnd." are allocated by IETF Consensus, while those 823 starting with "vnd." are allocated First Come First Served. 825 7. Security Considerations 827 Notifications can produce a large amount of traffic and expose 828 sensitive information. When notification mechanisms are used to 829 maintain state between a different entities, the ability to corrupt 830 or manipulate notification messages could enable an attacker to 831 modulate the state of these entities. For example, if an attacker 832 were able to modify notifications sent from a message store to an 833 auditing server, he could modify the "user" and "messageContent" 834 parameters in MessageNew notifications to create false audit log 835 entries. 837 A competent transfer protocol for notifications must consider 838 authentication, authorization, privacy, and message integrity, as 839 well as denial-of-service issues. While the IETF has adequate tools 840 and experience to address these issues for mechanisms which involve 841 only one TCP connection, notification or publish/subscribe protocols 842 which are more sophisticated than a single end-to-end TCP connection 843 will need to pay extra attention to these issues and carefully 844 balance requirements to successfully deploy a system with security 845 and privacy considerations. 847 8. Acknowledgments 849 Alexey Melnikov, Arnt Gulbrandsen, and Zoltan Ordogh have reviewed 850 and offered improvements to this draft. Richard Barnes did a nice 851 review during Last Call. 853 9. References 855 9.1. Normative References 857 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 858 Requirement Levels", BCP 14, RFC 2119, March 1997. 860 [RFC5092] Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092, 861 November 2007. 863 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 864 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 865 May 2008. 867 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 868 4rev1", RFC 3501, March 2003. 870 9.2. Informative References 872 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 873 RFC 4314, December 2005. 875 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 876 STD 53, RFC 1939, May 1996. 878 [RFC2177] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997. 880 [RFC2447] Dawson, F., Mansour, S., and S. Silverberg, "iCalendar 881 Message-Based Interoperability Protocol (iMIP)", RFC 2447, 882 November 1998. 884 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 885 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 886 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 888 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 889 April 2001. 891 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 892 Internet: Timestamps", RFC 3339, July 2002. 894 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 895 Context for Internet Mail", RFC 3458, January 2003. 897 [RFC4146] Gellens, R., "Simple New Mail Notification", RFC 4146, 898 August 2005. 900 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 901 Security Layer (SASL)", RFC 4422, June 2006. 903 [RFC4467] Crispin, M., "Internet Message Access Protocol (IMAP) - 904 URLAUTH Extension", RFC 4467, May 2006. 906 [RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional 907 STORE Operation or Quick Flag Changes Resynchronization", 908 RFC 4551, June 2006. 910 Appendix A. Future Extensions 912 This document specifies core functionality based on events which are 913 believed to be well understood, have known use cases and are 914 implemented by at least one deployed real-world Internet message 915 store. (A few events are exceptions to the last test only: FlagsSet, 916 FlagsClear, MailboxCreate, MailboxDelete, MailboxRename, 917 MailboxSubscribe, and MailboxUnSubscribe.) 919 Some events have been suggested, but are postponed to future 920 extensions because they do not meet this criteria. These events 921 include messages which have been moved to archive storage and may 922 require extra time to access, quota by message context, 923 authentication failure, user mail account disabled, annotations, and 924 mailbox ACL or metadata change. The descriptions of several events 925 note additional parameters which are likely candidates for future 926 inclusion. See Section 6 for how the list of events and parameters 927 can be extended. 929 In order to narrow the scope of this document to something that can 930 be completed, only events generated from the message store (by a 931 message access module, administrative module or message delivery 932 agent) are considered. A complete mail system is normally linked 933 with an identity system which would also publish events of interest 934 to a message store event subscriber. Events of interest include 935 account created/deleted/disabled and password changed/expired. 937 Authors' Addresses 939 Randall Gellens 940 QUALCOMM Incorporated 941 5775 Morehouse Drive 942 San Diego, CA 92651 943 US 945 Email: rg+ietf@qualcomm.com 947 Chris Newman 948 Sun Microsystems 949 800 Royal Oaks 950 Monrovia, CA 91016-6347 951 US 953 Email: chris.newman@sun.com 955 Full Copyright Statement 957 Copyright (C) The IETF Trust (2008). 959 This document is subject to the rights, licenses and restrictions 960 contained in BCP 78, and except as set forth therein, the authors 961 retain all their rights. 963 This document and the information contained herein are provided on an 964 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 965 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 966 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 967 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 968 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 969 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 971 Intellectual Property 973 The IETF takes no position regarding the validity or scope of any 974 Intellectual Property Rights or other rights that might be claimed to 975 pertain to the implementation or use of the technology described in 976 this document or the extent to which any license under such rights 977 might or might not be available; nor does it represent that it has 978 made any independent effort to identify any such rights. Information 979 on the procedures with respect to rights in RFC documents can be 980 found in BCP 78 and BCP 79. 982 Copies of IPR disclosures made to the IETF Secretariat and any 983 assurances of licenses to be made available, or the result of an 984 attempt made to obtain a general license or permission for the use of 985 such proprietary rights by implementers or users of this 986 specification can be obtained from the IETF on-line IPR repository at 987 http://www.ietf.org/ipr. 989 The IETF invites any interested party to bring to its attention any 990 copyrights, patents or patent applications, or other proprietary 991 rights that may cover technology that may be required to implement 992 this standard. Please address the information to the IETF at 993 ietf-ipr@ietf.org. 995 Acknowledgment 997 Funding for the RFC Editor function is provided by the IETF 998 Administrative Support Activity (IASA).