Re: BIND, lock root, and clarifying RFC4918

The term "lock-root" is introduced and very clearly defined in section 6.1 
(Lock Model) to be a URI:

A resource becomes directly locked when a LOCK request to a URL of that 
resource creates a new lock.
The "lock-root" of the new lock is that URL. 

There are four other occurrences of "lock-root", or "root of the lock" 
that make it equally clear that the root of a lock is a URI:

Section 6.1 (Lock Model):
If a request causes the lock-root of any lock to become an unmapped URL, 

Section 7 (Write Lock):
The list of modifications covered by a write-lock include: ... A 
modification of the mapping of the root of the write lock,  either to 
another resource or to no resource 

Section 7.4 (Write Locks and Collections):
With a depth-infinity lock, the resource identified by the root of the 
lock is directly locked

Section 14.12 (lockroot XML Element):
   Name:   lockroot
   Purpose:   Contains the root URL of the lock, which is the URL through 
which the resource was addressed in the LOCK request.

In section 9.10.1 (not section 7.4), we have the first and only mis-use of 
the term that was quoted by Lisa:
The resource identified in the Request-URI becomes the root of the lock.

It should have said just "The Request-URI becomes the root of the lock." 

I don't see how anyone could conclude that there are "two possible 
meanings" of the term lock root.
This single mis-use of the term is clearly just a bug in RFC-4918 that 
needs to be fixed.

Cheers,
Geoff


Lisa Dusseault wrote on 07/09/2009 12:56:22 PM:

> 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