idnits 2.17.1 draft-dusseault-http-patch-09.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 629. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 640. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 647. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 653. 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 IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 19, 2007) is 6094 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) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 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: February 20, 2008 J. Snell 5 August 19, 2007 7 PATCH Method for HTTP 8 draft-dusseault-http-patch-09 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on February 20, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 Several applications extending HTTP require a feature to do partial 42 resource modification. Existing HTTP functionality only allows a 43 complete replacement of a document. This proposal adds a new HTTP 44 method, PATCH, to modify an existing HTTP resource. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. The PATCH Method . . . . . . . . . . . . . . . . . . . . . . . 3 50 2.1. A simple PATCH example . . . . . . . . . . . . . . . . . . 5 51 2.2. Error handling . . . . . . . . . . . . . . . . . . . . . . 5 52 2.3. Advertising Support in OPTIONS . . . . . . . . . . . . . . 6 53 2.3.1. An example OPTIONS request and response . . . . . . . 7 54 3. 209 Content Returned . . . . . . . . . . . . . . . . . . . . . 7 55 4. The Prefer Request Header . . . . . . . . . . . . . . . . . . 7 56 4.1. The "no-content" Preference . . . . . . . . . . . . . . . 8 57 4.2. The "content-returned" Preference . . . . . . . . . . . . 8 58 4.3. The 601 Preference Ignored Warn Code . . . . . . . . . . . 8 59 4.4. The 602 Preference Honored Warn Code . . . . . . . . . . . 9 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 61 5.1. The 'Accept-Patch' Response Header . . . . . . . . . . . . 9 62 5.2. HTTP Status codes . . . . . . . . . . . . . . . . . . . . 9 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 66 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 67 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 68 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 11 69 B.1. Changes from -00 . . . . . . . . . . . . . . . . . . . . . 11 70 B.2. Changes from -01 . . . . . . . . . . . . . . . . . . . . . 11 71 B.3. Changes from -02 . . . . . . . . . . . . . . . . . . . . . 11 72 B.4. Changes from -03 . . . . . . . . . . . . . . . . . . . . . 12 73 B.5. Changes from -04 . . . . . . . . . . . . . . . . . . . . . 12 74 B.6. Changes from -05 . . . . . . . . . . . . . . . . . . . . . 12 75 B.7. Changes from -06 . . . . . . . . . . . . . . . . . . . . . 12 76 B.8. Changes from -07 . . . . . . . . . . . . . . . . . . . . . 12 77 B.9. Changes from -08 . . . . . . . . . . . . . . . . . . . . . 13 78 Appendix C. Notes to RFC Editor . . . . . . . . . . . . . . . . . 13 79 Appendix D. Editorial Notes . . . . . . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 81 Intellectual Property and Copyright Statements . . . . . . . . . . 15 83 1. Introduction 85 This specification defines the new HTTP 1.1 [RFC2616] method PATCH 86 that is used to apply partial modifications to a HTTP resource. 88 A new method is necessary to improve interoperability and prevent 89 errors. The PUT method is already defined to overwrite a resource 90 with a complete new body, and can not be reused to do partial 91 changes. Otherwise, proxies and caches and even clients and servers 92 may get confused as to the result of the operation. 94 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 95 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 96 and "OPTIONAL" are to be interpreted as described in [RFC2119]. 98 2. The PATCH Method 100 The PATCH method requests that a set of changes described in the 101 request entity be applied to the resource identified by the Request- 102 URI. The set of changes is represented in a format called a "patch 103 document" identified by a media type. PATCH is neither safe or 104 idempotent as defined by [RFC2616] Section 9.1. 106 The difference between the PUT and PATCH requests is reflected in the 107 way the server processes the enclosed entity to modify the resource 108 identified by the Request-URI. In a PUT request, the enclosed entity 109 is considered to be a modified version of the resource stored on the 110 origin server and the client is requesting that stored version be 111 replaced. With PATCH, however, the enclosed entity contains a set of 112 instructions describing how a resource currently residing on the 113 origin server should be modified to produce a new version. The 114 changes described by the entity MAY result in the creation of one or 115 more new resources on the server, however it is not intended that the 116 body of the PATCH request be used as the content of such resources. 118 The server MUST always apply the entire set of changes atomically and 119 never provide (e.g. in response to a GET during this operation) a 120 partially-modified representation. If the entire patch document 121 cannot be successfully applied then the server MUST fail the entire 122 request, applying none of the changes. The determination of what 123 constitutes a successful PATCH can vary depending on the patch 124 document and the type of resource being modified. The actual method 125 for determining how to apply the patch document to the resource is 126 defined entirely by the origin server. See Error Handling in section 127 2.2 for details on status codes and possible error conditions. 129 If the request passes through a cache and the Request-URI identifies 130 one or more currently cached entities, those entries SHOULD be 131 treated as stale. Responses to this method are not cacheable, unless 132 the response includes appropriate Cache-Control or Expires header 133 fields or the response uses the 209 Content Returned status code as 134 defined in Section 3. The 303 (See Other) response can be used to 135 direct the user agent to retrieve a cacheable resource. 137 Collisions from multiple requests are more dangerous than PUT 138 collisions, because a patch document that is not operating from a 139 known base point may corrupt the resource. Clients wishing to apply 140 a patch document to a known entity can first acquire the strong ETag 141 of the resource to be modified, and use that Etag in the If-Match 142 header on the PATCH request to verify that the resource is still 143 unchanged. If a strong ETag is not available for a given resource, 144 the client can use If-Unmodified-Since as a less-reliable safeguard. 146 It is RECOMMENDED that Servers provide strong ETags for all resources 147 for which PATCH is supported. 149 If a PATCH request contains any entity-headers the server does not 150 understand, the server MUST return a 501 (Not Implemented) response. 151 A server that understands a particular entity-header can choose to 152 ignore it; however, doing so can produce results that are unexpected 153 or unintended by the client. All entity-headers contained in the 154 request apply only to the contained patch document and MUST NOT be 155 applied to the resource being modified. 157 If the Request-URI identifies a resource with multiple alternate 158 representations, the server can choose to respond in a variety of 159 ways. For instance, the server can decide which representation to 160 alter and might even be able to change them all consistently 161 depending on the patch format. A particular patch document might be 162 able to identify specific representations to modify or might be 163 capable of describing changes to multiple representations. If the 164 server cannot choose a representation, it can reject the request with 165 an error or the server can choose to redirect the request (e.g. using 166 301 Moved Permanently or 302 Found), in which case the user agent 167 makes its own decision regarding whether or not to proceed with the 168 request. 170 Clients are advised to take caution when sending multiple PATCH 171 requests, or sequences of requests that include PATCH, over a 172 pipelined connection as there are no guarantees that pipelined 173 requests will be processed by the server in the same order in which 174 the client sends them. Such sequences of requests can be made safer 175 by using conditional request mechanisms such as If-Match. See 176 [RFC2616] Section 8.1.2.2 for additional details regarding pipelining 177 and non-idempotent requests. 179 There is no guarantee that a resource can be modified with PATCH. 180 Further, it is expected that different patch document formats will be 181 appropriate for different types of resources and that no single 182 format will be appropriate for all types of resources. Therefore, 183 there is no single default patch document format that implementations 184 are required to support. Servers MUST ensure that a received patch 185 document is appropriate for the type of resource identified by the 186 Request-URI. 188 2.1. A simple PATCH example 190 PATCH /file.txt HTTP/1.1 191 Host: www.example.com 192 Content-type: application/example 193 If-Match: "e0023aa4e" 194 Content-Length: 100 196 [description of changes] 198 This example illustrates use of a hypothetical patch document on an 199 existing text file. 201 Successful PATCH response to existing text file 203 HTTP/1.1 204 No Content 204 ETag: "e0023aa4f" 205 Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== 207 2.2. Error handling 209 There are several known conditions under which a PATCH request can 210 fail. 212 Malformed patch document: Can be specified using a 400 Bad Request 213 when the server finds that the patch document provided by the 214 client was improperly formatted. The definition of badly 215 formatted depends on the patch document chosen, but generally if 216 the server finds it cannot handle the patch due to the 217 serialization of the patch document, this response ought to be 218 appropriate. 219 Unsupported patch document: Specified using a 415 Unsupported Media 220 Type when the client sends a patch document that the server 221 doesn't support for the resource identified by the Request-URI. 222 Such a response SHOULD include an Accept-Patch response header as 223 described in Section 2.3 to notify the client what patch document 224 formats are supported. 226 Unprocessable request: Can be specified with a 422 Unprocessable 227 Entity [RFC4918] when the server understands the patch document 228 and the syntax of the patch document appears valid, but the server 229 is incapable of processing the request. There are a number of 230 situations that could lead to such a result, for example: 231 * The client attempted to apply a patch document to an empty 232 resource, but the patch document chosen cannot be applied to an 233 empty resource. 234 * The client attempted to apply a structural modification and the 235 structures assumed to exist did not exist (e.g. a patch which 236 specifies changing element 'foo' to element 'bar' but element 237 'foo' doesn't exist). 238 * The client attempted to modify a resource in a way that would 239 cause the resource to become invalid. For instance, a 240 modification to a well-formed XML document that would cause it 241 to no longer be well-formed. 242 * The client attempted to modify a resource that has multiple 243 representations but the server was unable to choose which 244 representation to modify. 245 Conflicting modification: Specified with a 412 Precondition Failed 246 when a client uses either the If-Match or If-Unmodified-Since 247 request headers and attempts to apply a patch document to a 248 resource whose state has changed since the patch was created. If 249 the server detects a possible conflicting modification and neither 250 the If-Match or If-Unmodified-Since request headers are used, the 251 server can return a 409 Conflict response. 252 Concurrent modification: When a server receives multiple concurrent 253 requests to modify a resource, those requests SHOULD be queued and 254 processed in the order in which they are received. If a server is 255 incapable of queuing concurrent requests, all subsequent requests 256 SHOULD be rejected using a 409 Conflict response until the first 257 modification request is complete. 259 Other HTTP status codes can also be used under the appropriate 260 circumstances. 262 The entity body of error responses SHOULD contain enough information 263 to communicate the nature of the error to the client. The content- 264 type of the response entity can vary across implementations. 266 2.3. Advertising Support in OPTIONS 268 A server can advertise its support for the PATCH method by adding it 269 to the listing of allowed methods in the "Allow" OPTIONS response 270 header defined in HTTP/1.1. 272 Clients also need to know whether the server supports specific patch 273 document formats, so this specification introduces a new response 274 header "Accept-Patch" used to specify the patch document formats 275 accepted by the server. "Accept-Patch" MUST appear in the OPTIONS 276 response for any resource that supports the use of the PATCH method. 277 The presence of the "Accept-Patch" header in response to any method 278 is an implicit indication that PATCH is allowed on the resource 279 identified by the Request-URI. 281 Accept-Patch = "Accept-Patch" ":" #( media-range ) 283 The Accept-Patch header specifies a listing of media ranges as 284 defined by [RFC2616], Section 14.1. Note that, unlike the HTTP 285 Accept request header, the Accept-Patch header does not use quality 286 factors. 288 2.3.1. An example OPTIONS request and response 290 [request] 292 OPTIONS /example/buddies.xml HTTP/1.1 293 Host: www.example.com 295 [response] 297 HTTP/1.1 200 OK 298 Allow: GET, PUT, POST, OPTIONS, HEAD, DELETE, PATCH 299 Accept-Patch: application/example, text/example 301 The examples show a server that supports PATCH generally using two 302 hypothetical patch documents. 304 3. 209 Content Returned 306 The 209 "Content Returned" status code can be used to indicate that a 307 response is equivalent to what would have been returned with a 200 308 status code response to a GET sent to the URI immediately following 309 the successful completion of the request. 311 4. The Prefer Request Header 313 The Prefer request-header is used to indicate that particular server 314 behaviors are preferred, but not required, by the client. Prefer is 315 similar in nature to the Expect header defined by [RFC2616] with the 316 exception that servers are allowed to ignore a clients stated 317 preference. 319 Prefer = "Prefer" ":" 1#preference 321 preference = "no-content" | "content-returned" | 322 preference-extension 323 preference-extension = token [ "=" ( token | quoted-string ) 324 *prefer-params ] 325 prefer-params = ";" token [ "=" ( token | quoted-string ) ] 327 This header is defined with an extensible syntax to allow for future 328 extensions. A server that does not understand or is unable to comply 329 with any of the preference values in the Prefer field of a request 330 MUST ignore those values and MUST NOT stop processing or signal an 331 error. 333 Comparison of preference values is case-insensitive for unquoted 334 tokens and is case-sensitive for quoted-string preference-extensions. 336 The Prefer mechanism is hop-by-hop: that is, an HTTP proxy MAY choose 337 to honor a preference even if the origin server does not. However, 338 the Prefer request-header itself is end-to-end; it MUST be forwarded 339 if the request is forwarded. 341 4.1. The "no-content" Preference 343 The "no-content" preference token indicates that the client prefers 344 that the server respond to a successful request using the 204 No 345 Content status code as defined in Section 10.2.5 of [RFC2616]. 347 4.2. The "content-returned" Preference 349 The "content-returned" preference token indicates that the client 350 prefers that the server respond to a successful request using the 209 351 Content Returned status code as defined in Section 3. 353 4.3. The 601 Preference Ignored Warn Code 355 When a server chooses to ignore a preference value specified in the 356 Prefer header, it MAY include a Warning header field in the response 357 message using the "601 Preference Ignored" warn code. The warning 358 text SHOULD specify the specific preference tokens that were ignored. 360 For instance, the following example notifies the client that the 361 "content-returned" preference token was intentionally ignored by the 362 server. 364 HTTP/1.1 204 No Content 365 Warning: 601 origin "content-returned" 367 4.4. The 602 Preference Honored Warn Code 369 When an HTTP proxy chooses to honor a preference even when the origin 370 server does not, it SHOULD include a Warning header field in the 371 response message using the "602 Preference Honored" warn code. The 372 warning text SHOULD specify the specific preference tokens that were 373 honored. 375 For instance, the following example notifies the client that the "no- 376 content" preference token was intentionally ignored by the origin 377 server, however a proxy chose to honor the preference and return the 378 prefered status code. 380 HTTP/1.1 204 No Content 381 Warning: 601 origin "no-content" 382 Warning: 602 proxy "no-content" 384 Use of the 602 warn-code is restricted to HTTP proxies and caches. 385 HTTP origin servers MUST NOT use the 602 warn-code. 387 5. IANA Considerations 389 5.1. The 'Accept-Patch' Response Header 391 The 'Accept-Patch' response header should be added to the permanent 392 registry (see [RFC3864]). 394 Header field name: Accept-Patch 396 Applicable Protocol: HTTP 398 Status: standard 400 Author/Change controller: IETF 402 Specification document: this specification 404 5.2. HTTP Status codes 406 This specification defines the 209 Content Returned status code 407 (Section 3) to be updated in the registry at 408 . 410 6. Security Considerations 412 The security considerations for PATCH are nearly identical to the 413 security considerations for PUT. In addition, one might be concerned 414 that a document that is patched might be more likely to be corrupted, 415 but that concern can be addressed through the use of mechanisms such 416 as conditional requests using ETags and the If-Match request header. 418 Sometimes an HTTP intermediary might try to detect viruses being sent 419 via HTTP by checking the body of the PUT/POST request or GET 420 response. The PATCH method complicates such watch-keeping because 421 neither the source document nor the patch document might be a virus, 422 yet the result could be. This security consideration is not 423 materially different from those already introduced by byte-range 424 downloads, downloading patch documents, uploading zipped (compressed) 425 files and so on. 427 Individual patch documents will have their own specific security 428 considerations that will likely vary depending on the types of 429 resources being patched. The considerations for patched binary 430 resources, for instance, will be different than those for patched XML 431 documents. 433 7. References 435 7.1. Normative References 437 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 438 Requirement Levels", BCP 14, RFC 2119, March 1997. 440 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 441 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 442 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 444 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 445 Procedures for Message Header Fields", BCP 90, RFC 3864, 446 September 2004. 448 7.2. Informative References 450 [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed 451 Authoring and Versioning (WebDAV)", RFC 4918, June 2007. 453 Appendix A. Acknowledgements 455 PATCH is not a new concept, it first appeared in HTTP in drafts of 456 version 1.1 written by Roy Fielding and Henrik Frystyk. 458 Thanks to Adam Roach, Chris Sharp, Julian Reschke, Geoff Clemm, Scott 459 Lawrence, Jeffrey Mogul, Roy Fielding, Greg Stein, Jim Luther, Alex 460 Rousskov, Jamie Lokier, Joe Hildebrand, Mark Nottingham and Michael 461 Balloni for review and advice on this document. 463 Appendix B. Changes 465 B.1. Changes from -00 467 OPTIONS support: removed "Patch" header definition and used Allow and 468 new "Accept-Patch" headers instead. 470 Supported delta encodings: removed vcdiff and diffe as these do not 471 have defined MIME types and did not seem to be strongly desired. 473 PATCH method definition: Clarified cache behavior. 475 B.2. Changes from -01 477 Removed references to XCAP - not yet a RFC. 479 Fixed use of MIME types (this "fix" now obsolete) 481 Explained how to use MOVE or COPY in conjunction with PATCH, to 482 create a new resource based on an existing resource in a different 483 location. 485 B.3. Changes from -02 487 Clarified that MOVE and COPY are really independent of PATCH. 489 Clarified when an ETag must change, and when Last-Modified must be 490 used. 492 Clarified what server should do if both Content-Type and IM headers 493 appear in PATCH request. 495 Filled in missing reference to DeltaV and ACL RFCs. 497 Stopped using 501 Unsupported for unsupported delta encodings. 499 Clarified what a static resource is. 501 Refixed use of MIME types for patch formats. 503 Limited the scope of some restrictions to apply only to usage of 504 required diff format. 506 B.4. Changes from -03 508 Various typographical, terminology consistency, and other minor 509 clarifications or fixes. 511 B.5. Changes from -04 513 Moved paragraphs on ACL and RFC3229 interoperability to new section. 515 Added security considerations. 517 Added IANA considerations, registration of new namespace, and 518 discontinued use of "DAV:" namespace for new elements. 520 Added example of error response. 522 B.6. Changes from -05 524 Due to various concerns it didn't seem likely the application/gdiff 525 registration could go through so switching to vcdiff as required diff 526 format, and to RFC3229's approach to specifying diff formats, 527 including use of the IM header. 529 Clarified what header server MUST use to return MD5 hash. 531 Reverted to using 501 Unsupported for unsupported delta encodings. 533 B.7. Changes from -06 535 The reliance on RFC 3229 defined patch documents has been factored 536 out in favor of delta encodings identified by MIME media type. 538 The required use of DeltaV-based error reporting has been removed in 539 favor of using basic HTTP status codes to report error conditions. 541 The Accept-Patch response header has been redefined as a listing of 542 media-ranges, similar to the Accept request header. 544 Added James Snell as a co-author. 546 B.8. Changes from -07 548 Terminology change from "delta encoding" to "patch document" 550 Added clarification on the safety and idempotency of PATCH 551 Updated the caching rules of PATCH responses 553 200 responses MUST include a representation of the modified resource. 554 204 responses are used to indicate successful response without 555 returning a representation. 557 Suggest using 422 Unprocessable Entity to indicate that a properly 558 formatted patch document cannot be processed 560 Clarify the use of 412 and 409 to indicate concurrent and conflicting 561 resource modifications. 563 Added registration for the Accept-Patch header. 565 Relaxed the requirements for the use of If-Match and If-Unmodified- 566 Since. 568 Add language that clarifies the difference between PUT and PATCH. 570 Add language that clarifies the issues with PATCH and Content 571 Negotiation. 573 Use of Accept-Patch on any response implies that PATCH is supported. 575 Add language advising caution when pipelining PATCH requests. 577 B.9. Changes from -08 579 Addition of the 209 Content Returned status code 581 Addition of the Prefer header field mechanism 583 Removed the paragraph discussing the use of 200+Content-Location. 584 This is replaced by the 209 Content Returned status code. 586 Appendix C. Notes to RFC Editor 588 The RFC Editor should remove this section and the Changes section. 590 Appendix D. Editorial Notes 592 There are several outstanding issues with the Prefer section: 594 o Should the Prefer section be separated out into a separate I-D? 595 o We need to determine how new preference codes are created/ 596 registered 597 o Are warn-codes ok or do we need a new response header? 599 Authors' Addresses 601 Lisa Dusseault 602 Open Source Application Foundation 603 2064 Edgewood Dr. 604 Palo Alto, CA 94303 605 US 607 Email: lisa@osafoundation.org 609 James M Snell 611 Phone: 612 Email: jasnell@gmail.com 613 URI: http://www.snellspace.com 615 Full Copyright Statement 617 Copyright (C) The IETF Trust (2007). 619 This document is subject to the rights, licenses and restrictions 620 contained in BCP 78, and except as set forth therein, the authors 621 retain all their rights. 623 This document and the information contained herein are provided on an 624 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 625 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 626 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 627 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 628 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 629 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 631 Intellectual Property 633 The IETF takes no position regarding the validity or scope of any 634 Intellectual Property Rights or other rights that might be claimed to 635 pertain to the implementation or use of the technology described in 636 this document or the extent to which any license under such rights 637 might or might not be available; nor does it represent that it has 638 made any independent effort to identify any such rights. Information 639 on the procedures with respect to rights in RFC documents can be 640 found in BCP 78 and BCP 79. 642 Copies of IPR disclosures made to the IETF Secretariat and any 643 assurances of licenses to be made available, or the result of an 644 attempt made to obtain a general license or permission for the use of 645 such proprietary rights by implementers or users of this 646 specification can be obtained from the IETF on-line IPR repository at 647 http://www.ietf.org/ipr. 649 The IETF invites any interested party to bring to its attention any 650 copyrights, patents or patent applications, or other proprietary 651 rights that may cover technology that may be required to implement 652 this standard. Please address the information to the IETF at 653 ietf-ipr@ietf.org. 655 Acknowledgment 657 Funding for the RFC Editor function is provided by the IETF 658 Administrative Support Activity (IASA).