I would like to revise and expand on some wording that I introduced in the first sentence, to make it clearer: 2.x UNLOCK and Bindings Due to the specific language used in section 8.11 of [RFC2518], it might be thought that an UNLOCK request to a locked resource would unlock just the particular binding expressed by the Request-URI, rather than the resource identified by that URI. This is not the case, however. Section 6 of [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. The authors of this specification anticipate and recommend that future revisions of [RFC2518] maintain this behavior. Julian Reschke wrote: > Ok, > > so do we have consensus to add the following subsection to > section 2 > (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-late > st.html#overview.of.bindings>)? > > > 2.x UNLOCK and Bindings > > Due to the specific language used in section 8.11 of > [RFC2518], 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. Section > 6 of [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. The authors of this > specification > anticipate and recommend that future revisions of [RFC2518] maintain > this behavior.Received on Tuesday, 18 January 2005 22:18:55 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:33 UTC