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. Brian On 2009-11-18 05:03, Julian Reschke wrote: > John C Klensin wrote: >> ... >>> 1) the client can't control whether the etag will be strong, >>> and weak etags may work just fine in certain instances, so >>> just be silent about the type >> >> Silent, no. But saying "can't control... certain instances" >> explicitly would be fine. I'd be even happier with an >> explanation of what such an instance might look like, but don't >> see that as a requirement. >> ... > > It's up to the server to decide whether it provides strong or weak > etags. And it's also up to the server to decide whether you can use them > in a conditional PATCH request (RFC 2616 disallowed this, but HTTPbis is > lifting that restriction, and furthermore WebDAV never had it). > > I think not stating this explicitly is the simplest approach (as this is > true for any HTTP method), but I wouldn't object to have more text > either (as long as that text wouldn't have to revised when HTTPbis is > done). > > BR, Julian > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf