Roy,
At this point I think we're arguing in a circle, so I will
simply wait to see what the authors and Area Director want to
do next. A Gen-ART review has no more standing than any other
Last Call comment.
Regards
Brian Carpenter
On 2009-11-18 15:18, Roy T. Fielding wrote:
On Nov 17, 2009, at 11:53 AM, Brian E Carpenter wrote:
These are the sort of changes that would, I believe, give
sufficient indication to a would-be user of PATCH of how
to make it somewhat safe. Personally I'd prefer to see it
made more prominent by starting with something like:
Clients requiring to verify the consistent application of a
patch document to a known entity SHOULD first acquire an ETag...
Rationale: the use of a normative keyword will draw the
attention of implementors who might otherwise not think
about this issue.
It would also be wrong, because it is neither a requirement
for interoperation nor a potential for causing harm (RFC 2119).
Aside from which, it makes the original purpose of PATCH
non-compliant with its own specification.
The purpose of PATCH is to request that the server apply a
set of changes to the current state of the target resource.
The assumption that these changes will be dependent on a
specific prior representation of that resource is false.
The server is fully capable of detecting and reporting
conflicts when they occur with the current state, as only
truly known by the server.
In other words ...
If the client wants to prevent the PATCH method from being
applied to a resource for which the state has changed since
the last state known by the client, then it SHOULD use one
or more of the conditional request mechanisms of HTTP
(If-Match and If-Unmodified-Since request headers [RFC2616])
or WebDAV (If request header [RFC4918]) with the
associated metadata from that prior resource state.
However, if the patch media type contains its own mechanism
for detecting conflicts, such as embedded context or metadata
designed to allow non-overlapping changes to be safely applied,
then the conditional request mechanisms SHOULD NOT
be used with PATCH because they would interfere with
collaborative applications, such as shared editors and
whiteboards.
FTR, the prior sentence, that PATCH is somehow more likely
to result in corrupted state than a PUT, is simply false for
any patch format that contains context or post-application
integrity checks. The only reason it was in the spec is
because earlier versions assumed a patch format that contains
nothing but byte-vector manipulations. It should be removed,
or at least altered to be factual.
....Roy
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf