BIND, lock root, and clarifying RFC4918

[Lisa Dusseault-3]

I've been discussing the BIND draft's appendix A <http://tools.ietf.org/html/draft-ietf-webdav-bind-25#appendix-A> with Julian, and he asked me to post my opinion publicly.

There are two possible meanings when we discuss "the root of a lock":  this could refer to the resource that was directly locked, or to the URL that was addressed in the LOCK request.  There are cases where RFC4918 definitely uses this phrase to mean resource: "The resource identified in the Request-URI becomes the root of the lock.".  (<http://tools.ietf.org/html/rfc4918#section-7.4>)

The appendix to BIND "clarifies" this by contradicting it, and saying that the lock root is actually the URI.  (Certainly I agree the value of the 'lock-root' element is the URI so at least that's not controversial.)  This "clarification" is justified by needing to explain that the lock does not cover the URIs that are bindings to the resource, other than the URI that was LOCKed.    I don't think there is a need to change the words of 4918 or clarify them; the behavior of bindings can be specified in BIND without that.

With bindings functionality as Julian explains it in email, you can send an UNLOCK request to any binding of a locked resource, even though some of those bindings aren't covered by the lock.  You can also change a binding that's not covered by the lock, so if you lock a resource through a binding in your collection, I can change the name of the binding to the same resource in my collection or remove it.  This behavior makes at least as much sense as any other, but it should be explained explicitly.  I don't think it falls out of the model trivially the same way for everybody reading the BIND document. 

Sometimes with messy, deployed protocols and extensions, it's hard to define a model such that all the behavior simply can be deduced from the model.  Sometimes you have to actually say "it works this way" although it also helps to have the model.

To be clear, since BIND is an experimental document, I think this appendix is pretty harmless to everything except possibly the interoperability of bindings implementations, so I'm not blocking the document or doing anything other than explain my lack of complete agreement.

Lisa

[Geoffrey M Clemm]

The term "lock-root" is introduced and very clearly defined in section 6.1 (Lock Model) to be a URI:

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.  

There are four other occurrences of "lock-root", or "root of the lock" that make it equally clear that the root of a lock is a URI:

Section 6.1 (Lock Model):
If a request causes the lock-root of any lock to become an unmapped URL,

Section 7 (Write Lock):
The list of modifications covered by a write-lock include: ... A modification of the mapping of the root of the write lock,  either to another resource or to no resource

Section 7.4 (Write Locks and Collections):
With a depth-infinity lock, the resource identified by the root of the lock is directly locked

Section 14.12 (lockroot XML Element):
   Name:   lockroot
  Purpose:   Contains the root URL of the lock, which is the URL through which the resource was addressed in the LOCK request.

In section 9.10.1 (not section 7.4), we have the first and only mis-use of the term that was quoted by Lisa:
The resource identified in the Request-URI becomes the root of the lock.

It should have said just "The Request-URI becomes the root of the lock."  

I don't see how anyone could conclude that there are "two possible meanings" of the term lock root.
This single mis-use of the term is clearly just a bug in RFC-4918 that needs to be fixed.

Cheers,
Geoff


Lisa Dusseault wrote on 07/09/2009 12:56:22 PM:

> I've been discussing the BIND draft's appendix A <http://
> tools.ietf.org/html/draft-ietf-webdav-bind-25#appendix-A> with
> Julian, and he asked me to post my opinion publicly.
>
> There are two possible meanings when we discuss "the root of a
> lock":  this could refer to the resource that was directly locked,
> or to the URL that was addressed in the LOCK request.  There are
> cases where RFC4918 definitely uses this phrase to mean resource:
> "The resource identified in the Request-URI becomes the root of the
> lock.".  (<http://tools.ietf.org/html/rfc4918#section-7.4>)
>
> The appendix to BIND "clarifies" this by contradicting it, and
> saying that the lock root is actually the URI.  (Certainly I agree
> the value of the 'lock-root' element is the URI so at least that's
> not controversial.)  This "clarification" is justified by needing to
> explain that the lock does not cover the URIs that are bindings to
> the resource, other than the URI that was LOCKed.    I don't think
> there is a need to change the words of 4918 or clarify them; the
> behavior of bindings can be specified in BIND without that.
>
> With bindings functionality as Julian explains it in email, you can
> send an UNLOCK request to any binding of a locked resource, even
> though some of those bindings aren't covered by the lock.  You can
> also change a binding that's not covered by the lock, so if you lock
> a resource through a binding in your collection, I can change the
> name of the binding to the same resource in my collection or remove
> it.  This behavior makes at least as much sense as any other, but it
> should be explained explicitly.  I don't think it falls out of the
> model trivially the same way for everybody reading the BIND document. 
>
> Sometimes with messy, deployed protocols and extensions, it's hard
> to define a model such that all the behavior simply can be deduced
> from the model.  Sometimes you have to actually say "it works this
> way" although it also helps to have the model.
>
> To be clear, since BIND is an experimental document, I think this
> appendix is pretty harmless to everything except possibly the
> interoperability of bindings implementations, so I'm not blocking
> the document or doing anything other than explain my lack of
> complete agreement.
>
> Lisa

[Julian Reschke]

Lisa Dusseault wrote:

>
> I've been discussing the BIND draft's appendix A
> <http://tools.ietf.org/html/draft-ietf-webdav-bind-25#appendix-A> with
> Julian, and he asked me to post my opinion publicly.
>
> There are two possible meanings when we discuss "the root of a lock":  
> this could refer to the resource that was directly locked, or to the URL
> that was addressed in the LOCK request.  There are cases where RFC4918
> definitely uses this phrase to mean resource: "The resource identified
> in the Request-URI becomes the root of the lock.".  
> (<http://tools.ietf.org/html/rfc4918#section-7.4>)

Actually, that sentence is in Section 9.10.1
(<http://tools.ietf.org/html/rfc4918#section-9.10.1>). It's the sentence
I think RFC 4918 got wrong, and which both the RFC 4918 erratum and the
appendix in BIND try to clarify.

> The appendix to BIND "clarifies" this by contradicting it, and saying
> that the lock root is actually the URI.  (Certainly I agree the value of

Yes.

> the 'lock-root' element is the URI so at least that's not
> controversial.)  This "clarification" is justified by needing to explain

No. The clarification is needed because a specification term can't
identify a URI and a resource at the same time.

It seems you're saying that this inconsistency somehow was deliberate
and serves a purpose. If so, which?

> that the lock does not cover the URIs that are bindings to the resource,
> other than the URI that was LOCKed.    I don't think there is a need to
> change the words of 4918 or clarify them; the behavior of bindings can
> be specified in BIND without that.

BIND does not *need* to explain the locking model, because the RFC 4918
locking model is the same (with 9.10.1 being the exception).

> With bindings functionality as Julian explains it in email, you can send
> an UNLOCK request to any binding of a locked resource, even though some
> of those bindings aren't covered by the lock....

Yes. UNLOCK operates on a resource, and it doesn't matter which URI you
use in order to access it.

> ...  You can also change a
> binding that's not covered by the lock, so if you lock a resource
> through a binding in your collection, I can change the name of the
> binding to the same resource in my collection or remove it...

If that namespace operation does not change the root of the lock (see
RFC 4918, Section 7). Otherwise the request need to include the lock
token (using the "If" header).

> ...  This
> behavior makes at least as much sense as any other, but it should be
> explained explicitly.  I don't think it falls out of the model trivially
> the same way for everybody reading the BIND document.

I think it's the only one that makes sense, and it happens to be the one
defined by RFC 4918.

> Sometimes with messy, deployed protocols and extensions, it's hard to
> define a model such that all the behavior simply can be deduced from the
> model.  Sometimes you have to actually say "it works this way" although
> it also helps to have the model.
>
> To be clear, since BIND is an experimental document, I think this
> appendix is pretty harmless to everything except possibly the
> interoperability of bindings implementations, so I'm not blocking the
> document or doing anything other than explain my lack of complete agreement.
> ...

Lisa, at this point I'd like to get feedback on two questions:

1) Do you maintain the point of view that the language in 9.10.1 of RFC
4918 ("The resource identified in the Request-URI becomes the root of
the lock.") is correct? If so, could you elaborate how it can be parsed
given the fact that the remainder of the spec takes as the "root of the
lock" being a URI, not a resource? (Essentially this is about confirming
the open erratum for RFC 4918).

2) Independently of that, do you think that draft-ietf-webdav-bind-25 is
ready and can be published? I *could* add an example explaining locking
to Appendix A, but I'd really like to understand whether that change
would be sufficient (from your perspective as appsarea AD).

BR, Julian

[Julian Reschke]

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