PATCH Method for HTTP
RFC 5789

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'PATCH Method for HTTP' to Proposed Standard

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