Re: Protocol Action: 'PATCH Method for HTTP' to Proposed Standard

(FYI)

The IESG wrote:
> 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
>

Received on Thursday, 10 December 2009 19:55:27 UTC