The IESG has approved the following document: - 'PATCH Method for HTTP ' <draft-dusseault-http-patch-16.txt> as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Alexey Melnikov. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-16.txt Technical Summary Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource in a generic way. Working Group Summary This is not a Working Group document; rather, it is an Individual Submission that is seeking IETF Consensus as an Standards Track RFC. However, this document has been reviewed and discussed extensively on the HTTPbis, WebDAV and Atom mailing lists. Document Quality The document has been reviewed extensively on the HTTPbis mailing list over a long period of time, and no substantive issues have arisen in the last few drafts. There has not yet been appreciable implementation experience, although several vendors have expressed interest. Personnel Mark Nottingham is the Document Shepherd for this document. Alexey Melnikov is the responsible AD. RFC Editor Notes In Section 2, change the last 2 sentences of the 4th paragraph to read: OLD: Clients using this kind of patch application SHOULD acquire a strong ETag [RFC2616] for the resource to be modified, and use that ETag in the If-Match header on the PATCH request to verify that the resource is still unchanged. If a strong ETag is not available for a given resource, the client can use If-Unmodified-Since as a less-reliable safeguard. NEW: Clients using this kind of patch application SHOULD use a conditional request such that the request will fail if the resource has been updated since the client last accessed the resource. For example, the client can use a strong ETag [RFC2616] in an If-Match header on the PATCH request. In Section 2.1, change everything starting from the 3rd paragraph: OLD: This example illustrates use of a hypothetical patch document on an existing resource. The 204 response code is used because the response does not have a body (a response with the 200 code would have a body) but other success codes can be used if appropriate. Successful PATCH response to existing text file HTTP/1.1 204 No Content Content-Location: /file.txt ETag: "e0023aa4f" NEW: This example illustrates use of a hypothetical patch document on an existing resource. Successful PATCH response to existing text file: HTTP/1.1 204 No Content Content-Location: /file.txt ETag: "e0023aa4f" The 204 response code is used because the response does not carry a message body (which a response with the 200 code would have). Note that other success codes could be used as well. Futhermore, the ETag response header field contains the ETag for the entity created by applying the PATCH, available at http://www.example.com/file.txt, as indicated by the Content-Location response header field. Please change the last paragraph of the Section 3.1 to read: OLD: The Accept-Patch header specifies a comma separated listing of media- types as defined by [RFC2616], Section 3.7. NEW: The Accept-Patch header specifies a comma separated listing of media- types (with optional parameters) as defined by [RFC2616], Section 3.7. Example: Accept-Patch: text/example;charset=utf-8 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
