Re: BIND, lock root, and clarifying RFC4918

Julian Reschke wrote:
> ...

Hi,

in order to make progress on this issue, I just added an example to the 
appendix which shows how the definition of "lock-root" is critical when 
a locked resource is addressable through multiple bindings.

Minimally, this should clarify that the locking model required for BIND 
actually *is* the one defined in RFC 4918, albeit in a potentially 
confusing way in 4918.

See 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.A>, 
the full text now being:

-- snip --
Appendix A.  Clarification to RFC4918 Usage of the Term 'Lock Root'

    [RFC4918], Section 9.10.1 claims:

       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.

    This is misleading in that it implies that the "lock root" is the
    directly locked resource, not the URI through which the lock was
    requested (see
    <http://www.rfc-editor.org/errata_search.php?eid=1207>).  As a matter
    of fact, other parts of the specification use the term "lock-root" to
    talk about that URI (see [RFC4918], Section 6.1, Item 2, and Section
    14.12).  With that definition, it becomes clear that a lock affects
    the resource identified by the Request-URI (plus optionally its
    descendants), plus the URI through which the lock was requested, but
    not URIs mapped to that resource due to the existence of additional
    bindings.

    A clearer description would be:

       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 Request-URI
       becomes the "lock-root" of the lock.

    Note that this change makes the description consistent with the
    definition of the DAV:lockroot XML element in Section 14.12 of
    [RFC4918].

A.1.  Example: Locking and Multiple Bindings

    This example shows how the clarification above is relevant when a
    locked resource is addressable through multiple bindings.

    Consider an the 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 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 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 --

I intend to submit a new I-D in the next few days, so feedback on 
correctness and completeness of this example would be appreciated.

BR, Julian

Received on Saturday, 5 September 2009 15:31:30 UTC