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

• From: Joe Hildebrand <JHildebrand@jabber.com>
• Date: Fri, 14 Jan 2005 12:54:03 -0700
• To:
• Cc: webdav <w3c-dist-auth@w3.org>
• Message-ID: <8D96EDA0AC04D31197B400A0C96C14800E2C72B2@corp.webb.net>

> > 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
> (<https://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