Subject: BIND, lock root, and clarifying RFC4918

From: Lisa Dusseault <[email-masked]>
Date: Thu, 9 Jul 2009 09:56:22 -0700

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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 9 Jul 2009 14:22:33 -0400

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 
> 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