idnits 2.17.1 draft-ietf-sipping-multiple-refer-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 545. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 556. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 563. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 569. ** 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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The REFER-Recipient SHOULD not create an implicit subscription, and SHOULD add a Refer-Sub header field set to "false" in the 200 OK response. -- 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 22, 2006) is 6519 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) == Outdated reference: A later version (-07) exists of draft-ietf-sipping-uri-services-05 == Outdated reference: A later version (-07) exists of draft-ietf-sipping-capacity-attribute-00 == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-07 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group G. Camarillo 3 Internet-Draft Ericsson 4 Intended status: Standards Track A. Niemi 5 Expires: December 24, 2006 M. Isomaki 6 M. Garcia-Martin 7 Nokia 8 H. Khartabil 9 Telio 10 June 22, 2006 12 Refering to Multiple Resources in the Session Initiation Protocol (SIP) 13 draft-ietf-sipping-multiple-refer-06.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on December 24, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This document defines extensions to the SIP REFER method so that this 47 method can be used to refer servers to multiple resources. These 48 extensions include the use of pointers to Uniform Resource Identifier 49 (URI)-lists in the Refer-To header field and the "multiple-refer" SIP 50 option-tag. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Overview of operation . . . . . . . . . . . . . . . . . . . . 3 57 4. The multiple-refer SIP Option-Tag . . . . . . . . . . . . . . 4 58 5. Suppressing REFER's Implicit Subscription . . . . . . . . . . 4 59 6. URI-List Format . . . . . . . . . . . . . . . . . . . . . . . 5 60 7. Behavior of SIP REFER-Issuers . . . . . . . . . . . . . . . . 7 61 8. Behavior of REFER-Recipients . . . . . . . . . . . . . . . . . 7 62 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 65 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 67 12.2. Informational References . . . . . . . . . . . . . . . . 11 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 69 Intellectual Property and Copyright Statements . . . . . . . . . . 14 71 1. Introduction 73 The SIP [5] REFER method [7] allows a user agent to request a server 74 to send a request to a third party. Still, a number of applications 75 need to request a server to initiate transactions towards a set of 76 destinations. In one example, the moderator of a conference may want 77 the conference server to send BYE requests to a group of 78 participants. In another example, the same moderator may want the 79 conference server to INVITE a set of new participants. 81 We define an extension to REFER so that REFER can be used to refer 82 servers to multiple destinations. In addition, this mechanism uses 83 the suppression of the REFER method implicit subscription specified 84 in RFC 4488 [8] to suppress REFER's implicit subscription. 86 2. Terminology 88 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 89 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 90 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 91 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 92 compliant implementations. 94 We define the following three new terms: 96 REFER-Issuer: the user agent issuing the REFER request. 97 REFER-Recipient: the user agent receiving the REFER request. 98 REFER-Target: the intended final recipient of the request to be 99 generated by the REFER-Recipient. 101 3. Overview of operation 103 This document defines an extension to the SIP REFER method [7] that 104 allows a SIP User Agent Client (UAC) to include a URI-list [9] of 105 REFER-Targets in a REFER request and send it to a server. The server 106 will create a new request for each entry in the list of REFER-Target 107 URIs. 109 The URI-list of REFER-Targets is used in conjunction with the 110 capacity attribute extension [11] to allow the sender indicate the 111 capacity (e.g., 'to', 'cc', or anonymous) in which the REFER-Target 112 is involved in the signalling. 114 We represent the multiple REFER-Targets of a REFER using a URI-list 115 [9]. A UAC (User Agent Client) that wants to refer a server to a set 116 of destinations creates a SIP REFER request. The Refer-To header 117 contains a pointer to a URI-list, which is included in a body part, 118 and an option-tag in the Required header field: "multiple-refer". 119 This option-tag indicates the requirement to support the 120 functionality described in this specification. 122 When the server receives such request it creates a new request per 123 destination and sends them. 125 This document does not provide any mechanism for UACs to find out 126 about the results of a REFER with multiple REFER-Targets. 127 Furthermore, it does not provide support for the implicit 128 subscription mechanism that is part of the SIP REFER method. The way 129 UACs are kept informed about the results of a REFER is service 130 specific. For example, a UAC sending a REFER to INVITE a set of 131 participants to a conference may discover which participants were 132 successfully brought into the conference by subscribing to the 133 conference state event [13]. 135 4. The multiple-refer SIP Option-Tag 137 We define a new SIP option-tag for the Require and Supported header 138 fields: "multiple-refer". 140 A user agent including the "multiple-refer" option-tag in a Supported 141 header field indicates compliance with this specification. 143 A user agent generating a REFER with a pointer to a URI-list in its 144 Refer-To header field MUST include the "multiple-refer" option-tag in 145 the Require header field of the REFER. 147 5. Suppressing REFER's Implicit Subscription 149 REFER requests with a single REFER-Target establish implicitly a 150 subscription to the refer event. The REFER-Issuer is informed about 151 the result of the transaction towards the REFER-Target through this 152 implicit subscription. As described in RFC 3515 [7], NOTIFY requests 153 sent as a result of an implicit subscription created by a REFER 154 request contain a body of type "message/sipfrag" [6] that describes 155 the status of the transaction initiated by the REFER-Recipient. 157 In the case of a REFER-Issuer that generates a REFER with multiple 158 REFER-targets, the REFER-Issuer is typically already subscribed to 159 other event package that can provide the information about the result 160 of the transactions towards the REFER-Targets. For example, a 161 moderator instructing a conference server to send a BYE request to a 162 set of participants is usually subscribed to the conference state 163 event package for the conference. Notifications to this event 164 package will keep the moderator and the rest of the subscribers 165 informed of the current list of conference participants. 167 Most of the applications using multiple REFER do not need its 168 implicit subscription. Consequently, a SIP REFER-Issuer generating a 169 REFER request with multiple REFER-Targets SHOULD include the 170 "norefersub" option-tag in a Require header field and SHOULD include 171 a Refer-Sub header field set to "false" to indicate that no 172 notifications about the requests should be sent to the REFER-Issuer. 173 The REFER-Recipient SHOULD honor the suggestion and also include a 174 Refer-Sub header field set to "false" in the 200 OK response. The 175 "norefersub" SIP option-tag and the Refer-Sub header field are 176 specified in RFC 4488 [8]. 178 RFC 4488 [8] indicates that a condition for the REFER-Issuer to 179 include a Refer-Sub header is that the REFER-Issue is sure that 180 the REFER request will not fork. 182 At the time of writing, there is no extension that allows to report 183 the status of several transactions over a REFER's implicit 184 subscription. That is the motivation for this document to recommend 185 the usage of the "norefersub" option-tag. If in the future such an 186 extension is defined, REFER-Issuers using it could refrain from using 187 the "norefersub" option-tag and use the new extension instead. 189 6. URI-List Format 191 As described in the Framework and Security Considerations for SIP 192 URI-List Services [10], specifications of individual URI-list 193 services, need to specify a default format for 'recipient-list' 194 bodies used within the particular service. 196 The default format for 'recipient-list' bodies for conferencing UAs 197 (User Agents) and servers is the XML resource list format [9] 198 extended with the XML Format Extension for Representing Capacity 199 Attributes in Resource Lists [11]. UAs handling 'recipient-list' 200 bodies MUST support both of these formats and MAY support other 201 formats. 203 As described in the XML Format Extension for Representing Capacity 204 Attributes in Resource Lists [11], each URI can be tagged with a 205 'capacity' attribute set to either "to", "cc", or "bcc", indicating 206 the capacity or role in which the recipient will get the referred SIP 207 request. However, it must be noted that, depending on the target SIP 208 method, a 'capacity' attribute may not have sense. For example, 209 while a 'capacity' attribute can be applied to INVITE requests, it 210 may not make sense with mid-dialog requests such as BYE requests. 212 In addition to the 'capacity' attribute, URIs can be tagged with the 213 'anonymize' attribute, also specified in the XML Format Extension for 214 Representing Capacity Attributes in Resource Lists [11] to prevent 215 that the server discloses the target URI in a URI-list. 217 Additionally, the XML Format Extension for Representing Capacity 218 Attributes in Resource Lists [11] defines a 'recipient-list-history' 219 body that contains the list of recipients. The default format for 220 'recipient-list-history' bodies for conference services is also the 221 XML resource list document format [7] extended with the XML Format 222 Extension for Representing Capacity Attributes in Resource Lists [8]. 223 Conferencing servers MUST support both of these formats; UASes MAY 224 support these formats. Both conferencing servers and UASes MAY 225 support other formats. 227 Nevertheless, the XML resource list document [9] provides features, 228 such as hierarchical lists and the ability to include entries by 229 reference relative to the XCAP root URI, that are not needed by the 230 multiplet REFER service defined in this document. Therefore, when 231 using the default resource list document, SIP REFER-Issuers 232 generating REFERs with multiple REFER-Targets SHOULD use flat lists 233 (i.e., no hierarchical lists) and SHOULD NOT use %lt;entry-ref> 234 elements. 236 A REFER-Recipient receiving a URI-list with more information than 237 what has just been described MAY discard all the extra information. 239 Figure 1 shows an example of a flat list that follows the resource 240 list document. 242 243 246 247 248 249 250 251 253 Figure 1: URI List 255 7. Behavior of SIP REFER-Issuers 257 As indicated in Section 4 and Section 5 a SIP REFER-Issuer that 258 creates a REFER request with multiple REFER-Targets includes a 259 "multiple-refer" and "norefersub" option-tags in the Require header 260 field and, if appropriate, a Refer-Sub header field set to "false". 261 The REFER-Issuer includes the set of REFER-Targets in body whose 262 disposition type is 'recipient-list', as defined in the Framework and 263 Security Considerations for SIP URI-List Services [10]. The URI-list 264 body is further described in Section 6. 266 The Refer-To header field of a REFER request with multiple REFER- 267 Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource 268 Locator (URL) [3] ) that points to the body part that carries the 269 URI-list. The REFER-Issuer SHOULD NOT include any particular URI 270 more than once in the URI-list. 272 8. Behavior of REFER-Recipients 274 The REFER-Recipient follows the rules in Section 2.4.2 of RFC 3515 275 [7] to determine the status code of the response to the REFER. 277 The REFER-Recipient SHOULD not create an implicit subscription, and 278 SHOULD add a Refer-Sub header field set to "false" in the 200 OK 279 response. 281 If the URI-list of the REFER request contains a repeated URI, the 282 REFER-Recipient MUST behave as if that URI appeared in the URI-list 283 only once. The REFER-Recipient uses the comparison rules specific to 284 the URI scheme of each of the URIs in the URI-list to determine if 285 there is any URI which appears more than once. 287 The incoming REFER request typically contains a URI-list document or 288 reference with the actual list of recipients. If this URI-list 289 includes resources tagged with the 'capacity' attribute set to a 290 value of "to" or "cc", and if appropriate for the service, e.g., if 291 it is non-mid dialog request, the URI-list server SHOULD include a 292 URI-list in each of the outgoing requests. This list SHOULD be 293 formatted according to the XML format for representing resource lists 294 [9] and the capacity extension [11]. The URI-list server MUST follow 295 the procedures specified in XML format for representing resource 296 lists [9] with respect handling of the 'anonymize', 'count' and 297 'capacity' attributes. 299 If the server includes a URI-list in an outgoing request, it MUST 300 include a Content-Disposition header field [2] with the value set to 301 'recipient-list-history' and a 'handling' parameter [4] set to 302 "optional". 304 The REFER-Recipient follows the rules in RFC 3515 [7] to generate the 305 necessary requests towards the REFER-Targets, acting as if it had 306 received a regular (no URI-list) REFER per each URI in the URI-list. 308 9. Example 310 Figure 2 shows an example flow where a REFER-Issuer sends a multiple- 311 REFER request to the focus of a conference, which acts as the REFER- 312 Recipient. The REFER-Recipient generates a BYE request per REFER- 313 Target. (How to use REFER to remove participants from a conference 314 is specified in [14].) 316 +--------+ +---------+ +--------+ +--------+ +--------+ 317 | REFER | | REFER | | REFER | | REFER | | REFER | 318 | issuer | |recipient| |target 1| |target 2| |target 3| 319 +--------+ +---------+ +--------+ +--------+ +--------+ 320 | 1. REFER | | | | 321 | ---------------->| | | | 322 | 2. 202 Accepted | | | | 323 |<---------------- | 3. BYE | | | 324 | | ----------->| | | 325 | | 4. BYE | | | 326 | | ----------------------->| | 327 | | 5. BYE | | | 328 | | ----------------------------------->| 329 | | 6. 200 OK | | | 330 | |<----------- | | | 331 | | 7. 200 OK | | | 332 | |<----------------------- | | 333 | | 8. 200K OK| | | 334 | |<----------------------------------- | 335 | | | | | 336 | | | | | 337 | | | | | 339 Figure 2: Example flow or a REFER request containin multiple REFER- 340 Targets 342 The REFER request (1) contains a Refer-To header field that includes 343 a pointer to the message body, which carries a list with the URIs of 344 the REFER-Targets. In this example, the URI-list does not contain 345 the capacity attribute extension. The REFER's Require header field 346 carries the "multiple-refer" and "norefersub" option-tags. The 347 Request-URI is set to a Globally Routable User Agent URIs (GRUU) [12] 348 (as a guarantee that the REFER request will not fork). The Refer-Sub 349 header field is set to "false" to request the suppression of the 350 implicit subscription. Figure 3 shows an example of this REFER 351 request. The resource list document contains the list of REFER- 352 Target URIs along with the method of the SIP request that the REFER- 353 Recipient generates. 355 REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0 356 Via: SIP/2.0/TCP client.chicago.example.com 357 ;branch=z9hG4bKhjhs8ass83 358 Max-Forwards: 70 359 To: "Conference 123" 360 From: Carol ;tag=32331 361 Call-ID: d432fa84b4c76e66710 362 CSeq: 2 REFER 363 Contact: 364 Refer-To: 365 Refer-Sub: false 366 Require: multiple-refer, norefersub 367 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY 368 Allow-Events: dialog 369 Accept: application/sdp, message/sipfrag 370 Content-Type: application/resource-lists+xml 371 Content-Disposition: recipient-list 372 Content-Length: 362 373 Content-ID: 375 376 378 379 380 381 382 383 385 Figure 3: REFER request with multiple REFER-Targets 387 Figure 4 shows an example of the BYE request (3) that the REFER- 388 Recipient sends to the first REFER-Target. 390 BYE sip:bill@example.com SIP/2.0 391 Via: SIP/2.0/TCP conference.example.com 392 ;branch=z9hG4bKhjhs8assmm 393 Max-Forwards: 70 394 From: "Conference 123" ;tag=88734 395 To: ;tag=29872 396 Call-ID: d432fa84b4c34098s812 397 CSeq: 34 BYE 398 Content-Length: 0 400 Figure 4: BYE request 402 10. Security Considerations 404 The Framework and Security Considerations for SIP URI-List Services 405 [10] discusses issues related to SIP URI-list services. Given that a 406 server accepting REFERs with multiple REFER-targets acts as an URI- 407 list service, implementations of this type of server MUST follow the 408 security-related rules in [10]. These rules include mandatory 409 authentication and authorization of clients, and opt-in lists. 411 Additionally, servers SHOULD only accept REFER requests within the 412 context of an application the server understands (e.g., a 413 conferencing application). This implies that servers MUST NOT accept 414 REFERs for methods they do not understand. The idea behind these two 415 rules is that servers are not used as dumb servers whose only 416 function is to fan-out random messages they do not understand. 418 11. IANA Considerations 420 This document defines a new SIP option-tag: "multiple-refer". This 421 option-tag should be registered in the SIP Parameters registry. 423 SIP user agents that place the "multiple-refer" option-tag in a 424 Supported header field understand REFER requests that contain 425 resource list document describing multiple REFER-Targets. 427 12. References 429 12.1. Normative References 431 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 432 Levels", BCP 14, RFC 2119, March 1997. 434 [2] Troost, R., Dorner, S., and K. Moore, "Communicating 435 Presentation Information in Internet Messages: The Content- 436 Disposition Header Field", RFC 2183, August 1997. 438 [3] Levinson, E., "Content-ID and Message-ID Uniform Resource 439 Locators", RFC 2392, August 1998. 441 [4] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., 442 Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG 443 Objects", RFC 3204, December 2001. 445 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 446 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 447 Session Initiation Protocol", RFC 3261, June 2002. 449 [6] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, 450 November 2002. 452 [7] Sparks, R., "The Session Initiation Protocol (SIP) Refer 453 Method", RFC 3515, April 2003. 455 [8] Levin, O., "Suppression of Session Initiation Protocol (SIP) 456 REFER Method Implicit Subscription", RFC 4488, May 2006. 458 [9] Rosenberg, J., "Extensible Markup Language (XML) Formats for 459 Representing Resource Lists", 460 draft-ietf-simple-xcap-list-usage-05 (work in progress), 461 February 2005. 463 [10] Camarillo, G. and A. Roach, "Framework and Security 464 Considerations for Session Initiation Protocol (SIP) Uniform 465 Resource Identifier (URI)-List Services", 466 draft-ietf-sipping-uri-services-05 (work in progress), 467 January 2006. 469 [11] Garcia-Martin, M. and G. Camarillo, "Extensible Markup Language 470 (XML) Format Extension for Representing Capacity Attributes in 471 Resource Lists", draft-ietf-sipping-capacity-attribute-00 (work 472 in progress), February 2006. 474 [12] Rosenberg, J., "Obtaining and Using Globally Routable User 475 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 476 (SIP)", draft-ietf-sip-gruu-07 (work in progress), May 2006. 478 12.2. Informational References 480 [13] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 481 Package for Conference State", 482 draft-ietf-sipping-conference-package-12 (work in progress), 483 July 2005. 485 [14] Levin, O., "Session Initiation Protocol Call Control - 486 Conferencing for User Agents", 487 draft-ietf-sipping-cc-conferencing-07 (work in progress), 488 June 2005. 490 Authors' Addresses 492 Gonzalo Camarillo 493 Ericsson 494 Hirsalantie 11 495 Jorvas 02420 496 Finland 498 Email: Gonzalo.Camarillo@ericsson.com 500 Aki Niemi 501 Nokia 502 P.O. Box 321 503 NOKIA GROUP, FIN 00045 504 Finland 506 Email: Aki.Niemi@nokia.com 508 Markus Isomaki 509 Nokia 510 Itamerenkatu 11-13 511 Helsinki 00180 512 Finland 514 Email: Markus.Isomaki@nokia.com 516 Miguel A. Garcia-Martin 517 Nokia 518 P.O.Box 407 519 NOKIA GROUP, FIN 00045 520 Finland 522 Email: miguel.an.garcia@nokia.com 523 Hisham Khartabil 524 Telio 525 P.O. Box 1203 526 Oslo 0110 527 Norway 529 Email: Hisham.Khartabil@telio.no 531 Full Copyright Statement 533 Copyright (C) The Internet Society (2006). 535 This document is subject to the rights, licenses and restrictions 536 contained in BCP 78, and except as set forth therein, the authors 537 retain all their rights. 539 This document and the information contained herein are provided on an 540 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 541 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 542 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 543 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 544 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 545 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 547 Intellectual Property 549 The IETF takes no position regarding the validity or scope of any 550 Intellectual Property Rights or other rights that might be claimed to 551 pertain to the implementation or use of the technology described in 552 this document or the extent to which any license under such rights 553 might or might not be available; nor does it represent that it has 554 made any independent effort to identify any such rights. Information 555 on the procedures with respect to rights in RFC documents can be 556 found in BCP 78 and BCP 79. 558 Copies of IPR disclosures made to the IETF Secretariat and any 559 assurances of licenses to be made available, or the result of an 560 attempt made to obtain a general license or permission for the use of 561 such proprietary rights by implementers or users of this 562 specification can be obtained from the IETF on-line IPR repository at 563 http://www.ietf.org/ipr. 565 The IETF invites any interested party to bring to its attention any 566 copyrights, patents or patent applications, or other proprietary 567 rights that may cover technology that may be required to implement 568 this standard. Please address the information to the IETF at 569 ietf-ipr@ietf.org. 571 Acknowledgment 573 Funding for the RFC Editor function is provided by the IETF 574 Administrative Support Activity (IASA).