9 Jul 2009 18:56
BIND, lock root, and clarifying RFC4918
Lisa Dusseault <lisa.dusseault <at> gmail.com>
2009-07-09 16:56:22 GMT
2009-07-09 16:56:22 GMT
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.