bind issue: locking2

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

Received on Sunday, 13 December 2009 15:44:42 UTC