idnits 2.17.1 draft-ietf-sip-xcap-config-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 539. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 516. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 523. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 529. ** 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 == Line 451 has weird spacing: '... Change in XM...' == 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 (October 14, 2006) is 6375 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) == Missing Reference: 'RFCXXXX' is mentioned on line 395, but not defined == Unused Reference: 'I-D.ietf-sip-content-indirect-mech' is defined on line 462, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'I-D.dpetrie-sip-event-param-err' == Outdated reference: A later version (-12) exists of draft-ietf-simple-xcap-11 == Outdated reference: A later version (-14) exists of draft-ietf-simple-xcap-diff-03 == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-09 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP D. Petrie 3 Internet-Draft SIPez LLC. 4 Expires: April 17, 2007 October 14, 2006 6 Extensions to the Session Initiation Protocol (SIP) User Agent Profile 7 Delivery Change Notification Event Package for the Extensible Markup 8 Language Language Configuration Access Protocol (XCAP) 9 draft-ietf-sip-xcap-config-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 17, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 The SIP User Agent profile delivery framework describes how a User 43 Agent can retrieve its data using a variety of protocols and defines 44 a SIP event package for notifications of changes to those profiles. 45 This document extends that event package to support XCAP (XML 46 Configuration Access Protocol). 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3 52 3. New Event Package Parameters . . . . . . . . . . . . . . . . . 3 53 4. Relationship of XCAP with the Data Model . . . . . . . . . . . 6 54 5. Example Usage . . . . . . . . . . . . . . . . . . . . . . . . 7 55 6. Use of the XCAP Diff Format with ua-profile Event Package . . 8 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 57 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 58 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 59 10. Change History . . . . . . . . . . . . . . . . . . . . . . . . 10 60 10.1. Changes from draft-ietf-sipping-xcap-config-00.txt . . . 10 61 11. Normative References . . . . . . . . . . . . . . . . . . . . . 11 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 63 Intellectual Property and Copyright Statements . . . . . . . . . . 14 65 1. Introduction 67 The SIP [RFC3261] User Agent profile delivery framework [I-D.ietf- 68 sipping-config-framework] describes how a User Agent (UA) can 69 retrieve its data using a variety of protocols. The framework also 70 defines a SIP event package [RFC3265] for notifications of changes to 71 those profiles. This document extends that event package to support 72 XCAP (XML Configuration Access Protocol) [I-D.ietf-simple-xcap]. 74 XCAP is a usage of HTTP (HyperText Transfer Protocol) [RFC2616] which 75 defines structure of the HTTP URI (Uniform Resource Identifier) to 76 represent a specific document hierarchy. XCAP URIs consist of the 77 document root, the Application Unique ID (AUID), the XCAP User 78 Identifier (XUI), plus additional optional elements for selecting XML 79 nodes within an XML document. The mandatory components point to a 80 specific XCAP document. For example: 82 http://xcap.example.com/root/resource-lists/users/joe 83 |-------------v-------------||------v------||---v---| 84 document root AUID XUI 86 This document extends the UA profile change event package with two 87 new Event header parameters. These allow a UA to subscribe to change 88 notification for a specific XCAP AUID or document. 90 2. Requirements Terminology 92 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 93 "MAY" that appear in this document are to be interpreted as described 94 in [RFC2119]. 96 3. New Event Package Parameters 98 This document extends the event package defined in Section 7 of 99 [I-D.ietf-sipping-config-framework] with the following two new 100 parameters for the Event header: "document" and "auid" and a new 101 profile type: "application" for the "profile-type" parameter. These 102 new parameters are for use in both SUBSCRIBE and NOTIFY requests. 103 The motivation for these new parameters is in support of XCAP, but 104 they may be used with other suitable protocols. 106 The "document" parameter is used to specify a relative URI for a 107 specific profile document that the user agent wishes to retrieve and 108 for which it wishes to receive change notification. It can be used 109 with any of the profile-types. The document parameter is useful for 110 profile content like XCAP [I-D.ietf-simple-xcap] where there is a 111 well defined URI schema and the user agent knows the specific content 112 that it wants. This provides a filtering mechanism to restrict the 113 content to be retrieved and for which change notification is to be 114 received. (The size of the content is important in limited bandwidth 115 environments.) The "document" parameter value syntax is a quoted 116 string. The values for the "document" parameter are defined as part 117 of the profile data format, which is out of scope for this document. 118 To use the "document" parameter, the profile data format, must also 119 define a URI path schema. For more details on the use of this 120 package and the "document" parameter with XCAP see Section 4. The 121 "document" parameter MAY be set in SUBSCRIBE requests for any of the 122 profile types. It is ignored in all other messages. In the 123 following ABNF EQUAL and quoted-string are defined in [RFC3261]. 125 Document = "document" EQUAL quoted-string 127 The "auid" parameter MAY be set when the "profile-type" parameter 128 value is "application". The "auid" indicates that the user agent 129 wishes to retrieve the profile data or URI and change notification 130 for the application profile data for the specific application 131 indicated in the value of the "auid" parameter. Like the "document" 132 parameter, the "auid" parameter provides a filtering mechanism on the 133 profile content. The "auid" parameter value is a quoted string. The 134 values for the "auid" parameter are defined as part of the profile 135 data format to be used with XCAP (see [I-D.ietf-simple-xcap] ), which 136 is out of scope for this document. The "auid" parameter has meaning 137 only in SUBSCRIBE requests when the "profile-type" Event header 138 parameter is set to "application". When used with XCAP it is not 139 necessary to set both the "document" and "auid" parameters in a 140 SUBSCRIBE request as the document path will also include the 141 application auid. The "auid" parameter is ignored if it conflicts 142 with the parameter "document" path. The "auid" parameter is ignored 143 in all other messages. 145 AUID = "auid" EQUAL quoted-string 147 The profile-type Event header parameter is extended to have the 148 additional profile type "application". Specifying "application" type 149 profile indicates the desire for the profile data (URI when content 150 indirection is used) and change notification of the profile content 151 for the user's applications. Specifying the "application" type 152 profile also implies the use of XCAP. If the profile-type is 153 "application" in the SUBSCRIBE request and the profile delivery 154 server does not support XCAP, a 439 Invalid Event Parameter Value 155 MUST be sent and profile-type=application MUST be added to the 156 Invalid-Parameters-Values response header field as described in 157 [I-D.dpetrie-sip-event-param-err]. The SUBSCRIBE request URI SHOULD 158 be discovered and constructed in the same way the "user" type 159 profiles described in Section 7 of [I-D.ietf-sipping-config- 160 framework]. 162 profile-types = "device" / "user" / "application" / "local-network" 164 The following is a SUBSCRIBE request Event header example: 165 Event: ua-profile;profile-type="application"; 166 document="user-aor/"; 167 vendor="premier";model="trs8000";version="5.5" 169 The following table shows the use of Event header parameters in 170 SUBSCRIBE requests for the four profile types: 172 profile-type || device | user | application | local-network 173 =========================================================== 174 vendor || m | m | m | m 175 model || m | m | m | m 176 version || m | m | m | m 177 network-user || s | | | s 178 effective-by || | | | 179 document || | | o | 180 auid || | | o | 182 m - mandatory 183 s - SHOULD be provided 184 o - optional 185 Non-specified means that the parameter has no meaning and 186 should be ignored. 188 The following table shows the use of Event header parameters in 189 NOTIFY requests for the four profile types: 191 profile-type || device | user | application | local-network 192 =========================================================== 193 vendor || | | | 194 model || | | | 195 version || | | | 196 network-user || s | | | s 197 effective-by || o | o | o | o 198 document || | | o/m | 199 auid || | | o/m | 201 o/m - mandatory if provided in the SUBSCRIBE request 203 4. Relationship of XCAP with the Data Model 205 The UA profile delivery framework [I-D.ietf-sipping-config-framework] 206 describes a rough data model with profile types that can correspond 207 to profile information related to the local-network, devices, users, 208 and applications. XCAP MAY be used as the profile delivery and 209 management mechanism for the UA profile delivery framework. Because 210 XCAP defines a specific hierarchy for how documents are organized, it 211 is necessary to discuss how that organization relates to the data 212 model described in the profile delivery framework. 214 When a user or device enrolls with a SUBSCRIBE request, the request 215 URI will contain identifying information for that user or device. 216 This identity is mapped to an XCAP User ID (XUID) based on an 217 implementation specific mapping. The "profile-type" along with the 218 "auid" Event header parameters specify the specific XCAP application 219 usage. 221 In particular, when the Event header parameter "profile-type" is 222 "application", the "auid" MAY be included to contain the XCAP 223 Application Unique ID (AUID). When the "profile-type" is 224 "application", but the "auid" parameter is absent, this specifies 225 that the user wishes to SUBSCRIBE to all documents for all 226 application usages associated with the user in the request-uri. This 227 provides a convenient way for a single subscription to be used to 228 obtain all application data. The XCAP root is determined by a local 229 mapping. 231 The "profile-type", "document" and "auid" can be thought of as 232 filters for determining which profile(s) are desired. When the 233 profile-type is "application" and the "document" and "auid" 234 parameters are not present, the XCAP operation to perform is to 235 select all AUID in the home and global paths. When the "auid" and/or 236 "document" parameters are present, the operation is to further filter 237 the profiles by the "auid" and/or "document" parameter values for the 238 global and user scope. If the filtering operations result in no 239 profiles being selected, a 404 response SHOULD be sent to the 240 SUBSCRIBE request. 242 Furthermore, when the "document" attribute is present and used with 243 XCAP, it identifies a specific document that is being requested. The 244 "document" attribute specifies a relative path from the XCAP root 245 [I-D.ietf-simple-xcap]. That is the "document" attribute is an XCAP 246 Document Selector expressed as a relative path to the XCAP root. The 247 "document" attribute MUST refer to a whole document. 248 The "document" cannot refer to an XCAP query or path that results 249 in a partial document. The reason for this is that changes which 250 occur and get notified require the context of the full document to 251 be unambiguous. For example if the "document" path refered to an 252 element of an list, deleting the element from the list entirely is 253 indistiguishable from moving the order in which the element occurs 254 in the list. 256 5. Example Usage 258 For example, consider a phone with an instance ID of 259 urn:uuid:00000000-0000-0000-0000-0003968cf920. To obtain its device 260 profile, it generates a SUBSCRIBE that contains the following 261 Request-Line and Event header: (Note that line folding of the 262 Request-URI is illegal in SIP. The Request URI is shown broken 263 across the first 3-lines here only due to formatting limitations of 264 IETF documents.) 266 SUBSCRIBE 267 sip:urn%3auuid%3a00000000-0000-0000-0000-0003968cf920@example.com 268 SIP/2.0 269 Event: ua-profile;profile-type=device;Vendor="vendor2" 270 ;Model="1";Version="2.2.2" 272 If the profile data is stored in an XCAP server, the profile delivery 273 server maps the "device" profile to an application usage and document 274 selector based on local policy. The user ID, in the case of a device 275 profile, could be the device ID which is identified in the user part 276 of the SUBSCRIBE URI. Assume the XCAP server uses an XCAP root 277 directory of: http://xcap.example.com/root. Local policy provides a 278 mapping for the AUID "vendor2-device-data" based upon the "vendor" 279 parameter and a document called "index" within the user directory, 280 the corresponding HTTP URI for the document would be: (Note that this 281 URI is only one line; it is split across lines due to formatting 282 limitations of IETF documents.) 284 http://xcap.example.com/root/vendor2-device-data/ 285 urn%3auuid%3a00000000-0000-0000-0000-0003968cf920/index 287 The returned user profile would typically specify the user identity 288 (as a SIP AOR) and his or her application-usages. From that, the 289 device can enroll to learn about its application data. To learn 290 about all of the data, the UA sends a subscription with the 291 application profile-type and no AUID: 293 SUBSCRIBE sip:alice@example.com SIP/2.0 294 Event: ua-profile;profile-type=application;Vendor="vendor2"; 295 Model="1";Version="2.2.2" 297 The server maps the SIP Request URI to an XUI (alice, for example) 298 and the xcap root based on local policy. If there are two AUIDs, 299 "resource-lists" [I-D.ietf-simple-xcap-list-usage] and "rls-services" 300 [I-D.ietf-simple-xcap-list-usage], this would result in a 301 subscription to all documents within: 303 http://xcap.example.com/root/rls-services/alice 304 http://xcap.example.com/root/resource-lists/alice 306 The user would not be subscribed to the global data for these two 307 application usages, since that data is not important for users. 309 However, the user/device could be made aware that it needs to 310 subscribe to a specific document. In that case, its subscribe would 311 look like: 313 SUBSCRIBE sip:user-aor@example.com SIP/2.0 314 Event: ua-profile;profile-type=application;auid="resource-lists"; 315 Vendor="vendor2";Model="1";Version="2.2.2" 317 this would result in a subscription to the single global document for 318 resource-lists. 320 In some cases, these subscriptions are to a multiplicity of 321 documents. In that case, the notification format will need to be one 322 which can indicate what document has changed. This includes content 323 indirection, but also the xcap diff format [I-D.ietf-simple-xcap- 324 diff]. 326 6. Use of the XCAP Diff Format with ua-profile Event Package 328 The XCAP diff format [I-D.ietf-simple-xcap-diff] is meant to be used 329 with an event package for the purposes of indicating changes in a 330 document. This section provides guidelines for its usage with the 331 us-profile or any event package defined for that purpose. 333 Upon receipt of an initial SUBSCRIBE request, the client may have a 334 cached version of some documents. However, the server does not know 335 which instances of each document (where each instance is identified 336 by an etag) the client currently posessses, if any. Indeed, upon 337 initial startup, the client will not have any documents. The initial 338 NOTIFY in this case MUST include a element for each 339 document associated with the subscription. The "previous-etag" 340 attribute MUST be absent, and the "new-etag" attribute MUST be 341 present and contain the entity tag for the current version of that 342 document resource. An XCAP diff document structured this way is 343 called a "reference" XCAP diff document. It establishes the baseline 344 etags and document URIs for the documents covered by the 345 subscription. 347 Upon receipt of this document, the client can determine whether its 348 local instance documents, if any, match the etags in the XCAP diff 349 document. If they do not match, the client SHOULD perform a 350 conditional GET for each document. The document URI is constructed 351 by appending the XCAP root in the "xcap-root" attribute of the element to the escape coded "doc-selector" from each 353 element. The request is made conditional by including an If-Match 354 header field, with the value of the etag from each 355 element. So long as the documents haven't changed between the NOTIFY 356 and the GET, the client will obtain the reference versions that the 357 server will use for subsequent notifications. 359 If the conditional GET should fail, the client SHOULD wait for the 360 next NOTIFY and retry the conditional GET with the etag from the new 361 NOTIFY. 362 This is because the the document was changed between the time that 363 the NOTIFY was sent and the time that the GET was received. In 364 this situation there should be another NOTIFY, for the change that 365 occurred, with the newer etag that the client can use to try 366 again. 368 Once the client has obtained the versions of the documents identified 369 in the reference XML diff, it can process NOTIFY requests on that 370 subscription. To process the NOTIFY requests, it makes sure that its 371 current version matches the version in the "previous-etag" attribute 372 of the element. If not, the client can then fetch the 373 updated document from the server. If they do match, the client has 374 the most current version. 376 7. IANA Considerations 378 This specification registers two new Event header parameters and 379 updates the corresponding event package as defined in [RFC3265]. The 380 following information required for this registration: 382 Package Name: ua-profile 383 Published Document: RFC XXXX (Note to RFC Editor: Please fill in 384 XXXX with the RFC number of this specification). 385 Person to Contact: Daniel Petrie dan.ietf AT SIPez DOT com 386 Additional SIP Event header parameters: document, auid 387 The document and auid parameters do not have predefined values. 388 The following table illustrates the additions to the IANA SIP Header 389 Field Parameters and Parameter Values: 391 Predefined 392 Header Field Parameter Name Values Reference 393 ---------------------------- --------------- --------- --------- 394 Event document No [RFCXXXX] 395 Event auid No [RFCXXXX] 397 8. Security Considerations 399 Profiles may contain sensitive data such as user credentials and 400 personal information. The security considerations of this document 401 are identical to those of the framework [I-D.ietf-sipping-config- 402 framework]. Implementors should also carefully read the security 403 considerations of XCAP [I-D.ietf-simple-xcap] as well. 405 Subscribers implementing this specification MUST implement either 406 HTTP or HTTPS. Subscribers also MUST implement the hash verification 407 scheme described in SIP content indirection [I-D.ietf-sip-content- 408 indirect-mech]. SIP profile delivery servers MUST implement both 409 HTTP and HTTPS, and SHOULD implement a SIP Authentication Service as 410 described in the SIP Identity mechanism [I-D.ietf-sip-identity]. All 411 SIP entities are already required to implement SIP Digest 412 authentication [RFC3261]. 414 9. Acknowledgements 416 Thanks to Rohan Mahy for editorial work on this document. 418 10. Change History 420 [[RFC Editor: Please remove this entire section upon publication as 421 an RFC.]] 423 10.1. Changes from draft-ietf-sipping-xcap-config-00.txt 424 Clarified constraint that "document" path MUST refer to a whole 425 document. 426 Moved "application" profile type definition here from: 427 draft-ietf-sipping-config-framework-08. 428 Defined concept of filtering using Event header parameters. 429 Cleaned up IANA section. 430 Profile delivery server SHOULD send 438 Invalid Event Parameter 431 Value for profile-type=application if XCAP is not supported. Also 432 reference draft-petrie-sip-event-param-err. 433 Moved section on xcap-diff usage in an event package from xcap- 434 diff to this document. 436 11. Normative References 438 [I-D.dpetrie-sip-event-param-err] 439 Petrie, D., "Session Initiation Protocol Response Code for 440 Invalid Event Parameter Values", 441 draft-petrie-sip-event-param-err-00 (work in progress), 442 October 2006. 444 [I-D.ietf-simple-xcap] 445 Rosenberg, J., "The Extensible Markup Language (XML) 446 Configuration Access Protocol (XCAP)", 447 draft-ietf-simple-xcap-11 (work in progress), May 2006. 449 [I-D.ietf-simple-xcap-diff] 450 Rosenberg, J., "An Extensible Markup Language (XML) 451 Document Format for Indicating A Change in XML 452 Configuration Access Protocol (XCAP) Resources", 453 draft-ietf-simple-xcap-diff-03 (work in progress), 454 October 2006. 456 [I-D.ietf-simple-xcap-list-usage] 457 Rosenberg, J., "Extensible Markup Language (XML) Formats 458 for Representing Resource Lists", 459 draft-ietf-simple-xcap-list-usage-05 (work in progress), 460 February 2005. 462 [I-D.ietf-sip-content-indirect-mech] 463 Burger, E., "A Mechanism for Content Indirection in 464 Session Initiation Protocol (SIP) Messages", 465 draft-ietf-sip-content-indirect-mech-05 (work in 466 progress), October 2004. 468 [I-D.ietf-sip-identity] 469 Peterson, J. and C. Jennings, "Enhancements for 470 Authenticated Identity Management in the Session 471 Initiation Protocol (SIP)", draft-ietf-sip-identity-06 472 (work in progress), October 2005. 474 [I-D.ietf-sipping-config-framework] 475 Petrie, D., "A Framework for Session Initiation Protocol 476 User Agent Profile Delivery", 477 draft-ietf-sipping-config-framework-09 (work in progress), 478 October 2006. 480 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 481 Requirement Levels", BCP 14, RFC 2119, March 1997. 483 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 484 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 485 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 487 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 488 A., Peterson, J., Sparks, R., Handley, M., and E. 489 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 490 June 2002. 492 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 493 Event Notification", RFC 3265, June 2002. 495 Author's Address 497 Daniel Petrie 498 SIPez LLC. 499 34 Robbins Rd 500 Arlington, MA 02476 501 US 503 Phone: "+1 617 273 4000 504 Email: dan.ietf AT SIPez DOT com 505 URI: http://www.SIPez.com/index.html?id=xcap-config 507 Intellectual Property Statement 509 The IETF takes no position regarding the validity or scope of any 510 Intellectual Property Rights or other rights that might be claimed to 511 pertain to the implementation or use of the technology described in 512 this document or the extent to which any license under such rights 513 might or might not be available; nor does it represent that it has 514 made any independent effort to identify any such rights. Information 515 on the procedures with respect to rights in RFC documents can be 516 found in BCP 78 and BCP 79. 518 Copies of IPR disclosures made to the IETF Secretariat and any 519 assurances of licenses to be made available, or the result of an 520 attempt made to obtain a general license or permission for the use of 521 such proprietary rights by implementers or users of this 522 specification can be obtained from the IETF on-line IPR repository at 523 http://www.ietf.org/ipr. 525 The IETF invites any interested party to bring to its attention any 526 copyrights, patents or patent applications, or other proprietary 527 rights that may cover technology that may be required to implement 528 this standard. Please address the information to the IETF at 529 ietf-ipr@ietf.org. 531 Disclaimer of Validity 533 This document and the information contained herein are provided on an 534 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 535 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 536 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 537 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 538 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 539 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 541 Copyright Statement 543 Copyright (C) The Internet Society (2006). This document is subject 544 to the rights, licenses and restrictions contained in BCP 78, and 545 except as set forth therein, the authors retain all their rights. 547 Acknowledgment 549 Funding for the RFC Editor function is currently provided by the 550 Internet Society.