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

> > 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:00:55 UTC