Re: bind issue: locking2

[Werner Donné <[e-mail]>]

Hi,

In RFC4918 the phrase "The resource identified in the Request-URI becomes the root of the lock." of section 9.10.1 seems to be wrong to me. It could be just "The Request-URI becomes the root of the lock." The definition of the "lockroot" element, which says "Contains the root URL of the lock, which is the URL through which the resource was addressed in the LOCK request." confirms that section 6.1 point 2 is correct.

As far as I understand it, in HTTP a resource is an opaque thing that is not specified as such. HTTP and related specifications are about representing a resource and interacting with it, not about a resource itself. The URI-specification is about addressing a resource, implying an URI is not the same thing as the resource it addresses. A resource is an undefined concept and can therefore not be the root of a lock. I would think that RFC4918 did not introduce the confusion intentionally, because the alternative server behaviour would simply be invalid.

Since there is an error in RFC4918, which will be corrected at some point, you can also just refer to section 6.1 point 2 without even mentioning section 9.10.1. If you make use of the definition of lock-root in an explicit way, then there will be no ambiguity and the text can remain the same whenever the successor of RFC4918 comes out.

Best regards,

Werner.

On 13 Dec 2009, at 16:43, Julian Reschke wrote:

> Julian Reschke wrote:
>> ...
>> 3) locking2 (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html#issue.locking2>) ...
> 
> This is the issue we've been discussing over and over again in the past months. It's about whether the vagueness in RFC 4918 about the "lock root" actually is a bug (thus could be fixed with an erratum), or is intentional, allowing different ways to interpret the requirements, and thus differing server behavior.
> 
> I haven't been able to convince enough people that this is an RFC 4918 problem that should be fixed, thus the new strategy to address is is to simply state the problem, and specify which interpretation a WebDAV BIND implementation needs to follow.
> 
> Consequently, the section about locking was upgraded from an appendix to a regular spec section, and now reads:
> 
> -- snip --
> 9.  Relationship to Locking in WebDAV
> 
>   Locking is an optional feature of WebDAV ([RFC4918]).  The base
>   WebDAV specification and this protocol extension have been designed
>   in parallel, making sure that all features of WebDAV can be
>   implemented on a server that implements this protocol as well.
> 
>   Unfortunately, WebDAV uses the term "lock-root" inconsistently.  It
>   is introduced in Section 6.1 of [RFC4918], point 2, as:
> 
>      2.  A resource becomes directly locked when a LOCK request to a
>      URL of that resource creates a new lock.  The "lock-root" of the
>      new lock is that URL.  If at the time of the request, the URL is
>      not mapped to a resource, a new empty resource is created and
>      directly locked.
> 
>   On the other hand, [RFC4918], Section 9.10.1 states:
> 
>      A LOCK request to an existing resource will create a lock on the
>      resource identified by the Request-URI, provided the resource is
>      not already locked with a conflicting lock.  The resource
>      identified in the Request-URI becomes the root of the lock.
> 
>   Servers that implement both WebDAV locking and support for multiple
>   bindings MUST use the first interpretation: the lock-root is the URI
>   through which the lock was created, not a resource.  This URI, and
>   potential aliases of this URI ([RFC4918], Section 5), are said to be
>   "protected" by the lock.
> 
>   As defined in the introduction to Section 7 of [RFC4918], write
>   operations that modify the state of a locked resource require that
>   the lock token is submitted with the request.  Consistent with
>   WebDAV, the state of the resource consists of the content ("any
>   variant"), dead properties, lockable live properties (item 1), plus,
>   for a collection, all its bindings (item 2).  Note that this, by
>   definition, does not depend on the request URI to which the write
>   operation is applied (the locked state is a property of the resource,
>   not its URI).
> 
>   However, the lock root is the URI through which the lock was
>   requested.  Thus, the protection defined in item 3 of the list does
>   not apply to additional URIs that may be mapped to the same resource
>   due to the existence of multiple bindings.
> 
> 9.1.  Example: Locking and Multiple Bindings
> 
>   Consider a root collection "/", containing the two collections C1 and
>   C2, named "/CollX" and "/CollY", and a child resource R, bound to C1
>   as "/CollX/test" and bound to C2 as "/CollY/test":
> 
>                         +-------------------------+
>                         | Root Collection         |
>                         |  bindings:              |
>                         |  CollX          CollY   |
>                         +-------------------------+
>                             |                |
>                             |                |
>                             |                |
>                    +---------------+  +---------------+
>                    | Collection C1 |  | Collection C2 |
>                    | bindings:     |  | bindings:     |
>                    |     test      |  |     test      |
>                    +---------------+  +---------------+
>                             |               |
>                             |               |
>                             |               |
>                            +------------------+
>                            |    Resource R    |
>                            +------------------+
> 
>   Given a host name of "www.example.com", applying a depth-zero write
>   lock to "/CollX/test" will lock the resource R, and the lock-root of
>   this lock will be "http://www.example.com/CollX/test".
> 
>   Thus the following operations will require that the associated lock
>   token is submitted with the "If" request header ([RFC4918], Section
>   10.4):
> 
>   o  a PUT or PROPPATCH request modifying the content or lockable
>      properties of resource R (as R is locked) -- no matter which URI
>      is used as request target,
> 
>   o  a MOVE, REBIND, UNBIND or DELETE request causing "/CollX/test" not
>      being mapped to resource R anymore (be it addressed to "/CollX" or
>      "/CollX/test").
> 
>   The following operations will not require submission of the lock
>   token:
> 
>   o  a DELETE request addressed to "/CollY" or /CollY/test", as it does
>      not affect the resource R, nor the lock-root,
> 
>   o  for the same reason, an UNBIND request removing the binding "test"
>      from collection C2, or the binding "CollY" from the root
>      collection,
> 
>   o  similarly, a MOVE or REBIND request causing "/CollY/test" not
>      being mapped to resource R anymore.
> 
>   Note that despite the lock root being
>   "http://www.example.com/CollX/test", an UNLOCK request can be
>   addressed through any URI mapped to resource R, as UNLOCK operates on
>   the resource identified by the request URI, not that URI (see
>   [RFC4918], Section 9.11).
> -- snip --
> 
> Some of this text is new (the introduction/motivation, and the example), so it would be nice if people understanding both BIND and locking could do a quick check.
> 
> Note that this doesn't really affect the technical contents of BIND: the  behavior with respect to locking is still the same, it's just presented in a different way.
> 
> Best regards, Julian

--
http://www.pincette.biz/
Handling your documents with care, wherever you are.