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