Re: bind issue: locking2

Werner Donné wrote:
> Hi,
> 
> In RFC4918 the phrase "The resource identified in the Request-URI becomes the root of the lock." of section 9.10.1 seems to be wrong to me. It could be just "The Request-URI becomes the root of the lock." The definition of the "lockroot" element, which says "Contains the root URL of the lock, which is the URL through which the resource was addressed in the LOCK request." confirms that section 6.1 point 2 is correct.
> 
> As far as I understand it, in HTTP a resource is an opaque thing that is not specified as such. HTTP and related specifications are about representing a resource and interacting with it, not about a resource itself. The URI-specification is about addressing a resource, implying an URI is not the same thing as the resource it addresses. A resource is an undefined concept and can therefore not be the root of a lock. I would think that RFC4918 did not introduce the confusion intentionally, because the alternative server behaviour would simply be invalid.
> 
> Since there is an error in RFC4918, which will be corrected at some point, you can also just refer to section 6.1 point 2 without even mentioning section 9.10.1. If you make use of the definition of lock-root in an explicit way, then there will be no ambiguity and the text can remain the same whenever the successor of RFC4918 comes out.
> 
> Best regards,
> 
> Werner.
> ...

Hi Werner,

it appears you are agreeing with what the published BIND specs say, and 
what I have reported as erratum for RFC 4918 in 
<http://www.rfc-editor.org/errata_search.php?eid=1207>. That's good to 
know, but I have failed to convince the author and the chairs about this 
back before publication of RFC 4918, and also failed to convince the 
IESG later on.

Thus the revised proposal that just states that RFC 4918 is ambiguous, 
and that servers that want to support BIND need to follow a more 
specific definition.

Best regards, Julian

Received on Monday, 14 December 2009 09:11:05 UTC