idnits 2.17.1 draft-ietf-sipping-capacity-attribute-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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 587. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 598. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 611. ** 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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (September 1, 2006) is 6440 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) -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 440 ** Obsolete normative reference: RFC 2246 (ref. '3') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 3851 (ref. '8') (Obsoleted by RFC 5751) == Outdated reference: A later version (-07) exists of draft-ietf-sipping-uri-services-05 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group M. Garcia-Martin 3 Internet-Draft Nokia 4 Intended status: Standards Track G. Camarillo 5 Expires: March 5, 2007 Ericsson 6 September 1, 2006 8 Extensible Markup Language (XML) Format Extension for Representing 9 Capacity Attributes in Resource Lists 10 draft-ietf-sipping-capacity-attribute-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on March 5, 2007. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document specifies an XML extension to the resource list format 44 for qualifiying resources with the capacity in which they are 45 included in the resource list. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 4. Extension to the resource lists data format . . . . . . . . . 5 53 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 7 54 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 7. Carrying URI-lists in SIP . . . . . . . . . . . . . . . . . . 9 56 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 57 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 58 9.1. Disposition Type Registration . . . . . . . . . . . . . . 10 59 9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 11 60 9.3. XML Schema Registration . . . . . . . . . . . . . . . . . 12 61 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 62 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 63 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 64 11.2. Informational References . . . . . . . . . . . . . . . . . 13 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 66 Intellectual Property and Copyright Statements . . . . . . . . . . 14 68 1. Introduction 70 The Framework and Security Considerations for Session Initiation 71 Protocol (SIP) URI-List Services [9] describes a generic framework 72 for carrying Uniform Resource Identifier (URI)-lists in SIP [5] 73 messages. Specifically the document provides a common framework for 74 specific implementations of URI-list services, such as conferences 75 initiated with INVITE requests [10] or Multiple-recipient MESSAGE 76 requests [11]. 78 Common to a multiple of URI-list services is the presence of a SIP 79 request that contains a collection of resources, typically expressed 80 as an XML resource list [7]. SIP requests carrying resource lists 81 can appear either in requests received by the URI-list server, 82 indicating the list of intended recipients; or in each of the 83 requests that the URI-list server sends to recipients, indicating the 84 list of recipients of the same SIP request. 86 Although the XML resource list [7] provides a powerful mechanism for 87 indicating list of resources, it is usually beneficial to indicate 88 the capacity in which a resource is receiving a SIP request. This is 89 similar to common e-mail where the sender can assign each recipient 90 the capacity of To, Cc, or Bcc, in which they are receiving an e-mail 91 message. 93 This document addresses this problem by providing an extension to the 94 XML resource list [7] that enables the sender to tag the capacity of 95 the recipients, as 'to', 'cc', or 'bcc'. Additionally, we provide 96 the sender with the capability of indicating in the URI-list that one 97 or more resources should be anonymized, so that their URIs are not 98 disclosed to the other recipients, but instead, they are replaced 99 with anonymous URIs. 101 The rest of this document is organized as follows: Section 2 102 introduces a few new terms. Section 3 gives an overview of 103 operation. Section 4 formally defines an extension to URI-lists. 104 The XML schema definition is provided in Section 5. Section 6 shows 105 examples of the URI-lists with the extensions defined in this 106 document. Section 7 discusses the implications of carrying URI-lists 107 in SIP messages. 109 2. Terminology 111 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 112 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 113 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 114 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 115 compliant implementations. 117 URI-list service: SIP application service that receives a SIP 118 request containing a URI-list and sends a similar SIP request to 119 each URI in the list. 121 Intended recipient: The intended final recipient of the request to 122 be generated by URI-list service. 124 Capacity: The role assigned by the sender to a recipient. The 125 sender is able to tag recipients with the 'to', 'cc', and 'bcc' 126 capacity, which indicate, respectively, whether the recipients get 127 a primary, carbon copy, or blind carbon copy of the SIP request. 129 3. Overview 131 Figure 1 depicts a general overview of the operation of a URI-list 132 server. A SIP User Agent Client (UAC) issuer sends a SIP request 133 (F1) to a URI-list server. The URI-list server generates a SIP 134 request to each of the recipients, according to the specific method. 136 +--------+ +---------+ +--------+ +--------+ +--------+ 137 |SIP UAC | | URI-list| |intended| |intended| |intended| 138 | issuer | | server | | recip. | | recip. | | recip. | 139 | | | | | 1 | | 2 | | n | 140 +--------+ +---------+ +--------+ +--------+ +--------+ 141 | | | | | 142 | F1. SIP request | | | | 143 | ---------------->| | | | 144 | F2. 2xx response | | | | 145 |<---------------- | F3. SIP request | | 146 | | ------------->| | | 147 | | F4. SIP request | | 148 | | ------------------------>| | 149 | | F5. SIP request | | 150 | | ----------------------------------->| 151 | | F6. 2xx response | | 152 | |<------------- | | | 153 | | F7. 2xx response | | 154 | |<------------------------ | | 155 | | F8. 2xx response | | 156 | |<----------------------------------- | 157 | | | | | 158 | | | | | 159 | | | | | 160 Figure 1: Example of operation 162 The URI-list mechanism allows a sender to specify multiple targets 163 for a SIP request by including an XML resource list [7] in the body 164 of the SIP request. This XML resource list includes the URIs of the 165 targets of the SIP request (the actual procedures are method specific 166 and outside the scope of this document). Each target URI may also be 167 marked to indicate in what capacity (or role) the recipient is 168 receiving the SIP request. The available capacities include 'to', 169 'cc', and 'bcc' (analogous to e-mail). Each target URI may also be 170 marked with the 'anonymize' attribute. This allows the sender of the 171 SIP request to indicate to the URI-list service that an intended 172 recipient should receive the SIP request, but his URI should not be 173 disclosed (for example, in a URI-list that the URI-list service could 174 send to the recipients of the SIP request). 176 When the URI-list server expands the request for each recipient, it 177 includes a new URI-list that contains only the targets originally 178 listed in the "to" and "cc" capacities, excludes those listed in the 179 'bcc' capacity. Further more, those URIs tagged with the 'anonymize' 180 attribute are replaced by an anonymous URI. 182 In case of multiple identical URIs the size of URI-list can be 183 compressed by adding a 'count' attribute to a URI. The 'count' 184 attribute indicates the number of repeated URIs. This is 185 particularly useful with anonymized URIs. It is not expected to have 186 value other than with anonymous URIs, although technically, it is 187 possible to include the 'count' attribute to any URI. 189 The presence of a URI-list in each of the expanded SIP requests 190 allows recipients to both see and reply to the non-anonymous "to" and 191 "cc" targets, but not to the "bcc" or anonymous targets. The default 192 capacity assumed, if one is not specified by the sender, is "bcc". 193 This is discussed in greater detailed in Section 4 195 4. Extension to the resource lists data format 197 This document defines an extension to the XML resource list data 198 format [7] that allows the sender to indicate the capacity or role in 199 which a recipient is receiving a message. We define a new 'capacity' 200 attribute to the element of the resource list document format 201 [7]. The 'capacity' attribute has similar semantics to the type of 202 destination address in e-mail systems. It can take the values "to", 203 "cc", and "bcc". A "to" value of the 'capacity' attribute indicates 204 that the resource is considered a primary recipient of the SIP 205 request. A "cc" value indicates that the resource receives a carbon 206 copy of the SIP request. A "bcc" value indicates that the resource 207 receives a blind carbon copy of the SIP request, i.e., this URI is 208 not disclosed in a URI-list sent to the recipients. The default 209 'capacity' value is "bcc", that is, the absence of a 'capacity' 210 attribute MUST be treated as if the 'capacity' was set to "bcc". 211 URI-list servers can use URIs tagged with the "bcc" 'capacity' 212 attribute for routing SIP requests, but MUST delete them if the URI- 213 list service includes a URI-list in outgoing requests. 215 A new 'anonymize' attribute can be included in a element of 216 the resource list document format [7]. If set to a "true" value, it 217 provides an indication to the URI-list server for not disclosing the 218 URI itself in a URI-list sent to the recipient, but instead, 219 anonymize the URI. URI-list servers can use URIs tagged with the 220 'anonymize' attribute for routing SIP requests, but MUST convert them 221 to an anonymized URI (such as sip:anonymous@anonymous.invalid) if the 222 URI-list server includes a URI-list in outgoing requests. The 223 default value of the 'anonymize' attribute is "false". 225 Processing of URIs tagged with a "bcc" 'capacity' has higher 226 precedence of the 'anonymize' attribute, thus, if the 'capacity' of a 227 URI is set to "bcc", the URI-list service will remove the URI from 228 the list and the 'anonymize' attribute will be ignored. Therefore, 229 the 'anonymize' attribute is only useful for those URIs tagged with a 230 'capacity' of "to" or "cc". 232 A new 'count' attribute can be also included in a element of 233 the resource list document format [7]. It provides the number of 234 equal URIs. Typically URI-lists created by UACs will not have equal 235 (or duplicated) URI entries, thus, it is not expected to contain URIs 236 tagged with the 'count' attributes. However, URI-lists created by 237 URI-list servers can contain duplicated anonymized URIs, thus, it is 238 expected that URI-list created by URI-list servers will contain 239 'count' attributes. The default value of the 'count' attribute is 240 "1". 242 The 'capacity', 'anonymize', and 'count' attributes SHOULD be 243 included as modifiers of any of the child elements included in the 244 element of a resource list (e.g., attribute of the or 245 elements). 247 Section 5 describes the format of the 'capacity', 'anonymize', and 248 'count' attributes. Implementations according to this specification 249 MUST support this XML Schema. 251 5. XML Schema 253 254 261 262 263 Adds the capacity, anonymize, and count attributes 264 to URIs included in a resource list. 265 266 268 271 272 273 274 275 276 277 278 279 281 282 285 287 Figure 2: XML Schema of the extension to the resource list format 289 6. Examples 291 This section shows two examples of URI-lists that can be included in 292 SIP requests. The first example in Figure 3 shows a URI-list that 293 the UAC sends to the URI-list server. This corresponds to a list 294 that will be included in the flow F2 in Figure 1. The list contains 295 a flat list according to the resource list data format [7]. Each 296 resource indicates the capacity of a resource. Some of the resources 297 are also attributed with the 'anonymize' attribute. This provides an 298 indication to the URI-list service for not disclosing their URIs in a 299 URI-list. The last two elements are attributed with a "bcc" 300 'capacity'. This provides an indication to the URI-list service for 301 removing these URIs from the outgoing URI-lists. 303 304 306 307 308 310 312 313 315 316 317 318 320 Figure 3: URI-list sent from the UAC to the URI-list server 322 Upon reception of the SIP request containing the URI-list of Figure 3 323 the URI-list service creates a SIP request for each of the URIs 324 listed in the URI-list (so, in our example, it creates 7 SIP 325 requests). Each outgoing SIP request contains a copy of the same 326 processed outgoing URI-list. The process is as follows: the URI-list 327 service creates a new URI-list, based on the received one, but with 328 changes. First it copies all the URIs ( elements) tagged with 329 the "to" or "cc" 'capacity' which do not contain an 'anonymize' 330 attribute (or when the 'anonymize' attribute is set to "false"). 331 Then all the URIs tagged with a 'capacity' attribute set to "to" and 332 'anonymize' set to "true" are replaced by an anonymous URI, such as 333 "sip:anonymous@anonymous.invalid". In this entry it also adds the 334 original 'capacity' attribute ("to" in our example), and it adds a 335 'count' attribute with the number of anonymous entries with this 336 capacity ("2" in our example). Then the URI-list service does the 337 same operation to the URIs tagged with the 'capacity' attribute set 338 to "cc" and 'anonymize' attribute set to "true", adding also the 339 'count' attribute containing the number of anonymous attributes with 340 this capacity ("1" in the example). Last, the URI-list service 341 completely removes URIs tagged with the "bcc" 'capacity'. The result 342 URI-list if shown in Figure 4. 344 345 347 348 349 351 352 354 355 357 Figure 4: URI-List sent from the URI-list server to each recipient 359 7. Carrying URI-lists in SIP 361 A SIP User Agent Client (UAC) that composes a SIP request can include 362 a URI-list with the extensions specified in this document to indicate 363 the list of intended recipients. On doing so, as specified in the 364 Framework and Security Considerations for SIP URI-List Services [9], 365 the UAC adds a Content-Disposition [2] header field set to the value 366 'recipient-list'. Typically UACs send these 'recipient-list' bodies 367 to URI-list services (this corresponds to flow F1 in Figure 1). A 368 body whose Content-Disposition type is 'recipient-list' contains a 369 URI-list with list of intended recipients of the SIP request. The 370 element in the URI-list MAY also include a 'capacity' and 371 'anonymize' attributes, as specified in Section 4. 373 To enable the capability of the intended recipients to become aware 374 of who else is receiving a copy of the SIP request, we define a new 375 mail disposition type to be included in a Content-Disposition [2] 376 header field of a SIP request. The value of this new disposition 377 type is 'recipient-list-history' and its purpose is to indicate a 378 list of recipients that a SIP request was sent to. A body whose 379 Content-Disposition type is 'recipient-list-history' contains a URI- 380 list with the visible (including anonymized) recipients of the SIP 381 request. The element in the URI-list MAY also include a 382 'capacity' and 'count' attributes, as specified in Section 4. 384 It is often desired that, if the intended recipient of the SIP 385 request does not support this specification, still the SIP request 386 does not fail. In order to provide the maximum probability of 387 success of those requests that include 'recipient-list-history' 388 bodies, User Agents (such as URI-list services) that build SIP 389 requests with the Content-Disposition header field set to 'recipient- 390 list-history' SHOULD add a 'handling' parameter [4] set to 391 "optional". 393 8. Security Considerations 395 The Framework and Security Considerations for SIP URI-List Services 396 [9] discusses issues related to SIP URI-list services. 397 Implementations of this specification MUST follow the security- 398 related rules in the Framework and Security Considerations for SIP 399 URI-List Services [9]. These rules include mandatory authentication 400 and authorization of clients, and opt-in lists. 402 User Agent Clients SHOULD NOT hand SIP requests containing URI-list 403 services to unauthenticated and untrusted parties. This is to avoid 404 man-in-the-middle attacks or acquiring URI-lists for performing SPAM 405 attacks. 407 URI-lists may contain private information, such as SIP URIs. It is 408 therefore not desirable that these URI-lists are known by third 409 parties. Eavesdroppers are able to watch URI-lists contained in SIP 410 requests unless the SIP message was sent over a secured channel with 411 Transport Layer Security (TLS) [3] or unless the URI-list body itself 412 is encrypted with S/MIME [8]. Therefore, it is RECOMMENDED that URI- 413 list bodies are encrypted with S/MIME [8] or that the SIP request is 414 encrypted with TLS [3]. 416 Note that this URI-list does not indicate the actual participants in 417 the session. It indicates only the URIs invited and that might 418 accept the request. It does not assert that these parties actually 419 exist, that they are reachable at the given URI, or that they have 420 accepted the invitation. No inferences about billing should be made 421 from this information. It is subject to spoofing by loading the list 422 with falsified content. 424 9. IANA Considerations 426 The following sections instruct the IANA to register: a new 427 disposition type, a new SIP option-tag, a new XML namespace, and a 428 new XML schema. 430 9.1. Disposition Type Registration 432 Section 7 defines a new 'recipient-list-history' value of the Mail 433 Content Disposition Values registry. This value should be registered 434 in the IANA registry of Mail Content Disposition Values with the 435 following registration data: 437 +------------------------+------------------------------+-----------+ 438 | Name | Description | Reference | 439 +------------------------+------------------------------+-----------+ 440 | recipient-list-history | the body contains a list of | [RFCXXXX] | 441 | | URIs that indicates the | | 442 | | recipients of the SIP | | 443 | | request | | 444 +------------------------+------------------------------+-----------+ 446 Table 1: Registration of the 'recipient-list-history' Mail Content 447 Disposition Value 449 Note to IANA and the RFC editor: replace RFCXXXX above with the RFC 450 number of this specification. 452 9.2. XML Namespace Registration 454 This section registers a new XML namespace in the XML registry, as 455 per the guidelines in RFC 3688 [6]. 457 URI: The URI for this namespace is urn:ietf:params:xml:ns:capacity. 459 Registrant Contact: IETF, SIPPING working group, (sipping@ietf.org), 460 Miguel Garcia-Martin (miguel.an.garcia@nokia.com). 462 XML: 464 BEGIN 465 466 468 469 470 472 Capacity Namespace 473 474 475

Namespace for the Capacity Attribute Extension 476 in Resource Lists

477

urn:ietf:params:xml:ns:capacity

478

See RFCXXXX 479 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with 480 the RFC number of this specification.].

481 482 483 END 485 9.3. XML Schema Registration 487 This section registers a new XML schema in the XML registry per the 488 procedures in RFC 3688 [6]. 490 URI: urn:ietf:params:xml:schema:capacity 492 Registrant Contact: IETF, SIPPING working group, (sipping@ietf.org), 493 Miguel Garcia-Martin (miguel.an.garcia@nokia.com). 495 The XML for this schema can be found as the sole content of 496 Section 5. 498 10. Acknowledgements 500 Thanks to Dean Willis, Jari Urpalainen, Pekka Kuure, and Atsushi Sato 501 for reviewing this document and providing helpful comments. 503 11. References 505 11.1. Normative References 507 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 508 Levels", BCP 14, RFC 2119, March 1997. 510 [2] Troost, R., Dorner, S., and K. Moore, "Communicating 511 Presentation Information in Internet Messages: The Content- 512 Disposition Header Field", RFC 2183, August 1997. 514 [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 515 RFC 2246, January 1999. 517 [4] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., 518 Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG 519 Objects", RFC 3204, December 2001. 521 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 522 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 523 Session Initiation Protocol", RFC 3261, June 2002. 525 [6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 526 January 2004. 528 [7] Rosenberg, J., "Extensible Markup Language (XML) Formats for 529 Representing Resource Lists", 530 draft-ietf-simple-xcap-list-usage-05 (work in progress), 531 February 2005. 533 [8] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 534 (S/MIME) Version 3.1 Message Specification", RFC 3851, 535 July 2004. 537 [9] Camarillo, G. and A. Roach, "Framework and Security 538 Considerations for Session Initiation Protocol (SIP) Uniform 539 Resource Identifier (URI)-List Services", 540 draft-ietf-sipping-uri-services-05 (work in progress), 541 January 2006. 543 11.2. Informational References 545 [10] Camarillo, G. and A. Johnston, "Conference Establishment Using 546 Request-Contained Lists in the Session Initiation Protocol 547 (SIP)", draft-ietf-sipping-uri-list-conferencing-05 (work in 548 progress), February 2006. 550 [11] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE 551 Requests in the Session Initiation Protocol (SIP)", 552 draft-ietf-sipping-uri-list-message-08 (work in progress), 553 September 2006. 555 Authors' Addresses 557 Miguel A. Garcia-Martin 558 Nokia 559 P.O.Box 407 560 NOKIA GROUP, FIN 00045 561 Finland 563 Email: miguel.an.garcia@nokia.com 565 Gonzalo Camarillo 566 Ericsson 567 Hirsalantie 11 568 Jorvas 02420 569 Finland 571 Email: Gonzalo.Camarillo@ericsson.com 573 Full Copyright Statement 575 Copyright (C) The Internet Society (2006). 577 This document is subject to the rights, licenses and restrictions 578 contained in BCP 78, and except as set forth therein, the authors 579 retain all their rights. 581 This document and the information contained herein are provided on an 582 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 583 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 584 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 585 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 586 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 587 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 589 Intellectual Property 591 The IETF takes no position regarding the validity or scope of any 592 Intellectual Property Rights or other rights that might be claimed to 593 pertain to the implementation or use of the technology described in 594 this document or the extent to which any license under such rights 595 might or might not be available; nor does it represent that it has 596 made any independent effort to identify any such rights. Information 597 on the procedures with respect to rights in RFC documents can be 598 found in BCP 78 and BCP 79. 600 Copies of IPR disclosures made to the IETF Secretariat and any 601 assurances of licenses to be made available, or the result of an 602 attempt made to obtain a general license or permission for the use of 603 such proprietary rights by implementers or users of this 604 specification can be obtained from the IETF on-line IPR repository at 605 http://www.ietf.org/ipr. 607 The IETF invites any interested party to bring to its attention any 608 copyrights, patents or patent applications, or other proprietary 609 rights that may cover technology that may be required to implement 610 this standard. Please address the information to the IETF at 611 ietf-ipr@ietf.org. 613 Acknowledgment 615 Funding for the RFC Editor function is provided by the IETF 616 Administrative Support Activity (IASA).