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

• From: Joe Hildebrand <JHildebrand@jabber.com>
• Date: 2005年1月14日 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
> (<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