idnits 2.17.1 draft-ietf-lemonade-msgevent-01.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, updated by RFC 4748 on line 586. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 597. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 604. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 610. 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 IETF Trust 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 (March 2, 2007) is 6265 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) -- Obsolete informational reference (is this intentional?): RFC 4551 (Obsoleted by RFC 7162) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 11 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: September 3, 2007 March 2, 2007 6 Internet Message Store Events 7 draft-ietf-lemonade-msgevent-01.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 September 3, 2007. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 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 -00 to -01 . . . . . . . . . . . . . . . 4 55 1.1.2. Changes from draft-newman-lemonade-msgevent-00.txt 56 to draft-ietf-lemonade-msgevent-00.txt . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Event Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Event Types . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.1. Message Addition and Deletion . . . . . . . . . . . . . . 6 61 4.2. Message Flags . . . . . . . . . . . . . . . . . . . . . . 7 62 4.3. Access Accounting . . . . . . . . . . . . . . . . . . . . 8 63 5. Event Parameters . . . . . . . . . . . . . . . . . . . . . . . 8 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 67 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 68 Appendix A. Future Extensions . . . . . . . . . . . . . . . . . . 13 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 Intellectual Property and Copyright Statements . . . . . . . . . . 14 72 1. Introduction 74 A message store is used to organize Internet Messages [RFC2822] into 75 one or more mailboxes, annotate them in various ways and provide 76 access to these messages and associated meta-data. Three different 77 standards-based protocols have been widely deployed to remotely 78 access a message store. Post Office Protocol (POP) [RFC1939] 79 provides simple download-and-delete access to a single mail drop 80 (which is a subset of the functionality typically associated with a 81 message store). Internet Message Access Protocol (IMAP) [RFC3501] 82 provides an extensible feature-rich model for online, offline and 83 disconnected access to a message store with minimal constraints on 84 any associated "fat-client" user interface. Finally, mail access 85 applications built on top of Hypertext Transfer Protocol (HTTP) 86 [RFC2616] which run in standards-based web browsers provide a third 87 standards-based access mechanism for online-only access. 89 While simple and/or ad-hoc mechanisms for notifications have sufficed 90 to some degree in the past (e.g. Simple New Mail Notification 91 [RFC4146], IMAP4 IDLE command [RFC2177]), as the scope and importance 92 of message stores expands, the demand for a more complete store 93 notification system increases. Some of the driving forces behind 94 this demand include: 96 o Mobile devices with intermittent network connectivity that have 97 "new mail" or "message count" indicators 99 o Unified messaging systems which include both Internet and voice 100 mail require support for a message waiting indicator on phones 102 o Interaction with systems for event-based or utility-computing 103 billing 105 o Simplify the process of passing message store events to non- 106 Internet notification systems 108 o A calendar system may wish to subscribe to NewMessage 109 notifications in order to support iMIP [RFC2447]. 111 o Recent laws for information protection and auditing will require 112 interoperable protocols between message stores built by messaging 113 experts and compliance auditing systems built by compliance 114 experts. 116 Vendors who have deployed proprietary notification systems for their 117 Internet message stores have seen significant demand to provide 118 notifications for more and more events. As a first step towards 119 building a notification system, this document attempts to enumerate 120 the core events that real-world customers demand. 122 1.1. Change History 124 This section will be removed if/when this draft is published as an 125 RFC. 127 1.1.1. Changes from -00 to -01 129 o Add modseq event parameter. 131 o Add tags event parameter. 133 1.1.2. Changes from draft-newman-lemonade-msgevent-00.txt to 134 draft-ietf-lemonade-msgevent-00.txt 136 o Rename draft title 138 o Add Change History section 140 o Update reference to URLAUTH 142 o Add SetFlags, ClearFlags events and flagNames parameter. Update 143 future events section to reflect this change. 145 o Removed unnecessary normative reference to NAMESPACE. 147 2. Terminology 149 The following terminology will be used in this document: 151 mailbox 152 A folder which contains Internet messages and may or may not 153 permit delivery of new messages via a mail delivery agent. 155 mailbox identifier 156 A mailbox identifier provides sufficient information to identify a 157 specific mailbox on a specific server instance. An IMAP URL can 158 be a mailbox identifier. 160 message access protocols 161 Protocols which provide clients (e.g. a mail user agent or web 162 browser) with access the message store including but not limited 163 to IMAP, POP and HTTP. 165 message context 166 As defined in [RFC3458]. 168 UIDVALIDITY 169 As defined in IMAP4rev1 [RFC3501]. UIDVALIDITY is critical to the 170 correct operation of a caching mail client. When it changes, the 171 client must flush its cache. It's particularly important to 172 include UIDVALIDITY with event notifications related to message 173 addition or removal in order to keep the message data correctly 174 synchronized. 176 3. Event Model 178 The events that are generated by a message store depend to some 179 degree on the model used to represent a message store. The model the 180 IETF has for a message store is implicit from IMAP4rev1 and 181 extensions, so that model is assumed by this document. 183 A message store event typically has an associated mailbox name and 184 usually has an associated user name (or authorization identity if 185 using the terminology from SASL [RFC2222]). Events referring to a 186 specific message can use an IMAP URL [RFC2192] to do so. Events 187 referring to a set of messages can use an IMAP URL to the mailbox 188 plus an IMAP UID set. 190 Each notification has a type and parameters. The type determines the 191 type of event, while the parameters supply information about the 192 context of the event that may be used to adjust subscription 193 preferences or may simply supply data associated with the event. The 194 types and parameter names in this document are restricted to US-ASCII 195 printable characters so these events can be easily mapped to an 196 arbitrary notification system. However, this document assumes 197 arbitrary parameter values (including large and multi-line values) 198 can be encoded with the notification system. Systems which lack that 199 feature could only implement a subset of these events. 201 This document does not yet take a position on which event parameters 202 are mandatory or optional. That will be done when actual message 203 formats or bindings to a notification system are completed. 205 For scalability reasons, some degree of filtering at event generation 206 is necessary. At the very list, the ability to turn on and off 207 groups of related events and to suppress inclusion of large 208 parameters (such as messageContent) is needed. A sophisticated 209 publish/subscribe notification system may be able to propagate 210 cumulative subscription information to the publisher. 212 some of these events might be logically collapsed into a single event 213 type with a required parameter to distinguish between the cases 214 (e.g., OverQuota and UnderQuota). However until such time that an 215 event subscription model is formulated, it's not practical to make 216 such decisions. We thus note only the fact that some of these events 217 may be viewed as a single event type. 219 4. Event Types 221 This section discusses the different types of events useful in a 222 message store event notification system. The intention is to 223 document the events sufficient to cover about 95% of the known use 224 cases while leaving less common event types for the future. This 225 section mentions parameters which are important or specific to the 226 events described here. Event parameters likely to be included in 227 most or all notifications are discussed in the next section. 229 4.1. Message Addition and Deletion 231 This section includes events related to message addition and 232 deletion. 234 AppendMessage 235 A message was appended or concatenated to a mailbox by a message 236 access client. For the most part, this is identical to the 237 NewMessage event type, except that the SMTP envelope information 238 is not included as a parameter, but information about which 239 protocol triggered the event may be included. See the NewMessage 240 event for more information. 242 ExpireMessage 243 One or more messages were expired from a mailbox due to server 244 expiration policy and are no longer accessible by the end-user. 245 The parameters include a mailbox identifier which must include 246 UIDVALIDITY. A UID set references the messages. Information 247 about which server expiration policy was applied may be included 248 as parameters in a future version. 250 ExpungeMessage 251 One or more messages were expunged from a mailbox by an IMAP 252 CLOSE/EXPUNGE, POP3 DELE+QUIT, HTTP or equivalent client action 253 and are no longer accessible by the end-user. The parameters 254 include a mailbox identifier which must include UIDVALIDITY, a UID 255 set, and may also indicate which access protocol triggered the 256 event. 258 NewMessage 259 A new message was received into a mailbox via a message delivery 260 agent. The parameters include a message identifier which must 261 include UIDVALIDITY and UID for IMAP-accessible message stores. 262 The parameters may also include the entire new message itself, 263 possibly an SMTP envelope and other arbitrary message and mailbox 264 meta-data. The set of parameters included should be adjustable to 265 the client's preference with limits set by server policy. An 266 interesting policy, for example, would be to include messages up 267 to 2K in size with the notification, but for larger messages to 268 include a URLAUTH [RFC4467] reference. 270 OverQuota 271 An operation failed (typically NewMessage) because the user's 272 mailbox exceeded one of the quotas (e.g., disk quota, message 273 quota, quota by message context, etc). The parameters should 274 include at least the relevant user and quota, and optionally the 275 mailbox. Quota usage should be included if possible. Parameters 276 needed to extend this to support quota by context are not 277 presently described in this document, but could be added in the 278 future. 280 UnderQuota 281 An operation occurred (typically ExpungeMessages or 282 ExpireMessages) which reduced the user's quota usage under their 283 limit. 285 4.2. Message Flags 287 This section includes events related to changes in message flags. 289 ReadMessages 290 One or more messages in the mailbox were marked as read or seen by 291 a user. Note that POP has no concept of read or seen messages, so 292 these events will only be generated by IMAP or HTTP clients (or 293 equivalent). The parameters include a mailbox identifier and a 294 set of message UIDs. 296 TrashMessages 297 One or more messages were marked for future deletion by the user 298 but are still accessible over protocol (the user's client may or 299 may not make these messages accessible through its user 300 interface). The parameters include a mailbox identifier and a set 301 of message UIDs. 303 SetFlags 304 One or more messages in the mailbox had an IMAP flag or keyword 305 set. The parameters include a list of IMAP flag or keyword names 306 that were set, a mailbox identifier and a set of message UIDs that 307 were impacted. For compatibility with simpler clients, it should 308 be configurable whether setting the \Seen or \Deleted flags 309 results in this event or the simpler ReadMessages/TrashMessages 310 events. By default, the simpler message forms should be used for 311 ReadMessages and TrashMessages. 313 ClearFlags 314 One or more messages in the mailbox had an IMAP flag or keyword 315 cleared. The parameters include a list of IMAP flag or keyword 316 names that were cleared, a mailbox identifier and a set of message 317 UIDs that were impacted. The flagName not include \Recent. 319 4.3. Access Accounting 321 This section includes events related to message store access 322 accounting. 324 Login 325 A user has logged in to the system via IMAP, HTTP, POP or some 326 other mechanism. The parameters include a the server domain name 327 and port and the user's authorization identity. Additional 328 possible parameters include the client's IP address and port, the 329 authentication identity (if different from the authorization 330 identity), the service name, the authentication mechanism, 331 information about any negotiated security layers, a timestamp and 332 other information. 334 Logout 335 A user has logged out or otherwise been disconnected from the 336 message store via IMAP, HTTP, POP or some other mechanism. The 337 parameters include the server domain name and the user's 338 authorization identity. Additional parameters may include any of 339 the information from the "Login" event as well as information 340 about the type of disconnect (graceful, abort, timeout, security 341 layer error), the duration of the connection or session and other 342 information. 344 5. Event Parameters 346 This section lists parameters that may be useful to include with 347 these events. 349 admin 350 Included with all events generated by message access protocols. 351 The authentication identity associated with this event, as 352 distinct from the authorization identity (see "user"). This is 353 not included when it is the same as the value of the user 354 parameter. 356 bodyStructure 357 May be included with AppendMessage and NewMessage. 358 The IMAP BODYSTRUCTURE of the message. 360 clientIP 361 Included with all events generated by message access protocols. 362 The IP address of the message store access client which performed 363 an action which triggered the notification. 365 clientPort 366 Included with all events generated by message access protocols. 367 The port number of the message store access client which performed 368 an action which triggered the notification. 370 diskQuota 371 Included with OverQuota and UnderQuota notifications relating to a 372 user or mailbox disk quota. May be included with other 373 notifications. 374 Disk quota limit in kilobytes. 376 diskUsed 377 Included with OverQuota and UnderQuota notifications relating to a 378 user or mailbox disk quota. May be included with other 379 notifications. 380 Disk quota used in kilobytes. 382 envelope 383 May be included with the NewMessage notification. 384 The message transfer envelope associated with final delivery of 385 the message for the NewMessage notification. This will include 386 the MAIL FROM and relevant RCPT TO line(s) used for final delivery 387 with CRLF delimiters and any ESMTP parameters. 389 flagNames 390 Included with SetFlags and ClearFlags events. May be included 391 with AppendMessage and NewMessage to indicate flags which were set 392 initially by the APPEND command or delivery agent respectively. 393 A space-separated list of IMAP flag or keyword names that were set 394 or cleared. Flag names begin with backslash while keyword names 395 do not. The \Recent flag is explicitly not permitted in the list. 397 maxMessages 398 Included with OverQuota and UnderQuota notifications relating to a 399 user or mailbox message count quota. May be included with other 400 notifications. 401 Quota limit on the number of messages in the mailbox, for events 402 referring to a mailbox. 404 messageContent 405 May be included with AppendMessage and NewMessage. 406 The entire message itself. Size based suppression of this should 407 be available. 409 messageSize 410 May be included with AppendMessage and NewMessage. 411 Size of the RFC 2822 message itself in octets. This value would 412 match the length of the IMAP literal which would be returned in 413 response to an IMAP FETCH of BODY[] for the referenced message. 415 messages 416 Included with OverQuota and UnderQuota notifications relating to a 417 user or mailbox message count quota. May be included with other 418 notifications. 419 Number of messages in the mailbox. This is typically included 420 with message addition and deletion events. 422 modseq 423 May be included with any notification referring to one message. 424 This is the 64-bit integer MODSEQ as defined in [RFC4551]. No 425 assumptions about MODSEQ can be made if this is omitted. 427 pid 428 May be included with any notification. 429 The process id of the process which generated the notification. 431 process 432 May be included with any notification. 433 The name of the process which generated the notification. 435 serverFQDN 436 May be included with any notification. 437 The fully-qualified-domain-name of the server which generated the 438 event. Note that this may be different from the server name used 439 to access the mailbox included in the mailbox identifier. 441 service 442 May be included with any notification. 443 The name of the service which triggered the event. Suggested 444 values include "imap", "pop", "http", "admincli". 446 tags 447 May be included with any notification. 448 This is a comma-separated list of UTF-8 tags. One or more tags 449 can be set at the time a notification criteria or notification 450 subscription is created. Subscribers can use tags for additional 451 client-side filtering or dispatch of events. 453 timestamp 454 May be included with any notification. 455 When the notification was generated in [RFC3339] syntax. 457 uidnext 458 May be included with any notification referring to a mailbox. 459 The next UID that will be assigned in the mailbox. This is 460 typically included with message addition and deletion events. 461 This is equivalent to the UIDNEXT status item in the IMAP STATUS 462 command. 464 uidset 465 Included with ExpireMessages, ExpungeMessages, ReadMessages, 466 TrashMessages, SetFlags and ClearFlags. 467 This includes the set of IMAP UIDs referenced. 469 uri 470 Included with all notifications and refers to the IMAP server, a 471 mailbox or a message. 472 Typically an IMAP URL. This can include the name of the server 473 used to access the mailbox/message, the mailbox name, the 474 UIDVALIDITY of the mailbox, and the UID of a specific message. 476 user 477 Included with all events generated by message access protocols. 478 This is the SASL authorization identifier used when the user 479 connected to the access protocol which triggered the event. For 480 events associated with a mailbox, this may be different from the 481 owner of the mailbox specified in the IMAP URL. 483 6. Security Considerations 485 Notifications can produce a large amount of traffic and expose 486 sensitive information. A competent transfer protocol for 487 notifications must address authentication, authorization and privacy, 488 as well as denial-of-service issues. While the IETF has adequate 489 tools and experience to address these issues for mechanisms which 490 involve only one TCP connection, notification or publish/subscribe 491 protocols which are more sophisticated than a single end-to-end TCP 492 connection will need to pay extra attention to these issues and 493 carefully balance requirements to successfully deploy a system with 494 security and privacy considerations. 496 7. References 498 7.1. Normative References 500 [RFC2192] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997. 502 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 503 April 2001. 505 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 506 4rev1", RFC 3501, March 2003. 508 7.2. Informative References 510 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 511 STD 53, RFC 1939, May 1996. 513 [RFC2177] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997. 515 [RFC2222] Myers, J., "Simple Authentication and Security Layer 516 (SASL)", RFC 2222, October 1997. 518 [RFC2447] Dawson, F., Mansour, S., and S. Silverberg, "iCalendar 519 Message-Based Interoperability Protocol (iMIP)", RFC 2447, 520 November 1998. 522 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 523 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 524 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 526 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 527 Internet: Timestamps", RFC 3339, July 2002. 529 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 530 Context for Internet Mail", RFC 3458, January 2003. 532 [RFC4146] Gellens, R., "Simple New Mail Notification", RFC 4146, 533 August 2005. 535 [RFC4467] Crispin, M., "Internet Message Access Protocol (IMAP) - 536 URLAUTH Extension", RFC 4467, May 2006. 538 [RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional 539 STORE Operation or Quick Flag Changes Resynchronization", 540 RFC 4551, June 2006. 542 Appendix A. Future Extensions 544 The "core" functionality is based on events which are believed to be 545 well understood, have known use cases and are implemented by at least 546 one deployed real-world Internet message store (SetFlags and 547 ClearFlags are exceptions to the latter test only). Some events have 548 been suggested, but are postponed to future extensions because they 549 do not meet this criteria. These events include messages which have 550 been moved to archive storage and may require extra time to access, 551 quota by message context, authentication failure, user mail account 552 disabled, annotations and mailbox create/delete/rename. 554 In order to narrow the scope of this document to something that can 555 be completed, only events generated from the message store (by a 556 message access module, administrative module or message delivery 557 agent) are considered. A complete mail system will be linked with an 558 identity system which would also publish events of interest to a 559 message store event subscriber. Events of interest include account 560 created/deleted/disabled and password changed/expired. 562 Author's Address 564 Chris Newman 565 Sun Microsystems 566 3401 Centrelake Dr., Suite 410 567 Ontario, CA 91761 568 US 570 Email: chris.newman@sun.com 572 Full Copyright Statement 574 Copyright (C) The IETF Trust (2007). 576 This document is subject to the rights, licenses and restrictions 577 contained in BCP 78, and except as set forth therein, the authors 578 retain all their rights. 580 This document and the information contained herein are provided on an 581 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 582 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 583 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 584 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 585 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 586 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 588 Intellectual Property 590 The IETF takes no position regarding the validity or scope of any 591 Intellectual Property Rights or other rights that might be claimed to 592 pertain to the implementation or use of the technology described in 593 this document or the extent to which any license under such rights 594 might or might not be available; nor does it represent that it has 595 made any independent effort to identify any such rights. Information 596 on the procedures with respect to rights in RFC documents can be 597 found in BCP 78 and BCP 79. 599 Copies of IPR disclosures made to the IETF Secretariat and any 600 assurances of licenses to be made available, or the result of an 601 attempt made to obtain a general license or permission for the use of 602 such proprietary rights by implementers or users of this 603 specification can be obtained from the IETF on-line IPR repository at 604 http://www.ietf.org/ipr. 606 The IETF invites any interested party to bring to its attention any 607 copyrights, patents or patent applications, or other proprietary 608 rights that may cover technology that may be required to implement 609 this standard. Please address the information to the IETF at 610 ietf-ipr@ietf.org. 612 Acknowledgment 614 Funding for the RFC Editor function is provided by the IETF 615 Administrative Support Activity (IASA).