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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
