idnits 2.17.1 draft-ietf-lemonade-msgevent-04.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 852. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 863. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 870. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 876. 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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 8, 2007) is 6130 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 2192 (Obsoleted by RFC 5092) ** 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: 4 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lemonade C. Newman 3 Internet-Draft Sun Microsystems 4 Expires: January 9, 2008 R. Gellens 5 QUALCOMM Incorporated 6 July 8, 2007 8 Internet Message Store Events 9 draft-ietf-lemonade-msgevent-04.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 9, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 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 -03 to -04 . . . . . . . . . . . . . . . 4 58 1.2.2. Changes from -02 to -03 . . . . . . . . . . . . . . . 4 59 1.2.3. Changes from -01 to -02 . . . . . . . . . . . . . . . 4 60 1.2.4. Changes from -00 to -01 . . . . . . . . . . . . . . . 5 61 1.2.5. Changes from draft-newman-lemonade-msgevent-00.txt 62 to draft-ietf-lemonade-msgevent-00.txt . . . . . . . . 5 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3. Event Model . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4. Event Types . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.1. Message Addition and Deletion . . . . . . . . . . . . . . 8 67 4.2. Message Flags . . . . . . . . . . . . . . . . . . . . . . 9 68 4.3. Access Accounting . . . . . . . . . . . . . . . . . . . . 10 69 4.4. Mailbox Management . . . . . . . . . . . . . . . . . . . . 10 70 5. Event Parameters . . . . . . . . . . . . . . . . . . . . . . . 12 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 73 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 76 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 77 Appendix A. Future Extensions . . . . . . . . . . . . . . . . . . 18 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 79 Intellectual Property and Copyright Statements . . . . . . . . . . 20 81 1. Introduction 83 A message store is used to organize Internet Messages [RFC2822] into 84 one or more mailboxes, possibly hierarchical, annotate them in 85 various ways and provide access to these messages and associated 86 meta-data. Three different standards-based protocols have been 87 widely deployed to remotely access a message store. Post Office 88 Protocol (POP) [RFC1939] provides simple download-and-delete access 89 to a single mail drop (which is a subset of the functionality 90 typically associated with a message store). Internet Message Access 91 Protocol (IMAP) [RFC3501] provides an extensible feature-rich model 92 for online, offline and disconnected access to a message store with 93 minimal constraints on any associated "fat-client" user interface. 94 Finally, mail access applications built on top of Hypertext Transfer 95 Protocol (HTTP) [RFC2616] which run in standards-based web browsers 96 provide a third standards-based access mechanism for online-only 97 access. 99 While simple and/or ad-hoc mechanisms for notifications have sufficed 100 to some degree in the past (e.g., Simple New Mail Notification 101 [RFC4146], IMAP4 IDLE command [RFC2177]), as the scope and importance 102 of message stores expands, the demand for a more complete store 103 notification system increases. Some of the driving forces behind 104 this demand include: 106 o Mobile devices with intermittent network connectivity that have 107 "new mail" or "message count" indicators 109 o Unified messaging systems which include both Internet and voice 110 mail require support for a message waiting indicator on phones 112 o Interaction with systems for event-based or utility-computing 113 billing 115 o Simplify the process of passing message store events to non- 116 Internet notification systems 118 o A calendar system may wish to subscribe to MessageNew 119 notifications in order to support iMIP [RFC2447]. 121 o Some jurisdictions have laws or regulations for information 122 protection and auditing which require interoperable protocols 123 between message stores built by messaging experts and compliance 124 auditing systems built by compliance experts. 126 Vendors who have deployed proprietary notification systems for their 127 Internet message stores have seen significant demand to provide 128 notifications for more and more events. As a first step towards 129 building a notification system, this document attempts to enumerate 130 the core events that real-world customers demand. 132 This document includes those events which can be generated by the use 133 of IMAP4Rev1 [RFC3501] and some existing extensions. As new IMAP 134 extensions are defined, or additional event types or parameters need 135 to be added, the set specified here can be extended by means of an 136 IANA registry with update requirements, as specified in Section 6. 138 1.1. Conventions Used in this Document 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 1.2. Change History 146 This section to be removed if/when this draft is published as an RFC. 148 1.2.1. Changes from -03 to -04 150 o Added QuotaChange event 152 1.2.2. Changes from -02 to -03 154 o Fix typo in Login event 156 o Remove UIDVALIDITY from MailboxRename event 158 o Made event names hierarchical: Changed AppendMessage to 159 MessageAppend, ExpireMessage to MessageExpire, ExpungeMessage to 160 MessageExpunge, NewMessage to MessageNew, OverQuota to 161 QuotaExceed, UnderQuota to QuotaWithin, ReadMessages to 162 MessageRead, TrashMessages to MessageTrash, SetFlags to FlagsSet, 163 and ClearFlags to FlagsClear; deleted Editor's Note asking if this 164 should be done 166 o Made ACL information a future extension in MailboxCreate 168 1.2.3. Changes from -01 to -02 170 o Add text indicating that mailboxes may contain Internet messages 171 and/or child mailboxes 173 o Remove word "folder" from definition of "mailbox" 175 o Add editor's note regarding optionality in this document 176 o Add editor's note regarding optional vs. mandatory events 178 o Add editor's note regarding event names 180 o Remove U.S.-centric wording regarding laws 182 o Review uses of "will" and change as appropriate 184 o Clarification of server address in login event 186 o Add MailboxCreate, MailboxDelete, MailboxRename, and 187 MailboxSubscribe events 189 o Add mailboxName and oldMailboxName parameters 191 o Move RFC2822 from normative to informative 193 o Add IANA Considerations and reference to RFC 2434 195 o Minor grammatical improvements 197 o Incorporate edits from Alexey Melnikov 199 o Add editor's note regarding deployment of mailbox admin events 201 o Add Acknowledgments section 203 o Fix formatting to add blank line between paragraphs in event and 204 parameter lists 206 o Add reference to RFC 2119 and "Conventions" section 208 o Update RFC 2222 to RFC 4422 210 1.2.4. Changes from -00 to -01 212 o Add modseq event parameter. 214 o Add tags event parameter. 216 1.2.5. Changes from draft-newman-lemonade-msgevent-00.txt to 217 draft-ietf-lemonade-msgevent-00.txt 219 o Rename draft title 221 o Add Change History section 222 o Update reference to URLAUTH 224 o Add FlagsSet, FlagsClear events and flagNames parameter. Update 225 future events section to reflect this change. 227 o Removed unnecessary normative reference to NAMESPACE. 229 2. Terminology 231 The following terminology is used in this document: 233 mailbox 234 A container for Internet messages and/or child mailboxes. A 235 mailbox may or may not permit delivery of new messages via a mail 236 delivery agent. 238 mailbox identifier 239 A mailbox identifier provides sufficient information to identify a 240 specific mailbox on a specific server instance. An IMAP URL can 241 be a mailbox identifier. 243 message access protocols 244 Protocols which provide clients (e.g., a mail user agent or web 245 browser) with access to the message store including but not 246 limited to IMAP, POP and HTTP. 248 message context 249 As defined in [RFC3458]. 251 UIDVALIDITY 252 As defined in IMAP4rev1 [RFC3501]. UIDVALIDITY is critical to the 253 correct operation of a caching mail client. When it changes, the 254 client must flush its cache. It's particularly important to 255 include UIDVALIDITY with event notifications related to message 256 addition or removal in order to keep the message data correctly 257 synchronized. 259 3. Event Model 261 The events that are generated by a message store depend to some 262 degree on the model used to represent a message store. The model the 263 IETF has for a message store is implicit from IMAP4rev1 and 264 extensions, so that model is assumed by this document. 266 A message store event typically has an associated mailbox name and 267 usually has an associated user name (or authorization identity if 268 using the terminology from SASL [RFC4422]). Events referring to a 269 specific message can use an IMAP URL [RFC2192] to do so. Events 270 referring to a set of messages can use an IMAP URL to the mailbox 271 plus an IMAP UID set. 273 Each notification has a type and parameters. The type determines the 274 type of event, while the parameters supply information about the 275 context of the event that may be used to adjust subscription 276 preferences or may simply supply data associated with the event. The 277 types and parameter names in this document are restricted to US-ASCII 278 printable characters so these events can be easily mapped to an 279 arbitrary notification system. However, this document assumes 280 arbitrary parameter values (including large and multi-line values) 281 can be encoded with the notification system. Systems which lack that 282 feature could only implement a subset of these events. 284 This document does not specify which event parameters are mandatory 285 or optional. That is done when actual message formats or bindings to 286 a notification system are completed. 288 [[anchor11: Should optional vs. mandatory be in this document?]] 290 For scalability reasons, some degree of filtering at event generation 291 is necessary. At the very list, the ability to turn on and off 292 groups of related events and to suppress inclusion of large 293 parameters (such as messageContent) is needed. A sophisticated 294 publish/subscribe notification system may be able to propagate 295 cumulative subscription information to the publisher. 297 some of these events might be logically collapsed into a single event 298 type with a required parameter to distinguish between the cases 299 (e.g., QuotaExceed and QuotaWithin). However until such time that an 300 event subscription model is formulated, it's not practical to make 301 such decisions. We thus note only the fact that some of these events 302 may be viewed as a single event type. 304 4. Event Types 306 This section discusses the different types of events useful in a 307 message store event notification system. The intention is to 308 document the events sufficient to cover about 95% of the known use 309 cases while leaving less common event types for the future. This 310 section mentions parameters which are important or specific to the 311 events described here. Event parameters likely to be included in 312 most or all notifications are discussed in the next section. 314 4.1. Message Addition and Deletion 316 This section includes events related to message addition and 317 deletion. 319 MessageAppend 320 A message was appended or concatenated to a mailbox by a message 321 access client. For the most part, this is identical to the 322 MessageNew event type, except that the SMTP envelope information 323 is not included as a parameter, but information about which 324 protocol triggered the event may be included. See the MessageNew 325 event for more information. 327 MessageExpire 328 One or more messages were expired from a mailbox due to server 329 expiration policy and are no longer accessible by the end-user. 331 The parameters include a mailbox identifier which must include 332 UIDVALIDITY. A UID set references the messages. Information 333 about which server expiration policy was applied may be included 334 as parameters in a future version. 336 MessageExpunge 337 One or more messages were expunged from a mailbox by an IMAP 338 CLOSE/EXPUNGE, POP3 DELE+QUIT, HTTP or equivalent client action 339 and are no longer accessible by the end-user. 341 The parameters include a mailbox identifier which must include 342 UIDVALIDITY, a UID set, and may also indicate which access 343 protocol triggered the event. 345 MessageNew 346 A new message was received into a mailbox via a message delivery 347 agent. 349 The parameters include a message identifier which must include 350 UIDVALIDITY and UID for IMAP-accessible message stores. The 351 parameters may also include the entire new message itself, 352 possibly an SMTP envelope and other arbitrary message and mailbox 353 meta-data. The set of parameters included should be adjustable to 354 the client's preference with limits set by server policy. An 355 interesting policy, for example, would be to include messages up 356 to 2K in size with the notification, but for larger messages to 357 include a URLAUTH [RFC4467] reference. 359 QuotaExceed 360 An operation failed (typically MessageNew) because the user's 361 mailbox exceeded one of the quotas (e.g., disk quota, message 362 quota, quota by message context, etc). The parameters should 363 include at least the relevant user and quota, and optionally the 364 mailbox. Quota usage should be included if possible. Parameters 365 needed to extend this to support quota by context are not 366 presently described in this document, but could be added in the 367 future. 369 QuotaWithin 370 An operation occurred (typically MessageExpunges or 371 MessageExpires) which reduced the user's quota usage under their 372 limit. 374 QuotaChange 375 The user's quota was changed. 377 4.2. Message Flags 379 This section includes events related to changes in message flags. 381 MessageRead 382 One or more messages in the mailbox were marked as read or seen by 383 a user. Note that POP has no concept of read or seen messages, so 384 these events are only generated by IMAP or HTTP clients (or 385 equivalent). 387 The parameters include a mailbox identifier and a set of message 388 UIDs. 390 MessageTrash 391 One or more messages were marked for future deletion by the user 392 but are still accessible over protocol (the user's client may or 393 may not make these messages accessible through its user 394 interface). 396 The parameters include a mailbox identifier and a set of message 397 UIDs. 399 FlagsSet 400 One or more messages in the mailbox had an IMAP flag or keyword 401 set. 403 The parameters include a list of IMAP flag or keyword names that 404 were set, a mailbox identifier and a set of message UIDs that were 405 impacted. For compatibility with simpler clients, it should be 406 configurable whether setting the \Seen or \Deleted flags results 407 in this event or the simpler MessageRead/MessageTrash events. By 408 default, the simpler message forms should be used for MessageRead 409 and MessageTrash. 411 FlagsClear 412 One or more messages in the mailbox had an IMAP flag or keyword 413 cleared. 415 The parameters include a list of IMAP flag or keyword names that 416 were cleared, a mailbox identifier and a set of message UIDs that 417 were impacted. The flagName not include \Recent. 419 4.3. Access Accounting 421 This section lists events related to message store access accounting. 423 Login 424 A user has logged in to the system via IMAP, HTTP, POP or some 425 other mechanism. 427 The parameters include the domain name and port used to access the 428 server and the user's authorization identity. Additional possible 429 parameters include the client's IP address and port, the 430 authentication identity (if different from the authorization 431 identity), the service name, the authentication mechanism, 432 information about any negotiated security layers, a timestamp and 433 other information. 435 Logout 436 A user has logged out or otherwise been disconnected from the 437 message store via IMAP, HTTP, POP or some other mechanism. 439 The parameters include the server domain name and the user's 440 authorization identity. Additional parameters may include any of 441 the information from the "Login" event as well as information 442 about the type of disconnect (graceful, abort, timeout, security 443 layer error), the duration of the connection or session and other 444 information. 446 4.4. Mailbox Management 448 This section lists events related to the management of mailboxes. 450 MailboxCreate 451 A mailbox has been created, or an access control changed on an 452 existing mailbox so that it is now accessible by the user. If the 453 mailbox creation caused the creation of new mailboxes earlier in 454 the hierarchy, separate MailboxCreate events are not generated for 455 those as their creation is implied. 457 The parameters include the created mailbox identifier, its 458 UIDVALIDITY for IMAP-accessible message stores, and may also 459 indicate which access protocol triggered the event. Access/ 460 permissions information (such as ACL [RFC4314] settings) require a 461 standardized format to be included, and so are left for future 462 extension. 464 MailboxDelete 465 A mailbox has been deleted, or an access control changed on an 466 existing mailbox so that it is no longer accessible by the user. 467 Note that if the mailbox has child mailboxes, only the specified 468 mailbox has been deleted, not the children. The mailbox becomes 469 \NOSELECT and the hierarchy remains unchanged, as per the 470 description of the DELETE command in RFC 3501IMAP4rev1 [RFC3501]. 472 The parameters include the deleted mailbox identifier, and may 473 also indicate which access protocol triggered the event. 475 MailboxRename 476 A mailbox has been renamed. Note that, per the description of the 477 RENAME command in RFC 3501IMAP4rev1 [RFC3501], special semantics 478 regarding the mailbox hierarchy apply when INBOX is renamed (child 479 mailboxes are usually included in the rename, but are excluded 480 when INBOX is renamed). When a mailbox other than INBOX is 481 renamed and its child mailboxes are also renamed as a result, 482 separate MailboxRename events are not generated for the child 483 mailboxes, as their renaming is implied. If the rename caused the 484 creation of new mailboxes earlier in the hierarchy, separate 485 MailboxCreate events are not generated for those as their creation 486 is implied. When INBOX is renamed, a new INBOX is created. A 487 MailboxCreate event is not generated for the new INBOX, since it 488 is implied. 490 The parameters include the old mailbox identifier, the new mailbox 491 identifier, and may also indicate which access protocol triggered 492 the event. 494 MailboxSubscribe 495 A mailbox has been added to the subscription list. 497 The parameters include the user whose subscription list has been 498 affected and the mailbox identifier, and may also indicate which 499 access protocol triggered the event. 501 MailboxUnSubscribe 502 A mailbox has been removed from the subscription list. 504 The parameters include the user whose subscription list has been 505 affected and the mailbox identifier, and may also indicate which 506 access protocol triggered the event. 508 5. Event Parameters 510 This section lists parameters that may be useful to include with 511 these events. 513 admin 515 Included with all events generated by message access protocols. 517 The authentication identity associated with this event, as 518 distinct from the authorization identity (see "user"). This is 519 not included when it is the same as the value of the user 520 parameter. 522 bodyStructure 524 May be included with MessageAppend and MessageNew. 526 The IMAP BODYSTRUCTURE of the message. 528 clientIP 530 Included with all events generated by message access protocols. 532 The IP address of the message store access client which performed 533 an action which triggered the notification. 535 clientPort 537 Included with all events generated by message access protocols. 539 The port number of the message store access client which performed 540 an action which triggered the notification. 542 diskQuota 544 Included with QuotaExceed, QuotaWithin, and QuotaChange 545 notifications relating to a user or mailbox disk quota. May be 546 included with other notifications. 548 Disk quota limit in kilobytes. 550 diskUsed 552 Included with QuotaExceed and QuotaWithin notifications relating 553 to a user or mailbox disk quota. May be included with other 554 notifications. 556 Disk space used in kilobytes. Only disk space which counts 557 against the quota is included. 559 envelope 561 May be included with the MessageNew notification. 563 The message transfer envelope associated with final delivery of 564 the message for the MessageNew notification. This includes the 565 MAIL FROM and relevant RCPT TO line(s) used for final delivery 566 with CRLF delimiters and any ESMTP parameters. 568 flagNames 570 Included with FlagsSet and FlagsClear events. May be included 571 with MessageAppend and MessageNew to indicate flags which were set 572 initially by the APPEND command or delivery agent respectively. 574 A space-separated list of IMAP flag or keyword names that were set 575 or cleared. Flag names begin with backslash while keyword names 576 do not. The \Recent flag is explicitly not permitted in the list. 578 mailboxID 580 Included in events which affect mailboxes. URI describing the 581 mailbox. In the case of MailboxRename, this refers to the new 582 name. 584 maxMessages 586 Included with QuotaExceed and QuotaWithin notifications relating 587 to a user or mailbox message count quota. May be included with 588 other notifications. 590 Quota limit on the number of messages in the mailbox, for events 591 referring to a mailbox. 593 messageContent 595 May be included with MessageAppend and MessageNew. 597 The entire message itself. Size based suppression of this should 598 be available. 600 messageSize 602 May be included with MessageAppend and MessageNew. 604 Size of the RFC 2822 message itself in octets. This value matches 605 the length of the IMAP literal returned in response to an IMAP 606 FETCH of BODY[] for the referenced message. 608 messages 610 Included with QuotaExceed and QuotaWithin notifications relating 611 to a user or mailbox message count quota. May be included with 612 other notifications. 614 Number of messages in the mailbox. This is typically included 615 with message addition and deletion events. 617 modseq 619 May be included with any notification referring to one message. 621 This is the 64-bit integer MODSEQ as defined in [RFC4551]. No 622 assumptions about MODSEQ can be made if this is omitted. 624 oldMailboxID 626 URI describing the old name of a renamed or moved mailbox. 628 pid 630 May be included with any notification. 632 The process id of the process which generated the notification. 634 process 636 May be included with any notification. 638 The name of the process which generated the notification. 640 serverFQDN 642 May be included with any notification. 644 The fully-qualified-domain-name of the server which generated the 645 event. Note that this may be different from the server name used 646 to access the mailbox included in the mailbox identifier. 648 service 650 May be included with any notification. 652 The name of the service which triggered the event. Suggested 653 values include "imap", "pop", "http", "admincli". 655 tags 657 May be included with any notification. 659 This is a comma-separated list of UTF-8 tags. One or more tags 660 can be set at the time a notification criteria or notification 661 subscription is created. Subscribers can use tags for additional 662 client-side filtering or dispatch of events. 664 timestamp 666 May be included with any notification. 668 When the notification was generated in [RFC3339] syntax. 670 uidnext 672 May be included with any notification referring to a mailbox. 674 The UID that is projected to be assigned next in the mailbox. 675 This is typically included with message addition and deletion 676 events. This is equivalent to the UIDNEXT status item in the IMAP 677 STATUS command. 679 uidset 681 Included with MessageExpires, MessageExpunges, MessageRead, 682 MessageTrash, FlagsSet and FlagsClear. 684 This includes the set of IMAP UIDs referenced. 686 uri 688 Included with all notifications and refers to the IMAP server, a 689 mailbox or a message. 691 Typically an IMAP URL. This can include the name of the server 692 used to access the mailbox/message, the mailbox name, the 693 UIDVALIDITY of the mailbox, and the UID of a specific message. 695 user 697 Included with all events generated by message access protocols. 699 This is the SASL authorization identifier used when the user 700 connected to the access protocol which triggered the event. For 701 events associated with a mailbox, this may be different from the 702 owner of the mailbox specified in the IMAP URL. 704 6. IANA Considerations 706 The IANA is requested to create a new registry for "Internet Message 707 Store Events" containing two sub-registries: event names and event 708 parameters. For both event names and event parameters, entries which 709 do not start with "vnd." are added by the IETF and intended for 710 interoperable use. Entries which start with "vnd." are intended for 711 private use by one or more parties and are allocated to avoid 712 collisions. 714 The initial values are contained in this document. 716 Using IANA Considerations [RFC2434] terminology, entries which do not 717 start with "vnd." are allocated by IETF Consensus, while those 718 starting with "vnd." are allocated First Come First Served. 720 7. Security Considerations 722 Notifications can produce a large amount of traffic and expose 723 sensitive information. A competent transfer protocol for 724 notifications must address authentication, authorization and privacy, 725 as well as denial-of-service issues. While the IETF has adequate 726 tools and experience to address these issues for mechanisms which 727 involve only one TCP connection, notification or publish/subscribe 728 protocols which are more sophisticated than a single end-to-end TCP 729 connection will need to pay extra attention to these issues and 730 carefully balance requirements to successfully deploy a system with 731 security and privacy considerations. 733 8. Acknowledgments 735 Alexey Melnikov, Arnt Gulbrandsen, and Zoltan Ordogh have reviewed 736 and offered improvements to this draft. 738 9. References 740 9.1. Normative References 742 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 743 Requirement Levels", BCP 14, RFC 2119, March 1997. 745 [RFC2192] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997. 747 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 748 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 749 October 1998. 751 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 752 4rev1", RFC 3501, March 2003. 754 9.2. Informative References 756 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 757 RFC 4314, December 2005. 759 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 760 STD 53, RFC 1939, May 1996. 762 [RFC2177] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997. 764 [RFC2447] Dawson, F., Mansour, S., and S. Silverberg, "iCalendar 765 Message-Based Interoperability Protocol (iMIP)", RFC 2447, 766 November 1998. 768 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 769 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 770 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 772 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 773 April 2001. 775 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 776 Internet: Timestamps", RFC 3339, July 2002. 778 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 779 Context for Internet Mail", RFC 3458, January 2003. 781 [RFC4146] Gellens, R., "Simple New Mail Notification", RFC 4146, 782 August 2005. 784 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 785 Security Layer (SASL)", RFC 4422, June 2006. 787 [RFC4467] Crispin, M., "Internet Message Access Protocol (IMAP) - 788 URLAUTH Extension", RFC 4467, May 2006. 790 [RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional 791 STORE Operation or Quick Flag Changes Resynchronization", 792 RFC 4551, June 2006. 794 Appendix A. Future Extensions 796 The "core" functionality is based on events which are believed to be 797 well understood, have known use cases and are implemented by at least 798 one deployed real-world Internet message store (FlagsSet and 799 FlagsClear are exceptions to the latter test only). 801 [[anchor23: have the mailbox admin events been deployed or should 802 they be added to the exceptions list?]] 804 Some events have been suggested, but are postponed to future 805 extensions because they do not meet this criteria. These events 806 include messages which have been moved to archive storage and may 807 require extra time to access, quota by message context, 808 authentication failure, user mail account disabled, annotations, and 809 mailbox ACL or metadata change. See Section 6 for how the list of 810 events and parameters can be extended. 812 In order to narrow the scope of this document to something that can 813 be completed, only events generated from the message store (by a 814 message access module, administrative module or message delivery 815 agent) are considered. A complete mail system is normally linked 816 with an identity system which would also publish events of interest 817 to a message store event subscriber. Events of interest include 818 account created/deleted/disabled and password changed/expired. 820 Authors' Addresses 822 Chris Newman 823 Sun Microsystems 824 3401 Centrelake Dr., Suite 410 825 Ontario, CA 91761 826 US 828 Email: chris.newman@sun.com 830 Randall Gellens 831 QUALCOMM Incorporated 832 5775 Morehouse Drive 833 San Diego, CA 92651 834 US 836 Email: rg+ietf@qualcomm.com 838 Full Copyright Statement 840 Copyright (C) The IETF Trust (2007). 842 This document is subject to the rights, licenses and restrictions 843 contained in BCP 78, and except as set forth therein, the authors 844 retain all their rights. 846 This document and the information contained herein are provided on an 847 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 848 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 849 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 850 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 851 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 852 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 854 Intellectual Property 856 The IETF takes no position regarding the validity or scope of any 857 Intellectual Property Rights or other rights that might be claimed to 858 pertain to the implementation or use of the technology described in 859 this document or the extent to which any license under such rights 860 might or might not be available; nor does it represent that it has 861 made any independent effort to identify any such rights. Information 862 on the procedures with respect to rights in RFC documents can be 863 found in BCP 78 and BCP 79. 865 Copies of IPR disclosures made to the IETF Secretariat and any 866 assurances of licenses to be made available, or the result of an 867 attempt made to obtain a general license or permission for the use of 868 such proprietary rights by implementers or users of this 869 specification can be obtained from the IETF on-line IPR repository at 870 http://www.ietf.org/ipr. 872 The IETF invites any interested party to bring to its attention any 873 copyrights, patents or patent applications, or other proprietary 874 rights that may cover technology that may be required to implement 875 this standard. Please address the information to the IETF at 876 ietf-ipr@ietf.org. 878 Acknowledgment 880 Funding for the RFC Editor function is provided by the IETF 881 Administrative Support Activity (IASA).