Subject: progress on WebDAV BIND, was: I-D Action:draft-ietf-webdav-bind-26.txt

From: Julian Reschke <[email-masked]>
Date: Sun, 13 Dec 2009 16:14:53 +0100

Julian Reschke wrote:
> Hi,
> 
> the draft below contains the example for locking behavior in presence of 
> multiple bindings, as proposed a few days ago.
> 
> At this point I'd like to ask those who still have concerns with the 
> specification to verify that the example given matches the locking 
> semantics in RFC 4918.
> 
> If it does not, we'll need to do more work. If if does, then it appears 
> that Appendix A is indeed a clarification of RFC 4918, nothing more.
> 
> BR, Julian
> ...

In the meantime I had a conversation with our AD, trying to identify 
what's left to do. We identified three issues:

1) copying-complex-loops 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html#issue.copying-complex-loops>)

2) bind-vs-hierarchy 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html#issue.bind-vs-hierarchy>)

3) locking2 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html#issue.locking2>)

I'll address the individual issues in separate mails.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 13 Dec 2009 16:30:45 +0100

> (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html#issue.copying-complex-loops>) 

This issue was raised by Robert Sparks during IESG review 
(<https://datatracker.ietf.org/idtracker/ballot/1025/>):

-- snip --

The document provides some discussion of the ramifications of simple 
loops, but its not immediately obvious that the recommendations for 
handling them are sufficient for dealing with more complex loops. Are 
there additional issues introduced when each added level of depth adds 
an exponentially growing number of elements?

(view in fixed width)
         +---------+
         | root    |
         |         |
         |  start  |
         +---------+
              |
              v
         +---------+          +---------+
   +---->| C1      |          | C2      |<---+
   |  +->|         |          |         |<-+ |
   |  |  | a    b  |          | a    b  |  | |
   |  |  +---------+          +---------+  | |
   |  |    |    |               |    |     | |
   |  |    |    |          +----+    |     | |
   |  |    |    |          |         |     | |
   |  |    |    +----------c---+     |     | |
   |  |    |               |   |     |     | |
   |  |    |    +----------+   |     |     | |
   |  |    v    v              v     v     | |
   |  |  +---------+          +---------+  | |
   |  |  | C3      |          | C4      |  | |
   |  |  |         |          |         |  | |
   |  |  | a    b  |          | a    b  |  | |
   |  |  +---------+          +---------+  | |
   |  |    |    |               |    |     | |
   |  +----+    |          +----+    +-----+ |
   |            |          |                 |
   |            +----------c-----------------+
   |                       |
   +-----------------------+

-- snip --

We (the authors) have discussed this, and note that copying complex 
loops works exactly like copying simple loops, and thus adding another 
example isn't necessary.

That being said, we have added an additional explanation, and a short 
statement about complex loops:

-- snip --
2.3.1.  Example: COPY with 'Depth: infinity' in Presence of Bind Loops

    As an example of how COPY with Depth infinity would work in the
    presence of bindings, consider the following collection:

                  +------------------+
                  | Root Collection  |
                  |  bindings:       |
                  |  CollX           |
                  +------------------+
                      |
                      |
                  +-------------------------------+
                  | Collection C1                 |<-------+
                  | bindings:                     |        |
                  | x.gif      CollY              |        |
                  +-------------------------------+        |
                      |            \        (creates loop) |
                      |             \                      |
                  +-------------+   +------------------+   |
                  | Resource R1 |   | Collection C2    |   |
                  +-------------+   | bindings:        |   |
                                    | y.gif     CollZ  |   |
                                    +------------------+   |
                                        |         |        |
                                        |         +--------+
                                        |
                                    +-------------+
                                    | Resource R2 |
                                    +-------------+

    If a COPY with Depth infinity is submitted to /CollX, with
    destination of /CollA, the outcome of the copy operation is that a
                                                                     *
    copy of the tree is replicated to the target /CollA:
    ***************************************************

                 +------------------+
                 | Root Collection  |
                 |  bindings:       |
                 |  CollX     CollA |
                 +------------------+
                    |           |
                    |           +---------------------------+
                    |                                       |
                 +-------------------+                      |
                 | Collection C1     |<------------------+  |
                 | bindings:         |                   |  |
                 | x.gif      CollY  |                   |  |
                 +-------------------+                   |  |
                    |            \        (creates loop) |  |
                    |             \                      |  |
                 +-------------+   +-----------------+   |  |
                 | Resource R1 |   | Collection C2   |   |  |
                 +-------------+   | bindings:       |   |  |
                                   | y.gif     CollZ |   |  |
                                   +-----------------+   |  |
                                       |         |       |  |
                                       |         +-------+  |
                                       |                    |
                                   +-------------+          |
                                   | Resource R2 |          |
                                   +-------------+          |
                                                            |
                            +-------------------------------+
                            |
                 +-------------------+
                 | Collection C3     |<------------------+
                 | bindings:         |                   |
                 | x.gif      CollY  |                   |
                 +-------------------+                   |
                    |            \        (creates loop) |
                    |             \                      |
                 +-------------+   +-----------------+   |
                 | Resource R3 |   | Collection C4   |   |
                 +-------------+   | bindings:       |   |
                                   | y.gif     CollZ |   |
                                   +-----------------+   |
                                       |         |       |
                                       |         +-------+
                                       |
                                   +-------------+
                                   | Resource R4 |
                                   +-------------+

    Note that the same would apply for more complex loops.
    ******************************************************
-- snip --

(new bits marked with "*" characters).

We hope that this addresses this comment.

Note a new draft has not yet been submitted, for now the changes can be 
seen in context at 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.copying-complex-loops> 
and 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest-from-previous.diff.html>.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 13 Dec 2009 16:43:55 +0100

> (<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

---

From: Julian Reschke <[email-masked]>
Date: Sun, 13 Dec 2009 20:44:12 +0100

> (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html#issue.bind-vs-hierarchy>) 

I have added the following note to the introduction of Section 2:

-- snip --
       Note: the collection model described herein is not compatible with
       systems in which resources inherit properties based solely on the
       access path, as the ability to create additional bindings will
       cause a single resource to appear as member of several different
       collections at the same time.
-- snip --

Also, the section about the WebDAV ACL spec has been rewritten to make 
clear that it doesn't have a problem with multiple bindings; it now reads:

-- snip --
10.  Relationship to WebDAV Access Control Protocol

    Note that the WebDAV Access Control Protocol has been designed for
    compatibility with systems that allow multiple URIs to map to the
    same resource (see [RFC3744], Section 5):

       ...Access control properties (especially DAV:acl and DAV:
       inherited-acl-set) are defined on the resource identified by the
       Request-URI of a PROPFIND request.  A direct consequence is that
       if the resource is accessible via multiple URI, the value of
       access control properties is the same across these URI. ...

    Furthermore, note that BIND and REBIND behave the same as MOVE with
    respect to the DAV:acl property (see [RFC3744], Section 7.3).
-- snip --

Diffs, as usually, at 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html> 
and <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html>.

Feedback appreciated,

Julian

---

From: Werner Donné <[email-masked]>
Date: Mon, 14 Dec 2009 09:58:20 +0100

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 --
> 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.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 14 Dec 2009 10:10:23 +0100

> 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 o…

Hi Werner,

it appears you are agreeing with what the published BIND specs say, and 
what I have reported as erratum for RFC 4918 in 
<http://www.rfc-editor.org/errata_search.php?eid=1207>. That's good to 
know, but I have failed to convince the author and the chairs about this 
back before publication of RFC 4918, and also failed to convince the 
IESG later on.

Thus the revised proposal that just states that RFC 4918 is ambiguous, 
and that servers that want to support BIND need to follow a more 
specific definition.

Best regards, Julian