idnits 2.17.1 draft-ietf-lemonade-msgevent-00.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 578. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 555. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 562. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 568. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (June 6, 2006) is 6527 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 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 2222 (Obsoleted by RFC 4422, RFC 4752) -- 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) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Newman 3 Internet-Draft Sun Microsystems 4 Expires: December 8, 2006 June 6, 2006 6 Internet Message Store Events 7 draft-ietf-lemonade-msgevent-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 8, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 One of the missing features in the existing Internet mail and 41 messaging standards is a facility for server-to-server and server-to- 42 client event notifications related to message store events. As the 43 scope of Internet mail expands to support more diverse media (such as 44 voice mail), devices (such as cell phones) and to provide rich 45 interactions with other services (such as web portals and legal 46 compliance systems), the need for an interoperable notification 47 system increases. This document attempts to enumerate the types of 48 events which interest real-world consumers of such a system. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Change History . . . . . . . . . . . . . . . . . . . . . . 4 54 1.1.1. Changes from draft-newman-lemonade-msgevent-00.txt 55 to draft-ietf-lemonade-msgevent-00.txt . . . . . . . . 4 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Event Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Event Types . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4.1. Message Addition and Deletion . . . . . . . . . . . . . . 6 60 4.2. Message Flags . . . . . . . . . . . . . . . . . . . . . . 7 61 4.3. Access Accounting . . . . . . . . . . . . . . . . . . . . 8 62 5. Event Parameters . . . . . . . . . . . . . . . . . . . . . . . 8 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 66 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 67 Appendix A. Future Extensions . . . . . . . . . . . . . . . . . . 12 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 Intellectual Property and Copyright Statements . . . . . . . . . . 14 71 1. Introduction 73 A message store is used to organize Internet Messages [RFC2822] into 74 one or more mailboxes, annotate them in various ways and provide 75 access to these messages and associated meta-data. Three different 76 standards-based protocols have been widely deployed to remotely 77 access a message store. Post Office Protocol (POP) [RFC1939] 78 provides simple download-and-delete access to a single mail drop 79 (which is a subset of the functionality typically associated with a 80 message store). Internet Message Access Protocol (IMAP) [RFC3501] 81 provides an extensible feature-rich model for online, offline and 82 disconnected access to a message store with minimal constraints on 83 any associated "fat-client" user interface. Finally, mail access 84 applications built on top of Hypertext Transfer Protocol (HTTP) 85 [RFC2616] which run in standards-based web browsers provide a third 86 standards-based access mechanism for online-only access. 88 While simple and/or ad-hoc mechanisms for notifications have sufficed 89 to some degree in the past (e.g. Simple New Mail Notification 90 [RFC4146], IMAP4 IDLE command [RFC2177]), as the scope and importance 91 of message stores expands, the demand for a more complete store 92 notification system increases. Some of the driving forces behind 93 this demand include: 95 o Mobile devices with intermittent network connectivity that have 96 "new mail" or "message count" indicators 98 o Unified messaging systems which include both Internet and voice 99 mail require support for a message waiting indicator on phones 101 o Interaction with systems for event-based or utility-computing 102 billing 104 o Simplify the process of gatewaying message store events to non- 105 Internet notification systems 107 o A calendar system may wish to subscribe to NewMessage 108 notifications in order to support iMIP [RFC2447]. 110 o Recent laws for information protection and auditing will require 111 interoperable protocols between message stores built by messaging 112 experts and compliance auditing systems built by compliance 113 experts. 115 Vendors who have deployed proprietary notification systems for their 116 Internet message stores have seen significant demand to provide 117 notifications for more and more events. As a first step towards 118 building a notification system, this document attempts to enumerate 119 the core events that real-world customers demand. 121 1.1. Change History 123 This section will be removed if/when this draft is published as an 124 RFC. 126 1.1.1. Changes from draft-newman-lemonade-msgevent-00.txt to 127 draft-ietf-lemonade-msgevent-00.txt 129 o Rename draft title 131 o Add Change History section 133 o Update reference to URLAUTH 135 o Add SetFlags, ClearFlags events and flagNames parameter. Update 136 future events section to reflect this change. 138 o Removed unnecessary normative reference to NAMESPACE. 140 2. Terminology 142 The following terminology will be used in this document: 144 mailbox 145 A folder which contains Internet messages and may or may not 146 permit delivery of new messages via a mail delivery agent. 148 mailbox identifier 149 A mailbox identifier provides sufficient information to identify a 150 specific mailbox on a specific server instance. An IMAP URL can 151 be a mailbox identifier. 153 message access protocols 154 Protocols which provide clients (e.g. a mail user agent or web 155 browser) with access the message store including but not limited 156 to IMAP, POP and HTTP. 158 message context 159 As defined in [RFC3458]. 161 UIDVALIDITY 162 As defined in IMAP4rev1 [RFC3501]. UIDVALIDITY is critical to the 163 correct operation of a caching mail client. When it changes, the 164 client must flush its cache. It's particularly important to 165 include UIDVALIDITY with event notifications related to message 166 addition or removal in order to keep the message data correctly 167 synchronized. 169 3. Event Model 171 The events that are generated by a message store depend to some 172 degree on the model used to represent a message store. The model the 173 IETF has for a message store is implicit from IMAP4rev1 and 174 extensions, so that model is assumed by this document. 176 A message store event typically has an associated mailbox name and 177 usually has an associated user name (or authorization identity if 178 using the terminology from SASL [RFC2222]). Events referring to a 179 specific message can use an IMAP URL [RFC2192] to do so. Events 180 referring to a set of messages can use an IMAP URL to the mailbox 181 plus an IMAP UID set. 183 Each notification has a type and parameters. The type determines the 184 type of event, while the parameters supply information about the 185 context of the event that may be used to adjust subscription 186 preferences or may simply supply data associated with the event. The 187 types and parameter names in this document are restricted to US-ASCII 188 printable characters so these events can be easily mapped to an 189 arbitrary notification system. However, this document assumes 190 arbitrary parameter values (including large and multi-line values) 191 can be encoded with the notification system. Systems which lack that 192 feature could only implement a subset of these events. 194 This document does not yet take a position on which event parameters 195 are mandatory or optional. That will be done when actual message 196 formats or bindings to a notification system are completed. 198 For scalability reasons, some degree of filtering at event generation 199 is necessary. At the very list, the ability to turn on and off 200 groups of related events and to suppress inclusion of large 201 parameters (such as messageContent) is needed. A sophisticated 202 publish/subscribe notification system may be able to propagate 203 cumulative subscription information to the publisher. 205 some of these events might be logically collapsed into a single event 206 type with a required parameter to distinguish between the cases 207 (e.g., OverQuota and UnderQuota). However until such time that an 208 event subscription model is formulated, it's not practical to make 209 such decisions. We thus note only the fact that some of these events 210 may be viewed as a single event type. 212 4. Event Types 214 This section discusses the different types of events useful in a 215 message store event notification system. The intention is to 216 document the events sufficient to cover about 95% of the known use 217 cases while leaving less common event types for the future. This 218 section mentions parameters which are important or specific to the 219 events described here. Event parameters likely to be included in 220 most or all notifications are discussed in the next section. 222 4.1. Message Addition and Deletion 224 This section includes events related to message addition and 225 deletion. 227 AppendMessage 228 A message was appended or concatenated to a mailbox by a message 229 access client. For the most part, this is identical to the 230 NewMessage event type, except that the SMTP envelope information 231 is not included as a parameter, but information about which 232 protocol triggered the event may be included. See the NewMessage 233 event for more information. 235 ExpireMessage 236 One or more messages were expired from a mailbox due to server 237 expiration policy and are no longer accessible by the end-user. 238 The parameters include a mailbox identifier which must include 239 UIDVALIDITY. A UID set references the messages. Information 240 about which server expiration policy was applied may be included 241 as parameters in a future version. 243 ExpungeMessage 244 One or more messages were expunged from a mailbox by an IMAP 245 CLOSE/EXPUNGE, POP3 DELE+QUIT, HTTP or equivalent client action 246 and are no longer accessible by the end-user. The parameters 247 include a mailbox identifier which must include UIDVALIDITY, a UID 248 set, and may also indicate which access protocol triggered the 249 event. 251 NewMessage 252 A new message was received into a mailbox via a message delivery 253 agent. The parameters include a message identifier which must 254 include UIDVALIDITY and UID for IMAP-accessible message stores. 255 The parameters may also include the entire new message itself, 256 possibly an SMTP envelope and other arbitrary message and mailbox 257 meta-data. The set of parameters included should be adjustable to 258 the client's preference with limits set by server policy. An 259 interesting policy, for example, would be to include messages up 260 to 2K in size with the notification, but for larger messages to 261 include a URLAUTH [RFC4467] reference. 263 OverQuota 264 An operation failed (typically NewMessage) because the user's 265 mailbox exceeded one of the quotas (e.g., disk quota, message 266 quota, quota by message context, etc). The parameters should 267 include at least the relevant user and quota, and optionally the 268 mailbox. Quota usage should be included if possible. Parameters 269 needed to extend this to support quota by context are not 270 presently described in this document, but could be added in the 271 future. 273 UnderQuota 274 An operation occurred (typically ExpungeMessages or 275 ExpireMessages) which reduced the user's quota usage under their 276 limit. 278 4.2. Message Flags 280 This section includes events related to changes in message flags. 282 ReadMessages 283 One or more messages in the mailbox were marked as read or seen by 284 a user. Note that POP has no concept of read or seen messages, so 285 these events will only be generated by IMAP or HTTP clients (or 286 equivalent). The parameters include a mailbox identifier and a 287 set of message UIDs. 289 TrashMessages 290 One or more messages were marked for future deletion by the user 291 but are still accessible over protocol (the user's client may or 292 may not make these messages accessible through its user 293 interface). The parameters include a mailbox identifier and a set 294 of message UIDs. 296 SetFlags 297 One or more messages in the mailbox had an IMAP flag or keyword 298 set. The parameters include a list of IMAP flag or keyword names 299 that were set, a mailbox identifier and a set of message UIDs that 300 were impacted. For compatibility with simpler clients, it should 301 be configurable whether setting the \Seen or \Deleted flags 302 results in this event or the simpler ReadMessages/TrashMessages 303 events. By default, the simpler message forms should be used for 304 ReadMessages and TrashMessages. 306 ClearFlags 307 One or more messages in the mailbox had an IMAP flag or keyword 308 cleared. The parameters include a list of IMAP flag or keyword 309 names that were cleared, a mailbox identifier and a set of message 310 UIDs that were impacted. The flagName not include \Recent. 312 4.3. Access Accounting 314 This section includes events related to message store access 315 accounting. 317 Login 318 A user has logged in to the system via IMAP, HTTP, POP or some 319 other mechanism. The parameters include a the server domain name 320 and port and the user's authorization identity. Additional 321 possible parameters include the client's IP address and port, the 322 authentication identity (if different from the authorization 323 identity), the service name, the authentication mechanism, 324 information about any negotiated security layers, a timestamp and 325 other information. 327 Logout 328 A user has logged out or otherwise been disconnected from the 329 message store via IMAP, HTTP, POP or some other mechanism. The 330 parameters include the server domain name and the user's 331 authorization identity. Additional parameters may include any of 332 the information from the "Login" event as well as information 333 about the type of disconnect (graceful, abort, timeout, security 334 layer error), the duration of the connection or session and other 335 information. 337 5. Event Parameters 339 This section lists parameters that may be useful to include with 340 these events. 342 admin 343 Included with all events generated by message access protocols. 344 The authentication identity associated with this event, as 345 distinct from the authorization identity (see "user"). This is 346 not included when it is the same as the value of the user 347 parameter. 349 bodyStructure 350 May be included with AppendMessage and NewMessage. 351 The IMAP BODYSTRUCTURE of the message. 353 clientIP 354 Included with all events generated by message access protocols. 355 The IP address of the message store access client which performed 356 an action which triggered the notification. 358 clientPort 359 Included with all events generated by message access protocols. 360 The port number of the message store access client which performed 361 an action which triggered the notification. 363 diskQuota 364 Included with OverQuota and UnderQuota notifications relating to a 365 user or mailbox disk quota. May be included with other 366 notifications. 367 Disk quota limit in kilobytes. 369 diskUsed 370 Included with OverQuota and UnderQuota notifications relating to a 371 user or mailbox disk quota. May be included with other 372 notifications. 373 Disk quota used in kilobytes. 375 flagNames 376 Included with SetFlags and ClearFlags events. May be included 377 with AppendMessage and NewMessage to indicate flags which were set 378 initially by the APPEND command or delivery agent respectively. 379 A space-separated list of IMAP flag or keyword names that were set 380 or cleared. Flag names begin with backslash while keyword names 381 do not. The \Recent flag is explicitly not permitted in the list. 383 maxMessages 384 Included with OverQuota and UnderQuota notifications relating to a 385 user or mailbox message count quota. May be included with other 386 notifications. 387 Quota limit on the number of messages in the mailbox, for events 388 referring to a mailbox. 390 messageContent 391 May be included with AppendMessage and NewMessage. 392 The entire message itself. Size based suppression of this should 393 be available. 395 messageSize 396 May be included with AppendMessage and NewMessage. 397 Size of the RFC 2822 message itself in octets. This value would 398 match the length of the IMAP literal which would be returned in 399 response to an IMAP FETCH of BODY[] for the referenced message. 401 messages 402 Included with OverQuota and UnderQuota notifications relating to a 403 user or mailbox message count quota. May be included with other 404 notifications. 405 Number of messages in the mailbox. This is typically included 406 with message addition and deletion events. 408 pid 409 May be included with any notification. 410 The process id of the process which generated the notification. 412 process 413 May be included with any notification. 414 The name of the process which generated the notification. 416 serverFQDN 417 May be included with any notification. 418 The fully-qualified-domain-name of the server which generated the 419 event. Note that this may be different from the server name used 420 to access the mailbox included in the mailbox identifier. 422 service 423 May be included with any notification. 424 The name of the service which triggered the event. Suggested 425 values include "imap", "pop", "http", "admincli". 427 envelope 428 May be included with the NewMessage notification. 429 The message transfer envelope associated with final delivery of 430 the message for the NewMessage notification. This will include 431 the MAIL FROM and relevant RCPT TO line(s) used for final delivery 432 with CRLF delimiters and any ESMTP parameters. 434 timestamp 435 May be included with any notification. 436 When the notification was generated. 438 uidnext 439 May be included with any notification referring to a mailbox. 440 The next UID that will be assigned in the mailbox. This is 441 typically included with message addition and deletion events. 442 This is equivalent to the UIDNEXT status item in the IMAP STATUS 443 command. 445 uidset 446 Included with ExpireMessages, ExpungeMessages, ReadMessages, 447 TrashMessages, SetFlags and ClearFlags. 448 This includes the set of IMAP UIDs referenced. 450 uri 451 Included with all notifications and refers to the IMAP server, a 452 mailbox or a message. 453 Typically an IMAP URL. This can include the name of the server 454 used to access the mailbox/message, the mailbox name, the 455 UIDVALIDITY of the mailbox, and the UID of a specific message. 457 user 458 Included with all events generated by message access protocols. 459 This is the SASL authorization identifier used when the user 460 connected to the access protocol which triggered the event. For 461 events associated with a mailbox, this may be different from the 462 owner of the mailbox specified in the IMAP URL. 464 6. Security Considerations 466 Notifications can produce a large amount of traffic and expose 467 sensitive information. A competent transfer protocol for 468 notifications must address authentication, authorization and privacy, 469 as well as denial-of-service issues. While the IETF has adequate 470 tools and experience to address these issues for mechanisms which 471 involve only one TCP connection, notification or publish/subscribe 472 protocols which are more sophisticated than a single end-to-end TCP 473 connection will need to pay extra attention to these issues and 474 carefully balance requirements to successfully deploy a system with 475 security and privacy considerations. 477 7. References 479 7.1. Normative References 481 [RFC2192] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997. 483 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 484 April 2001. 486 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 487 4rev1", RFC 3501, March 2003. 489 7.2. Informative References 491 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 492 STD 53, RFC 1939, May 1996. 494 [RFC2177] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997. 496 [RFC2222] Myers, J., "Simple Authentication and Security Layer 497 (SASL)", RFC 2222, October 1997. 499 [RFC2447] Dawson, F., Mansour, S., and S. Silverberg, "iCalendar 500 Message-Based Interoperability Protocol (iMIP)", RFC 2447, 501 November 1998. 503 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 504 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 505 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 507 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 508 Context for Internet Mail", RFC 3458, January 2003. 510 [RFC4146] Gellens, R., "Simple New Mail Notification", RFC 4146, 511 August 2005. 513 [RFC4467] Crispin, M., "Internet Message Access Protocol (IMAP) - 514 URLAUTH Extension", RFC 4467, May 2006. 516 Appendix A. Future Extensions 518 The "core" functionality is based on events which are believed to be 519 well understood, have known use cases and are implemented by at least 520 one deployed real-world Internet message store (SetFlags and 521 ClearFlags are exceptions to the latter test only). Some events have 522 been suggested, but are postponed to future extensions because they 523 do not meet this criteria. These events include messages which have 524 been moved to archive storage and may require extra time to access, 525 quota by message context, authentication failure, user mail account 526 disabled, annotations and mailbox create/delete/rename. 528 In order to narrow the scope of this document to something that can 529 be completed, only events generated from the message store (by a 530 message access module, administrative module or message delivery 531 agent) are considered. A complete mail system will be linked with an 532 identity system which would also publish events of interest to a 533 message store event subscriber. Events of interest include account 534 created/deleted/disabled and password changed/expired. 536 Author's Address 538 Chris Newman 539 Sun Microsystems 540 3401 Centrelake Dr., Suite 410 541 Ontario, CA 91761 542 US 544 Email: chris.newman@sun.com 546 Intellectual Property Statement 548 The IETF takes no position regarding the validity or scope of any 549 Intellectual Property Rights or other rights that might be claimed to 550 pertain to the implementation or use of the technology described in 551 this document or the extent to which any license under such rights 552 might or might not be available; nor does it represent that it has 553 made any independent effort to identify any such rights. Information 554 on the procedures with respect to rights in RFC documents can be 555 found in BCP 78 and BCP 79. 557 Copies of IPR disclosures made to the IETF Secretariat and any 558 assurances of licenses to be made available, or the result of an 559 attempt made to obtain a general license or permission for the use of 560 such proprietary rights by implementers or users of this 561 specification can be obtained from the IETF on-line IPR repository at 562 http://www.ietf.org/ipr. 564 The IETF invites any interested party to bring to its attention any 565 copyrights, patents or patent applications, or other proprietary 566 rights that may cover technology that may be required to implement 567 this standard. Please address the information to the IETF at 568 ietf-ipr@ietf.org. 570 Disclaimer of Validity 572 This document and the information contained herein are provided on an 573 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 574 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 575 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 576 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 577 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 578 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 580 Copyright Statement 582 Copyright (C) The Internet Society (2006). This document is subject 583 to the rights, licenses and restrictions contained in BCP 78, and 584 except as set forth therein, the authors retain all their rights. 586 Acknowledgment 588 Funding for the RFC Editor function is currently provided by the 589 Internet Society.