RE: [Bug 2] Bindings needs to completely describe how bindings in teract with locks.

I like Joe's suggestion, but I would word it differently, because part
of 2518's description of UNLOCK is flawed and misleading.  Note that it
says "The UNLOCK method removes the lock... from the Request-URI", not
from the *resource* identified by the Request-URI.  It is clearly stated
elsewhere in 2518 that "locks apply to resources, not URIs," and the
sentence on UNLOCK goes on to talk about "all other resources included
in the lock."  So the sentence is internally inconsistent.  If one
relied just on this misleading portion of the description of UNLOCK from
2518, one could mistakenly conclude that locks are on URIs, not
resources, and hence an UNLOCK on a URI other than the one used in the
original LOCK operation would fail.  I think this is at the heart of
Lisa's concern.

So I would rework Joe's suggestion this way, so that it doesn't rely on
the flawed definition of UNLOCK:

<blockquote>
   It might be thought that an UNLOCK request to a locked resource
   would unlock just the binding of the Request-URI.  This is not
   the case, however. [RFC2518] clearly states that locks are on
   resources, not URIs, so the server MUST allow UNLOCK to be used
   to unlock a locked resource through any binding to that resource,
   given an otherwise well-formed and permissioned request.  The
   authors of this specification anticipate and recommend that future
   revisions of [RFC2518] maintain this behavior.
</blockquote>

--Chuck Fay, FileNet Corporation, Costa Mesa, CA
phone:  (714) 327-3513, fax:  (714) 327-5076, email:  cfay@filenet.com 

-----
Joe Hildebrand wrote:
> > > like "The server MUST allow UNLOCK to work on any binding
> > to a locked
> > > resource, given an otherwise well-formed and permissioned request"
> > > (some standards-track document, not an email list or bug db), the 
> > > requirements for interoperability have minimally been met.
> > 
> > But that's what RFC2518 already says
> > (<http://greenbytes.de/tech/webdav/rfc2518.html#METHOD_UNLOCK>):
> > 
> > "The UNLOCK method removes the lock identified by the lock token in 
> > the Lock-Token request header from the Request-URI, and all other 
> > resources included in the lock. If all resources which have been 
> > locked under the submitted lock token can not be unlocked then the 
> > UNLOCK request MUST fail."
> 
> 
> How about this.  Section 2.3 of BIND has this language:
> 
> <blockquote>
>    It might be thought that a COPY request with "Depth: 0" on a
>    collection would duplicate its bindings, since bindings are part of
>    the collection's state.  This is not the case, however.  The
>    definition of Depth in [RFC2518] makes it clear that a "Depth: 0"
>    request does not apply to a collection's members.  Consequently, a
>    COPY with "Depth: 0" does not duplicate the bindings 
> contained by the
>    collection.
> </blockquote>
> 
> And 1.2 has this:
> 
> <blockquote>
>    The authors of this specification anticipate and
>    recommend that future revisions of [RFC2518] will update the
>    definition of the state of a collection to correspond to the
>    definition in this document.
> </blockquote>
> 
> If there was an extra paragraph in BIND that pulled from the 
> spirit of these two existing statements, could we move 
> forward?  Something like:
> 
> <blockquote>
>    It might be thought that an UNLOCK request to a locked resource
>    might unlock just that binding.  This is not the case, 
> however.  The
>    definition of UNLOCK in [RFC2518] makes it clear that the 
> server MUST
>    allow UNLOCK to work on any binding to a locked resource, given an
>    otherwise well-formed and permissioned request.  The 
> authors of this
>    specification anticipate and recommend that future revisions of
>    [RFC2518] maintain this behavior.
> </blockquote>
> 
> This doesn't change 2518.  It doesn't over-specify.  It 
> provides guidance for implementors, and makes clear the 
> relationship with 2518bis.
> 
> --
> Joe Hildebrand

Received on Friday, 14 January 2005 20:40:22 UTC