idnits 2.17.1 draft-dusseault-http-patch-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.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 548. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 525. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 532. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 538. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 112: '... body, and MUST NOT be reused to do ...' RFC 2119 keyword, line 156: '... Servers SHOULD support PATCH and th...' RFC 2119 keyword, line 167: '... MUST NOT create a new resource with...' RFC 2119 keyword, line 168: '... although it MAY (depending on the d...' RFC 2119 keyword, line 172: '... The server MUST always apply the en...' (22 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 510 has weird spacing: '...rted to using...' -- 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, 2004) is 7133 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: 'RFC3688' on line 378 ** Obsolete normative reference: RFC 2616 (ref. '1') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2518 (ref. '3') (Obsoleted by RFC 4918) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission L. Dusseault 3 Internet-Draft OSAF 4 Expires: April 14, 2005 October 14, 2004 6 Partial Document Changes (PATCH Method) for HTTP 7 draft-dusseault-http-patch-06 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 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 21 Internet-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 14, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 Several applications extending HTTP require a feature to do partial 43 resource modification. Existing HTTP functionality only allows a 44 complete replacement of a document. This proposal adds a new HTTP 45 method, PATCH, to modify an existing HTTP resource. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Delta Encodings . . . . . . . . . . . . . . . . . . . . . . . 5 51 3. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . 6 52 3.1 PATCH Method . . . . . . . . . . . . . . . . . . . . . . . 6 53 3.2 PATCH Response . . . . . . . . . . . . . . . . . . . . . . 7 54 3.2.1 Success Response . . . . . . . . . . . . . . . . . . . 7 55 3.2.2 Error handling . . . . . . . . . . . . . . . . . . . . 8 56 3.3 Advertising Support in OPTIONS . . . . . . . . . . . . . . 9 57 4. Interdependencies with other Standards . . . . . . . . . . . . 11 58 4.1 PATCH and Access Control (RFC3744) . . . . . . . . . . . . 11 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 62 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 63 7.2 Non-Normative References . . . . . . . . . . . . . . . . . . 14 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 65 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 66 B. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 67 B.1 Changes from -00 . . . . . . . . . . . . . . . . . . . . . 16 68 B.2 Changes from -01 . . . . . . . . . . . . . . . . . . . . . 16 69 B.3 Changes from -02 . . . . . . . . . . . . . . . . . . . . . 16 70 B.4 Changes from -03 . . . . . . . . . . . . . . . . . . . . . 16 71 B.5 Changes from -04 . . . . . . . . . . . . . . . . . . . . . 17 72 B.6 Changes from -05 . . . . . . . . . . . . . . . . . . . . . 17 73 C. Notes to RFC Editor . . . . . . . . . . . . . . . . . . . . . 18 74 Intellectual Property and Copyright Statements . . . . . . . . 19 76 1. Introduction 78 Three use cases initially motivated this proposal 80 1. WebDAV [3] is used by authoring applications to store and share 81 files on the internet. For example, Adobe Photoshop has a 82 Workgroup feature allowing the user to browse a repository and 83 save the file. Currently, Photoshop only publishes the file to 84 the repository rarely, because Photoshop files are typically 85 large and upload is slow. Worse, large uploads are more likely 86 to be interrupted. Although HTTP [1] provides byte range 87 downloads, it does not provide a mechanism for partial uploads. 88 2. DeltaV [4] extends WebDAV to do versioning. In versioning 89 environments, a large number of files may be updated with very 90 small changes. For example, a programmer may change the name of 91 a function used in a hundred source files. Versioning 92 applications typically send deltas or patches to the server to 93 modify these files, however DetaV does not yet have this 94 functionality. 95 3. The SIMPLE WG is devising a way to store and modify configuration 96 information. The biggest feature missing from HTTP is the 97 ability to modify information in a very lightweight manner, so 98 that the client that decides to change its presence state from 99 "free" to "busy" doesn't have to upload a large document. This 100 can be accomplished through changes to a HTTP resource as well. 102 Other working groups (like netconf) are also considering manipulating 103 large files using HTTP GET and PUT. Sometimes the files aren't that 104 large but the device is small or bandwidth is limited, as when phones 105 need to add a new contact to an address book file. This feature 106 would allow much more efficient changes to files. 108 This specification defines a new HTTP 1.1 method to apply a delta 109 encoding, or a "patch", to a HTTP resource. A new method is 110 necessary to improve interoperability and prevent errors. The PUT 111 method is already defined to overwrite a resource with a complete new 112 body, and MUST NOT be reused to do partial changes. Otherwise, 113 proxies and caches and even clients and servers may get confused as 114 to the result of the operation. 116 Note that byte ranges are already used in HTTP to do partial 117 downloads (GET method) as defined in RFC2616. However, they are not 118 defined for uploads, and there are some missing pieces for uploads. 119 For example, the HTTP specification does not define a particularly 120 informative error to send if the byte range in a PUT is invalid. 121 Byte ranges (or some other kind of range) could be made to work in 122 this specification but a more flexible mechanism (one that could also 123 encompass XML delta encodings) was desired, as well as a method that 124 would not confuse caching proxies. Reliable and tested delta 125 encodings already exist, and this specification takes advantage of 126 that existing work. 128 Some delta encodings for use in HTTP GET responses are defined in RFC 129 3229 [2]. That specification defines delta encodings for cache 130 updates, not for user write operations. It does mean that servers 131 can reuse delta encoding algorithms to support both that 132 specification and this proposal. 134 This specification defines the new method PATCH to alter a single 135 existing resource, in place, by applying a delta encoding. A patch 136 request body is modelled as a manipulation of an instance, where the 137 instance would have been the entire document had it been PUT to the 138 server, following the model of RFC3229 [2]. The operation is atomic. 139 Note that WebDAV MOVE and COPY requests, if supported by the HTTP 140 server, can be useful to independently rename or copy a whole 141 resource before applying PATCH to either the source or destination 142 URL to modify the contents. 144 2. Delta Encodings 146 A set of changes for a resource is itself a document, called a delta 147 encoding. The delta encoding is uniquely identified through a 148 instance manipulation as defined in RFC3229. Servers advertise 149 supported delta encodings for PATCH by advertising these algorithms, 150 and clients specify which one they're using by including the name in 151 the request. Not all instance-manipulations defined in the IANA 152 registry are delta encodings; as of October 2004, the instance 153 manipulations which are also delta encodings are vcdiff, diffe, and 154 gdiff. 156 Servers SHOULD support PATCH and the vcdiff delta encoding for all 157 authorable resources, that is all resources that support PUT. Some 158 requirements apply only to specific patch formats, and in this 159 specification those requirements are spelled out only for vcdiff. 161 3. Mechanisms 163 3.1 PATCH Method 165 The PATCH method requests that the request body (a delta encoding) be 166 applied to the resource identified by the Request-URI. The server 167 MUST NOT create a new resource with the contents of the request body, 168 although it MAY (depending on the delta encoding) apply the request 169 body to an empty entity to result in the content for the new 170 resource. 172 The server MUST always apply the entire patch atomically and never 173 provide (e.g. in response to a GET during this operation) a 174 partially-patched body. If the entire patch file cannot be 175 successfully applied then the server MUST fail the entire request, 176 applying none of the changes. See error handling section for details 177 on status codes and possible error conditions. 179 PATCH request bodies MUST NOT be cached. A cache MAY mark the 180 resource identified in the Request-URI as stale if it sees a 181 successful response to the PATCH request. 183 The PATCH request MUST have a body. It MUST include the IM header 184 with a single valid delta encoding. The PATCH request MAY include a 185 Content-Type header which is the content-type of the resource to 186 which the delta encoding is to be applied. The request body MUST be 187 in the delta encoding format specified in the IM header. 189 If the vcdiff format is used: 191 o The client MUST verify that it is applying the delta encoding to a 192 known entity. There are two reliable ways to do this. The first 193 way is to find out the resource ETag at the time the body is 194 downloaded, and use that Etag in the If-Match header on the PATCH 195 request to make sure the resource is still unchanged. The second 196 way to use WebDAV LOCK/UNLOCK to reserve the file (first LOCK, 197 then GET, then PATCH, then UNLOCK). Vcdiff collisions from 198 multiple users are more dangerous than PUT collisions, because a 199 vcdiff that is not operating from a known base point may corrupt 200 the resource. Therefore, if neither strong ETags nor LOCKS are 201 available from the server, the client MUST use If-Unmodified-Since 202 as a less-reliable safeguard. 203 o If the Request-URI does not identify an existing resource, the 204 server SHOULD (subject of course to access control and other 205 restrictions) create a resource with an empty body and apply the 206 vcdiff changes to that empty entity. A client SHOULD verify that 207 the URL is unmapped, as expected, with use of the "If-None-Match: 208 *" header. 210 o The Content-Type header specifies the client's intended 211 Content-Type for the resource being patched. Thus, if the server 212 creates a new resource it MUST assign this Content-Type, or assign 213 a generic one if the Content-Type header was not provided. If the 214 server modifies an existing resource, the server MUST change the 215 Content-Type if a new Content-Type was provided by the client; 216 otherwise the resource's Content-Type should remain unchanged. 218 Simple PATCH example 220 PATCH /file.txt HTTP/1.1 221 Host: www.example.com 222 Content-type: text/plain 223 IM: vcdiff 224 If-Match: "e0023aa4e" 225 Content-Length: 100 227 [vcdiff-bytes] 229 Figure 1 231 This example illustrates use of the vcdiff algorithm on an existing 232 text file. 234 3.2 PATCH Response 236 3.2.1 Success Response 238 A successful response with the 204 No Content status code implies 239 that no new resource was created. A successful response with the 201 240 Created status code informs the client that a new resource was 241 created. 243 The server SHOULD send the Content-MD5 header in responses to PATCH. 244 This allows the client to verify the success of the operation. 246 As with PUT, the PATCH method MUST change the resource's ETag if the 247 resulting entity is not identical to the original. If the server 248 supports strong ETags, the server MUST return a strong ETag for use 249 in future client operations. The server MUST return the 250 Last-Modified header if it does not support strong ETags. 252 Successful PATCH response to existing text file 254 HTTP/1.1 204 No Content 255 Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== 256 ETag: "e0023aa4e" 258 3.2.2 Error handling 260 This proposal uses the same mechanism as DeltaV (defined in section 261 1.6 of RFC3253) to add machine-parsable information to provide more 262 detail than HTTP status codes can. Existing HTTP status codes are 263 not infinitely extensible but XML elements and namespaces are more 264 so, and it's simple to treat the HTTP error code as a rough category 265 and put detailed error codes in the body. Clients that do not use 266 the extra information ignore the bodies of error responses. These 267 error codes are not meant to be displayed directly to end-users, so 268 there is no language code or other display information. Clients MUST 269 ignore any unrecognized elements within the XML response body because 270 extensions allow implementors to add custom debug information to the 271 response. 273 The PATCH method can return the following errors. All these errors 274 are represented as XML elements in an XML document, where the 275 specific error element appears inside a root element called "error" 276 in the "DAV:" namespace. The new elements defined in this 277 specification are all in the "urn:ietf:params:xml:ns:patch" 278 namespace. 280 delta-encoding-badly-formatted: Used with 400 Bad Request when the 281 server finds that the delta encoding provided by the client was 282 badly formatted or non-compliant. The definition of badly 283 formatted or non-compliant depends on the delta encoding chosen, 284 but generally if the server finds it can't handle the current 285 patch even though it supports the format used, this error ought to 286 be appropriate. 288 delta-encoding-unsupported: Used with 501 Unsupported when the client 289 sends a delta encoding that the server doesn't support on this 290 resource, or a delta encoding that the server never supports. 292 patch-empty-resource: Used with 409 Conflict when the resource 293 addressed in the Request-URI exists but is empty, and the delta 294 encoding cannot be applied to an empty document. Note that some 295 delta encodings may be applied to an empty document, in which case 296 this error wouldn't be used. 298 patch-result-invalid: Used with 409 Conflict when the resource could 299 be patched but the result of the patch would be a resource which 300 is invalid. This could mean, for example, that a XML resource 301 would become an invalid XML file if the patch specified that a 302 close element text line should be deleted. 304 "404 Not Found" can be used (with no body/error element) when the URL 305 in by the Request-URI does not map to a resource and the server 306 cannot apply the delta encoding to a new empty resource. 308 Other status codes defined in RFC2616 may also be used under the 309 appropriate circumstances, with no response body. For example, an 310 unauthenticated user may be prompted to authenticate, in order to use 311 PATCH, with "401 Unauthorized". An authenticated user who does not 312 have sufficient privilege to use PATCH may receive a "403 Forbidden" 313 response. 315 3.2.2.1 Example error response with body detail 317 HTTP/1.1 409 Conflict 318 Content-Type: text/xml; charset="utf-8" 319 Content-Length: xxx 321 322 323 325 327 3.3 Advertising Support in OPTIONS 329 The server advertises its support for the features described here 330 with OPTIONS response headers. The "Allow" OPTIONS header is already 331 defined in HTTP 1.1 to contain all the allowed methods on the 332 addressed resource, so the server MUST add PATCH if it is allowed. 334 Clients also need to know whether the server supports special patch 335 formats, so this document introduces a new OPTIONS response header 336 "Accept-Patch". "Accept-Patch" MUST appear in the OPTIONS response 337 for any resource where the PATCH method is shown as an allowed 338 method. 340 OPTIONS * is not used to advertise support for PATCH because the 341 patch formats supported are likely to change from one resource to 342 another. A server MAY include the Accept-Patch header in response to 343 OPTIONS *, and its value MAY be the union of known supported delta 344 encodings for all types of resources. 346 Accept-Patch = "Accept-Patch" ":" #instance-manipulation 348 Example: OPTIONS request and response for specific resource 350 [request] 352 OPTIONS /example/buddies.xml HTTP/1.1 353 Host: www.example.com 355 [response] 357 HTTP/1.1 200 OK 358 Allow: GET, PUT, POST, OPTIONS, HEAD, TRACE, DELETE, PATCH 359 Accept-Patch: vcdiff, gdiff, diffe, example-xcap-xml 361 The examples show a server that supports PATCH generally, with all 362 the delta encodings defined in RFC3229 plus one fictional 363 XML-oriented delta encoding. On some resources, for example on XML 364 files, different kinds of delta encodings more appropriate to the 365 resource may be supported. 367 4. Interdependencies with other Standards 369 4.1 PATCH and Access Control (RFC3744) 371 If the server supports WebDAV Access Control [5], then the PATCH 372 request SHOULD be subject to the same access control permissions as 373 the PUT request. 375 5. IANA Considerations 377 This document uses URNs to describe XML namespaces and XML schemas 378 conforming to a registry mechanism described in [RFC3688]. 380 Registration request for the patch namespace: 382 URI: urn:ietf:params:xml:ns:patch 384 Registrant Contact: See the "Author's Address" section of this 385 document. 387 XML: None. Namespace URIs do not represent an XML specification. 389 6. Security Considerations 391 The security considerations for PATCH are nearly identical to the 392 security considerations for PUT. In addition, one might be concerned 393 that a document that is patched might be more likely to be corrupted, 394 but that concern is addressed through use of MD5 digests. 396 7. References 398 7.1 Normative References 400 [1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 401 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 402 HTTP/1.1", RFC 2616, June 1999. 404 [2] Mogul, J., Krishnamurthy, B., Douglis, F., Feldmann, A., Goland, 405 Y., van Hoff, A. and D. Hellerstein, "Delta encoding in HTTP", 406 RFC 3229, January 2002. 408 7.2 Non-Normative References 410 [3] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen, 411 "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, 412 February 1999. 414 [4] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J. Whitehead, 415 "Versioning Extensions to WebDAV (Web Distributed Authoring and 416 Versioning)", RFC 3253, March 2002. 418 [5] Clemm, G., Reschke, J., Sedlar, E. and J. Whitehead, "Web 419 Distributed Authoring and Versioning (WebDAV) Access Control 420 Protocol", RFC 3744, May 2004. 422 Author's Address 424 Lisa Dusseault 425 Open Source Application Foundation 426 2064 Edgewood Dr. 427 Palo Alto, CA 94303 428 US 430 EMail: lisa@osafoundation.org 432 Appendix A. Acknowledgements 434 PATCH is not a new concept, it first appeared in HTTP in drafts of 435 version 1.1 written by Roy Fielding and Henrik Frystyk. 437 Thanks to Adam Roach, Chris Sharp, Julian Reschke, Geoff Clemm, Scott 438 Lawrence, Jeffrey Mogul, Roy Fielding, Greg Stein, Jim Luther, Alex 439 Rousskov, Jamie Lokier, Joe Hildebrand, Mark Nottingham and Michael 440 Balloni for review and advice on this document. 442 Appendix B. Changes 444 B.1 Changes from -00 446 OPTIONS support: removed "Patch" header definition and used Allow and 447 new "Accept-Patch" headers instead. 449 Supported delta encodings: removed vcdiff and diffe as these do not 450 have defined MIME types and did not seem to be strongly desired. 452 PATCH method definition: Clarified cache behavior. 454 B.2 Changes from -01 456 Removed references to XCAP - not yet a RFC. 458 Fixed use of MIME types (this "fix" now obsolete) 460 Explained how to use MOVE or COPY in conjunction with PATCH, to 461 create a new resource based on an existing resource in a different 462 location. 464 B.3 Changes from -02 466 Clarified that MOVE and COPY are really independent of PATCH. 468 Clarified when an ETag must change, and when Last-Modified must be 469 used. 471 Clarified what server should do if both Content-Type and IM headers 472 appear in PATCH request. 474 Filled in missing reference to DeltaV and ACL RFCs. 476 Stopped using 501 Unsupported for unsupported delta encodings. 478 Clarified what a static resource is. 480 Refixed use of MIME types for patch formats. 482 Limited the scope of some restrictions to apply only to usage of 483 required diff format. 485 B.4 Changes from -03 487 Various typographical, terminology consistency, and other minor 488 clarifications or fixes. 490 B.5 Changes from -04 492 Moved paragraphs on ACL and RFC3229 interoperability to new section. 494 Added security considerations. 496 Added IANA considerations, registration of new namespace, and 497 discontinued use of "DAV:" namespace for new elements. 499 Added example of error response. 501 B.6 Changes from -05 503 Due to various concerns it didn't seem likely the application/gdiff 504 registration could go through so switching to vcdiff as required diff 505 format, and to RFC3229's approach to specifying diff formats, 506 including use of the IM header. 508 Clarified what header server MUST use to return MD5 hash. 510 Reverted to using 501 Unsupported for unsupported delta encodings. 512 Appendix C. Notes to RFC Editor 514 The RFC Editor should remove this section and the Changes section. 516 Intellectual Property Statement 518 The IETF takes no position regarding the validity or scope of any 519 Intellectual Property Rights or other rights that might be claimed to 520 pertain to the implementation or use of the technology described in 521 this document or the extent to which any license under such rights 522 might or might not be available; nor does it represent that it has 523 made any independent effort to identify any such rights. Information 524 on the procedures with respect to rights in RFC documents can be 525 found in BCP 78 and BCP 79. 527 Copies of IPR disclosures made to the IETF Secretariat and any 528 assurances of licenses to be made available, or the result of an 529 attempt made to obtain a general license or permission for the use of 530 such proprietary rights by implementers or users of this 531 specification can be obtained from the IETF on-line IPR repository at 532 http://www.ietf.org/ipr. 534 The IETF invites any interested party to bring to its attention any 535 copyrights, patents or patent applications, or other proprietary 536 rights that may cover technology that may be required to implement 537 this standard. Please address the information to the IETF at 538 ietf-ipr@ietf.org. 540 Disclaimer of Validity 542 This document and the information contained herein are provided on an 543 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 544 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 545 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 546 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 547 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 548 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 550 Copyright Statement 552 Copyright (C) The Internet Society (2004). This document is subject 553 to the rights, licenses and restrictions contained in BCP 78, and 554 except as set forth therein, the authors retain all their rights. 556 Acknowledgment 558 Funding for the RFC Editor function is currently provided by the 559 Internet Society.