BIND, lock root, and clarifying RFC4918

I've been discussing the BIND draft's appendix A <
http://tools.ietf.org/html/draft-ietf-webdav-bind-25#appendix-A> with
Julian, and he asked me to post my opinion publicly.

There are two possible meanings when we discuss "the root of a lock":  this
could refer to the resource that was directly locked, or to the URL that was
addressed in the LOCK request.  There are cases where RFC4918 definitely
uses this phrase to mean resource: "The resource identified in the
Request-URI becomes the root of the lock.".  (<
http://tools.ietf.org/html/rfc4918#section-7.4>)

The appendix to BIND "clarifies" this by contradicting it, and saying that
the lock root is actually the URI.  (Certainly I agree the value of the
'lock-root' element is the URI so at least that's not controversial.)  This
"clarification" is justified by needing to explain that the lock does not
cover the URIs that are bindings to the resource, other than the URI that
was LOCKed.    I don't think there is a need to change the words of 4918 or
clarify them; the behavior of bindings can be specified in BIND without
that.

With bindings functionality as Julian explains it in email, you can send an
UNLOCK request to any binding of a locked resource, even though some of
those bindings aren't covered by the lock.  You can also change a binding
that's not covered by the lock, so if you lock a resource through a binding
in your collection, I can change the name of the binding to the same
resource in my collection or remove it.  This behavior makes at least as
much sense as any other, but it should be explained explicitly.  I don't
think it falls out of the model trivially the same way for everybody reading
the BIND document.

Sometimes with messy, deployed protocols and extensions, it's hard to define
a model such that all the behavior simply can be deduced from the model.
Sometimes you have to actually say "it works this way" although it also
helps to have the model.

To be clear, since BIND is an experimental document, I think this appendix
is pretty harmless to everything except possibly the interoperability of
bindings implementations, so I'm not blocking the document or doing anything
other than explain my lack of complete agreement.

Lisa