idnits 2.17.1 draft-ietf-lemonade-msgevent-06.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 918. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 929. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 936. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 942. 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: The parameters include a list of IMAP flag or keyword names that were set, a mailbox identifier and a set of message UIDs that were impacted. The flagNames MUST not include \Recent. For compatibility with simpler clients, it SHOULD be configurable whether setting the \Seen or \Deleted flags results in this event or the simpler MessageRead/MessageTrash events. By default, the simpler message forms SHOULD be used for MessageRead and MessageTrash. == 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: The parameters include a list of IMAP flag or keyword names that were cleared, a mailbox identifier and a set of message UIDs that were impacted. The flagNames parameter MUST not include \Recent. -- 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 (July 10, 2008) is 5762 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 2434 (Obsoleted by RFC 5226) ** 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 (~~), 4 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: January 11, 2009 C. Newman 5 Sun Microsystems 6 July 10, 2008 8 Internet Message Store Events 9 draft-ietf-lemonade-msgevent-06.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 January 11, 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 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Conventions Used in this Document . . . . . . . . . . . . 4 56 1.2. Change History . . . . . . . . . . . . . . . . . . . . . . 4 57 1.2.1. Changes from -05 to -06 . . . . . . . . . . . . . . . 4 58 1.2.2. Changes from -04 to -05 . . . . . . . . . . . . . . . 5 59 1.2.3. Changes from -03 to -04 . . . . . . . . . . . . . . . 5 60 1.2.4. Changes from -02 to -03 . . . . . . . . . . . . . . . 5 61 1.2.5. Changes from -01 to -02 . . . . . . . . . . . . . . . 5 62 1.2.6. Changes from -00 to -01 . . . . . . . . . . . . . . . 6 63 1.2.7. Changes from draft-newman-lemonade-msgevent-00.txt 64 to draft-ietf-lemonade-msgevent-00.txt . . . . . . . . 6 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3. Event Model . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 4. Event Types . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.1. Message Addition and Deletion . . . . . . . . . . . . . . 8 69 4.2. Message Flags . . . . . . . . . . . . . . . . . . . . . . 10 70 4.3. Access Accounting . . . . . . . . . . . . . . . . . . . . 11 71 4.4. Mailbox Management . . . . . . . . . . . . . . . . . . . . 11 72 5. Event Parameters . . . . . . . . . . . . . . . . . . . . . . . 13 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 75 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 79 Appendix A. Future Extensions . . . . . . . . . . . . . . . . . . 19 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 81 Intellectual Property and Copyright Statements . . . . . . . . . . 21 83 1. Introduction 85 A message store is used to organize Internet Messages [RFC2822] into 86 one or more mailboxes, possibly hierarchical, annotate them in 87 various ways and provide access to these messages and associated 88 meta-data. Three different standards-based protocols have been 89 widely deployed to remotely access a message store. 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). Internet Message Access 93 Protocol (IMAP) [RFC3501] provides an extensible feature-rich model 94 for online, offline and disconnected access to a message store with 95 minimal constraints on any associated "fat-client" user interface. 96 Finally, mail access applications built on top of Hypertext Transfer 97 Protocol (HTTP) [RFC2616] which run in standards-based web browsers 98 provide a third standards-based access mechanism for online-only 99 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 importance 104 of message stores expands, the demand for a more complete store 105 notification system increases. Some of the driving forces behind 106 this demand include: 108 o Mobile devices with intermittent network connectivity that have 109 "new mail" or "message count" indicators 111 o Unified messaging systems which include both Internet and voice 112 mail require support for a message waiting indicator on phones 114 o Interaction with systems for event-based or utility-computing 115 billing 117 o Simplify the process of passing message store events to non- 118 Internet notification systems 120 o A calendar system may wish to subscribe to MessageNew 121 notifications in order to support iMIP [RFC2447]. 123 o Some jurisdictions have laws or regulations for information 124 protection and auditing which require interoperable protocols 125 between message stores built by messaging experts and compliance 126 auditing systems built by compliance experts. 128 Vendors who have deployed proprietary notification systems for their 129 Internet message stores have seen significant demand to provide 130 notifications for more and more events. As a first step towards 131 building a notification system, this document attempts to enumerate 132 the core events that real-world customers demand. 134 This document includes those events which can be generated by the use 135 of IMAP4Rev1 [RFC3501] and some existing extensions. As new IMAP 136 extensions are defined, or additional event types or parameters need 137 to be added, the set specified here can be extended by means of an 138 IANA registry with update requirements, as specified in Section 6. 140 1.1. Conventions Used in this Document 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [RFC2119] 145 When these words appear in lower-case or with initial-capital 146 letters, they are not RFC 2119 key words. 148 1.2. Change History 150 This section to be removed if/when this draft is published as an RFC. 152 1.2.1. Changes from -05 to -06 154 o Added discussion of message integrity to Security Considerations 155 (Section 7). 157 o Reviewed use of "may", "must" and "should" for conversion to 158 "MAY", "MUST" and "SHOULD". 160 o Reworded MessageNew and MessageExpire text. 162 o Additional clarifying text added to Future Extensions 163 (Appendix A). 165 o Added explicit prohibition on \Recent in FlagsSet to match the one 166 in FlagsClear (\Recent was also explicitly excluded from 167 flagNames). 169 o Clarified that Logout disconnection types are suggestions only. 171 o Added serverDomain and serverPort parameters, and clarified 172 clientPort. 174 o Clarified that a kilobyte is 1024 octets. 176 o Clarified that FlagSet and FlagClear include one or more flags or 177 keywords. 179 o Changed "cover about 95% of the known use cases" to "an 180 overwhelming majority of known use cases" in Event Types 181 (Section 4). 183 1.2.2. Changes from -04 to -05 185 o Reworded statement on optional versus mandatory and removed Anchor 186 11. 188 o Included mailbox admin events in list of exceptions in Appendix A, 189 and deleted Anchor 23. 191 1.2.3. Changes from -03 to -04 193 o Added QuotaChange event. 195 1.2.4. Changes from -02 to -03 197 o Fix typo in Login event 199 o Remove UIDVALIDITY from MailboxRename event. 201 o Made event names hierarchical: Changed AppendMessage to 202 MessageAppend, ExpireMessage to MessageExpire, ExpungeMessage to 203 MessageExpunge, NewMessage to MessageNew, OverQuota to 204 QuotaExceed, UnderQuota to QuotaWithin, ReadMessages to 205 MessageRead, TrashMessages to MessageTrash, SetFlags to FlagsSet, 206 and ClearFlags to FlagsClear; deleted Editor's Note asking if this 207 should be done. 209 o Made ACL information a future extension in MailboxCreate. 211 1.2.5. Changes from -01 to -02 213 o Add text indicating that mailboxes may contain Internet messages 214 and/or child mailboxes. 216 o Remove word "folder" from definition of "mailbox." 218 o Add editor's note regarding optionality in this document. 220 o Add editor's note regarding optional vs. mandatory events. 222 o Add editor's note regarding event names. 224 o Remove U.S.-centric wording regarding laws. 226 o Review uses of "will" and change as appropriate. 228 o Clarification of server address in login event. 230 o Add MailboxCreate, MailboxDelete, MailboxRename, and 231 MailboxSubscribe events. 233 o Add mailboxName and oldMailboxName parameter.s 235 o Move RFC2822 from normative to informative. 237 o Add IANA Considerations and reference to RFC 2434. 239 o Minor grammatical improvements. 241 o Incorporate edits from Alexey Melnikov. 243 o Add editor's note regarding deployment of mailbox admin events. 245 o Add Acknowledgments section. 247 o Fix formatting to add blank line between paragraphs in event and 248 parameter lists. 250 o Add reference to RFC 2119 and "Conventions" section. 252 o Update RFC 2222 to RFC 4422. 254 1.2.6. Changes from -00 to -01 256 o Add modseq event parameter. 258 o Add tags event parameter. 260 1.2.7. Changes from draft-newman-lemonade-msgevent-00.txt to 261 draft-ietf-lemonade-msgevent-00.txt 263 o Rename draft title 265 o Add Change History section. 267 o Update reference to URLAUTH. 269 o Add FlagsSet, FlagsClear events and flagNames parameter. Update 270 future events section to reflect this change. 272 o Removed unnecessary normative reference to NAMESPACE. 274 2. Terminology 276 The following terminology is used in this document: 278 mailbox 279 A container for Internet messages and/or child mailboxes. A 280 mailbox may or may not permit delivery of new messages via a mail 281 delivery agent. 283 mailbox identifier 284 A mailbox identifier provides sufficient information to identify a 285 specific mailbox on a specific server instance. An IMAP URL can 286 be a mailbox identifier. 288 message access protocols 289 Protocols which provide clients (e.g., a mail user agent or web 290 browser) with access to the message store including but not 291 limited to IMAP, POP and HTTP. 293 message context 294 As defined in [RFC3458]. 296 UIDVALIDITY 297 As defined in IMAP4rev1 [RFC3501]. UIDVALIDITY is critical to the 298 correct operation of a caching mail client. When it changes, the 299 client MUST flush its cache. It's particularly important to 300 include UIDVALIDITY with event notifications related to message 301 addition or removal in order to keep the message data correctly 302 synchronized. 304 3. Event Model 306 The events that are generated by a message store depend to some 307 degree on the model used to represent a message store. The model the 308 IETF has for a message store is implicit from IMAP4rev1 and 309 extensions, so that model is assumed by this document. 311 A message store event typically has an associated mailbox name and 312 usually has an associated user name (or authorization identity if 313 using the terminology from SASL [RFC4422]). Events referring to a 314 specific message can use an IMAP URL [RFC5092] to do so. Events 315 referring to a set of messages can use an IMAP URL to the mailbox 316 plus an IMAP UID set. 318 Each notification has a type and parameters. The type determines the 319 type of event, while the parameters supply information about the 320 context of the event that may be used to adjust subscription 321 preferences or may simply supply data associated with the event. The 322 types and parameter names in this document are restricted to US-ASCII 323 printable characters so these events can be easily mapped to an 324 arbitrary notification system. However, this document assumes 325 arbitrary parameter values (including large and multi-line values) 326 can be encoded with the notification system. Systems which lack that 327 feature could only implement a subset of these events. 329 This document does not indicate which event parameters are mandatory 330 or optional. That is done in documents which specify specific 331 message formats or bindings to a notification system. 333 For scalability reasons, some degree of filtering at event generation 334 is necessary. At the very least, the ability to turn on and off 335 groups of related events and to suppress inclusion of large 336 parameters (such as messageContent) is needed. A sophisticated 337 publish/subscribe notification system may be able to propagate 338 cumulative subscription information to the publisher. 340 Some of these events might be logically collapsed into a single event 341 type with a required parameter to distinguish between the cases 342 (e.g., QuotaExceed and QuotaWithin). However until such time that an 343 event subscription model is formulated, it's not practical to make 344 such decisions. We thus note only the fact that some of these events 345 may be viewed as a single event type. 347 4. Event Types 349 This section discusses the different types of events useful in a 350 message store event notification system. The intention is to 351 document the events sufficient to cover an overwhelming majority of 352 known use cases while leaving less common event types for the future. 353 This section mentions parameters which are important or specific to 354 the events described here. Event parameters likely to be included in 355 most or all notifications are discussed in the next section. 357 4.1. Message Addition and Deletion 359 This section includes events related to message addition and 360 deletion. 362 MessageAppend 363 A message was appended or concatenated to a mailbox by a message 364 access client. For the most part, this is identical to the 365 MessageNew event type, except that the SMTP envelope information 366 is not included as a parameter, but information about which 367 protocol triggered the event MAY be included. See the MessageNew 368 event for more information. 370 MessageExpire 371 One or more messages were expired from a mailbox due to server 372 expiration policy and are no longer accessible by the end-user. 374 The parameters include a mailbox identifier which MUST include 375 UIDVALIDITY, and a UID set which describes the messages. 377 Information about which server expiration policy was applied may 378 be included in the future. 380 MessageExpunge 381 One or more messages were expunged from a mailbox by an IMAP 382 CLOSE/EXPUNGE, POP3 DELE+QUIT, HTTP or equivalent client action 383 and are no longer accessible by the end-user. 385 The parameters include a mailbox identifier which MUST include 386 UIDVALIDITY, a UID set, and MAY also indicate which access 387 protocol triggered the event. 389 MessageNew 390 A new message was received into a mailbox via a message delivery 391 agent. 393 The parameters include a message identifier which for IMAP- 394 accessible message stores MUST include UIDVALIDITY and UID. The 395 parameters MAY also include SMTP envelope and other arbitrary 396 message and mailbox meta-data. In some cases, the entire new 397 message itself may be included. The set of parameters SHOULD be 398 adjustable to the client's preference with limits set by server 399 policy. An interesting policy, for example, would be to include 400 messages up to 2K in size with the notification, but for larger 401 messages to include a URLAUTH [RFC4467] reference. 403 QuotaExceed 404 An operation failed (typically MessageNew) because the user's 405 mailbox exceeded one of the quotas (e.g., disk quota, message 406 quota, quota by message context, etc). The parameters SHOULD 407 include at least the relevant user and quota, and optionally the 408 mailbox. Quota usage SHOULD be included if possible. Parameters 409 needed to extend this to support quota by context are not 410 presently described in this document, but could be added in the 411 future. 413 QuotaWithin 414 An operation occurred (typically MessageExpunges or 415 MessageExpires) which reduced the user's quota usage under their 416 limit. 418 QuotaChange 419 The user's quota was changed. 421 4.2. Message Flags 423 This section includes events related to changes in message flags. 425 MessageRead 426 One or more messages in the mailbox were marked as read or seen by 427 a user. Note that POP has no concept of read or seen messages, so 428 these events are only generated by IMAP or HTTP clients (or 429 equivalent). 431 The parameters include a mailbox identifier and a set of message 432 UIDs. 434 MessageTrash 435 One or more messages were marked for future deletion by the user 436 but are still accessible over protocol (the user's client may or 437 may not make these messages accessible through its user 438 interface). 440 The parameters include a mailbox identifier and a set of message 441 UIDs. 443 FlagsSet 444 One or more messages in the mailbox had one or more IMAP flags or 445 keyword sets. 447 The parameters include a list of IMAP flag or keyword names that 448 were set, a mailbox identifier and a set of message UIDs that were 449 impacted. The flagNames MUST not include \Recent. For 450 compatibility with simpler clients, it SHOULD be configurable 451 whether setting the \Seen or \Deleted flags results in this event 452 or the simpler MessageRead/MessageTrash events. By default, the 453 simpler message forms SHOULD be used for MessageRead and 454 MessageTrash. 456 FlagsClear 457 One or more messages in the mailbox had one or more IMAP flags or 458 keywords cleared. 460 The parameters include a list of IMAP flag or keyword names that 461 were cleared, a mailbox identifier and a set of message UIDs that 462 were impacted. The flagNames parameter MUST not include \Recent. 464 4.3. Access Accounting 466 This section lists events related to message store access accounting. 468 Login 469 A user has logged in to the system via IMAP, HTTP, POP or some 470 other mechanism. 472 The parameters include the domain name and port used to access the 473 server and the user's authorization identity. Additional possible 474 parameters include the client's IP address and port, the 475 authentication identity (if different from the authorization 476 identity), the service name, the authentication mechanism, 477 information about any negotiated security layers, a timestamp and 478 other information. 480 Logout 481 A user has logged out or otherwise been disconnected from the 482 message store via IMAP, HTTP, POP or some other mechanism. 484 The parameters include the server domain name and the user's 485 authorization identity. Additional parameters MAY include any of 486 the information from the "Login" event as well as information 487 about the type of disconnect (suggested values include graceful, 488 abort, timeout, and security layer error), the duration of the 489 connection or session and other information. 491 4.4. Mailbox Management 493 This section lists events related to the management of mailboxes. 495 MailboxCreate 496 A mailbox has been created, or an access control changed on an 497 existing mailbox so that it is now accessible by the user. If the 498 mailbox creation caused the creation of new mailboxes earlier in 499 the hierarchy, separate MailboxCreate events are not generated for 500 those as their creation is implied. 502 The parameters include the created mailbox identifier, its 503 UIDVALIDITY for IMAP-accessible message stores, and MAY also 504 indicate which access protocol triggered the event. Access/ 505 permissions information (such as ACL [RFC4314] settings) require a 506 standardized format to be included, and so are left for future 507 extension. 509 MailboxDelete 510 A mailbox has been deleted, or an access control changed on an 511 existing mailbox so that it is no longer accessible by the user. 512 Note that if the mailbox has child mailboxes, only the specified 513 mailbox has been deleted, not the children. The mailbox becomes 514 \NOSELECT and the hierarchy remains unchanged, as per the 515 description of the DELETE command in RFC 3501IMAP4rev1 [RFC3501]. 517 The parameters include the deleted mailbox identifier, and MAY 518 also indicate which access protocol triggered the event. 520 MailboxRename 521 A mailbox has been renamed. Note that, per the description of the 522 RENAME command in RFC 3501IMAP4rev1 [RFC3501], special semantics 523 regarding the mailbox hierarchy apply when INBOX is renamed (child 524 mailboxes are usually included in the rename, but are excluded 525 when INBOX is renamed). When a mailbox other than INBOX is 526 renamed and its child mailboxes are also renamed as a result, 527 separate MailboxRename events are not generated for the child 528 mailboxes, as their renaming is implied. If the rename caused the 529 creation of new mailboxes earlier in the hierarchy, separate 530 MailboxCreate events are not generated for those as their creation 531 is implied. When INBOX is renamed, a new INBOX is created. A 532 MailboxCreate event is not generated for the new INBOX, since it 533 is implied. 535 The parameters include the old mailbox identifier, the new mailbox 536 identifier, and MAY also indicate which access protocol triggered 537 the event. 539 MailboxSubscribe 540 A mailbox has been added to the subscription list. 542 The parameters include the user whose subscription list has been 543 affected and the mailbox identifier, and MAY also indicate which 544 access protocol triggered the event. 546 MailboxUnSubscribe 547 A mailbox has been removed from the subscription list. 549 The parameters include the user whose subscription list has been 550 affected and the mailbox identifier, and MAY also indicate which 551 access protocol triggered the event. 553 5. Event Parameters 555 This section lists parameters included with these events. 557 admin 559 Included with all events generated by message access protocols. 561 The authentication identity associated with this event, as 562 distinct from the authorization identity (see "user"). This is 563 not included when it is the same as the value of the user 564 parameter. 566 bodyStructure 568 May be included with MessageAppend and MessageNew. 570 The IMAP BODYSTRUCTURE of the message. 572 clientIP 574 Included with all events generated by message access protocols. 576 The IP address of the message store access client which performed 577 the action which triggered the notification. 579 clientPort 581 Included with all events generated by message access protocols. 583 The port number of the message store access client which performed 584 an action which triggered the notification (the port from which 585 the connection occurred). 587 diskQuota 589 Included with QuotaExceed, QuotaWithin, and QuotaChange 590 notifications relating to a user or mailbox disk quota. May be 591 included with other notifications. 593 Disk quota limit in kilobytes (1024 octets). 595 diskUsed 597 Included with QuotaExceed and QuotaWithin notifications relating 598 to a user or mailbox disk quota. May be included with other 599 notifications. 601 Disk space used in kilobytes (1024 octets). Only disk space which 602 counts against the quota is included. 604 envelope 606 May be included with the MessageNew notification. 608 The message transfer envelope associated with final delivery of 609 the message for the MessageNew notification. This includes the 610 MAIL FROM and relevant RCPT TO line(s) used for final delivery 611 with CRLF delimiters and any ESMTP parameters. 613 flagNames 615 Included with FlagsSet and FlagsClear events. May be included 616 with MessageAppend and MessageNew to indicate flags which were set 617 initially by the APPEND command or delivery agent respectively. 619 A space-separated list of IMAP flag or keyword names that were set 620 or cleared. Flag names begin with backslash while keyword names 621 do not. The \Recent flag is explicitly not permitted in the list. 623 mailboxID 625 Included in events which affect mailboxes. URI describing the 626 mailbox. In the case of MailboxRename, this refers to the new 627 name. 629 maxMessages 631 Included with QuotaExceed and QuotaWithin notifications relating 632 to a user or mailbox message count quota. May be included with 633 other notifications. 635 Quota limit on the number of messages in the mailbox, for events 636 referring to a mailbox. 638 messageContent 640 May be included with MessageAppend and MessageNew. 642 The entire message itself. Size based suppression of this SHOULD 643 be available. 645 messageSize 647 May be included with MessageAppend and MessageNew. 649 Size of the RFC 2822 message itself in octets. This value matches 650 the length of the IMAP literal returned in response to an IMAP 651 FETCH of BODY[] for the referenced message. 653 messages 655 Included with QuotaExceed and QuotaWithin notifications relating 656 to a user or mailbox message count quota. May be included with 657 other notifications. 659 Number of messages in the mailbox. This is typically included 660 with message addition and deletion events. 662 modseq 664 May be included with any notification referring to one message. 666 This is the 64-bit integer MODSEQ as defined in [RFC4551]. No 667 assumptions about MODSEQ can be made if this is omitted. 669 oldMailboxID 671 URI describing the old name of a renamed or moved mailbox. 673 pid 675 May be included with any notification. 677 The process ID of the process which generated the notification. 679 process 681 May be included with any notification. 683 The name of the process which generated the notification. 685 serverDomain Included in Login, and optionally in Logout or other 686 events. The domain name or IP address used to access the server 687 or mailbox. 689 serverPort Included in Login, and optionally in Logout or other 690 events. The port number used to access the server. This is often 691 a well-known port. 693 serverFQDN 695 May be included with any notification. 697 The fully qualified domain name of the server which generated the 698 event. Note that this may be different from the server name used 699 to access the mailbox included in the mailbox identifier. 701 service 703 May be included with any notification. 705 The name of the service which triggered the event. Suggested 706 values include "imap", "pop", "http", and "admincli" (for an 707 administrative client). 709 tags 711 May be included with any notification. 713 This is a comma-separated list of UTF-8 tags. One or more tags 714 can be set at the time a notification criteria or notification 715 subscription is created. Subscribers can use tags for additional 716 client-side filtering or dispatch of events. 718 timestamp 720 May be included with any notification. 722 When the notification was generated in [RFC3339] syntax. 724 uidnext 726 May be included with any notification referring to a mailbox. 728 The UID that is projected to be assigned next in the mailbox. 729 This is typically included with message addition and deletion 730 events. This is equivalent to the UIDNEXT status item in the IMAP 731 STATUS command. 733 uidset 735 Included with MessageExpires, MessageExpunges, MessageRead, 736 MessageTrash, FlagsSet and FlagsClear. 738 This includes the set of IMAP UIDs referenced. 740 uri 742 Included with all notifications and refers to the IMAP server, a 743 mailbox or a message. 745 Typically an IMAP URL. This can include the name of the server 746 used to access the mailbox/message, the mailbox name, the 747 UIDVALIDITY of the mailbox, and the UID of a specific message. 749 user 751 Included with all events generated by message access protocols. 753 This is the SASL authorization identifier used when the user 754 connected to the access protocol which triggered the event. For 755 events associated with a mailbox, this may be different from the 756 owner of the mailbox specified in the IMAP URL. 758 6. IANA Considerations 760 The IANA is requested to create a new registry for "Internet Message 761 Store Events" containing two sub-registries: event names and event 762 parameters. For both event names and event parameters, entries which 763 do not start with "vnd." are added by the IETF and intended for 764 interoperable use. Entries which start with "vnd." are intended for 765 private use by one or more parties and are allocated to avoid 766 collisions. 768 The initial values are contained in this document. 770 Using IANA Considerations [RFC2434] terminology, entries which do not 771 start with "vnd." are allocated by IETF Consensus, while those 772 starting with "vnd." are allocated First Come First Served. 774 7. Security Considerations 776 Notifications can produce a large amount of traffic and expose 777 sensitive information. When notification mechanisms are used to 778 maintain state between a different entities, the ability to corrupt 779 or manipulate notification messages could enable an attacker to 780 modulate the state of these entities. For example, if an attacker 781 were able to modify notifications sent from a message store to an 782 auditing server, he could modify the "user" and "messageContent" 783 parameters in MessageNew notifications to create false audit log 784 entries. 786 A competent transfer protocol for notifications must consider 787 authentication, authorization, privacy, and message integrity, as 788 well as denial-of-service issues. While the IETF has adequate tools 789 and experience to address these issues for mechanisms which involve 790 only one TCP connection, notification or publish/subscribe protocols 791 which are more sophisticated than a single end-to-end TCP connection 792 will need to pay extra attention to these issues and carefully 793 balance requirements to successfully deploy a system with security 794 and privacy considerations. 796 8. Acknowledgments 798 Alexey Melnikov, Arnt Gulbrandsen, and Zoltan Ordogh have reviewed 799 and offered improvements to this draft. Richard Barnes did a nice 800 review during Last Call. 802 9. References 804 9.1. Normative References 806 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 807 Requirement Levels", BCP 14, RFC 2119, March 1997. 809 [RFC5092] Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092, 810 November 2007. 812 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 813 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 814 October 1998. 816 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 817 4rev1", RFC 3501, March 2003. 819 9.2. Informative References 821 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 822 RFC 4314, December 2005. 824 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 825 STD 53, RFC 1939, May 1996. 827 [RFC2177] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997. 829 [RFC2447] Dawson, F., Mansour, S., and S. Silverberg, "iCalendar 830 Message-Based Interoperability Protocol (iMIP)", RFC 2447, 831 November 1998. 833 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 834 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 835 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 837 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 838 April 2001. 840 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 841 Internet: Timestamps", RFC 3339, July 2002. 843 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 844 Context for Internet Mail", RFC 3458, January 2003. 846 [RFC4146] Gellens, R., "Simple New Mail Notification", RFC 4146, 847 August 2005. 849 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 850 Security Layer (SASL)", RFC 4422, June 2006. 852 [RFC4467] Crispin, M., "Internet Message Access Protocol (IMAP) - 853 URLAUTH Extension", RFC 4467, May 2006. 855 [RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional 856 STORE Operation or Quick Flag Changes Resynchronization", 857 RFC 4551, June 2006. 859 Appendix A. Future Extensions 861 This document specifies core functionality based on events which are 862 believed to be well understood, have known use cases and are 863 implemented by at least one deployed real-world Internet message 864 store. (A few events are exceptions to the last test only: FlagsSet, 865 FlagsClear, MailboxCreate, MailboxDelete, MailboxRename, 866 MailboxSubscribe, and MailboxUnSubscribe.) 868 Some events have been suggested, but are postponed to future 869 extensions because they do not meet this criteria. These events 870 include messages which have been moved to archive storage and may 871 require extra time to access, quota by message context, 872 authentication failure, user mail account disabled, annotations, and 873 mailbox ACL or metadata change. The descriptions of several events 874 note additional parameters which are likely candidates for future 875 inclusion. See Section 6 for how the list of events and parameters 876 can be extended. 878 In order to narrow the scope of this document to something that can 879 be completed, only events generated from the message store (by a 880 message access module, administrative module or message delivery 881 agent) are considered. A complete mail system is normally linked 882 with an identity system which would also publish events of interest 883 to a message store event subscriber. Events of interest include 884 account created/deleted/disabled and password changed/expired. 886 Authors' Addresses 888 Randall Gellens 889 QUALCOMM Incorporated 890 5775 Morehouse Drive 891 San Diego, CA 92651 892 US 894 Email: rg+ietf@qualcomm.com 896 Chris Newman 897 Sun Microsystems 898 3401 Centrelake Dr., Suite 410 899 Ontario, CA 91761 900 US 902 Email: chris.newman@sun.com 904 Full Copyright Statement 906 Copyright (C) The IETF Trust (2008). 908 This document is subject to the rights, licenses and restrictions 909 contained in BCP 78, and except as set forth therein, the authors 910 retain all their rights. 912 This document and the information contained herein are provided on an 913 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 914 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 915 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 916 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 917 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 918 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 920 Intellectual Property 922 The IETF takes no position regarding the validity or scope of any 923 Intellectual Property Rights or other rights that might be claimed to 924 pertain to the implementation or use of the technology described in 925 this document or the extent to which any license under such rights 926 might or might not be available; nor does it represent that it has 927 made any independent effort to identify any such rights. Information 928 on the procedures with respect to rights in RFC documents can be 929 found in BCP 78 and BCP 79. 931 Copies of IPR disclosures made to the IETF Secretariat and any 932 assurances of licenses to be made available, or the result of an 933 attempt made to obtain a general license or permission for the use of 934 such proprietary rights by implementers or users of this 935 specification can be obtained from the IETF on-line IPR repository at 936 http://www.ietf.org/ipr. 938 The IETF invites any interested party to bring to its attention any 939 copyrights, patents or patent applications, or other proprietary 940 rights that may cover technology that may be required to implement 941 this standard. Please address the information to the IETF at 942 ietf-ipr@ietf.org. 944 Acknowledgment 946 Funding for the RFC Editor function is provided by the IETF 947 Administrative Support Activity (IASA).