Re: I-D Action:draft-ietf-webdav-bind-26.txt

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: I-D Action:draft-ietf-webdav-bind-26.txt

Julian Reschke
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


[hidden email] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> Title           : Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)
> Author(s)       : G. Clemm, et al.
> Filename        : draft-ietf-webdav-bind-26.txt
> Pages           : 50
> Date            : 2009-09-11
>
> This specification defines bindings, and the BIND method for creating
> multiple bindings to the same resource.  Creating a new binding to a
> resource causes at least one new URI to be mapped to that resource.
> Servers are required to ensure the integrity of any bindings that
> they allow to be created.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-26.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> I-D-Announce mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
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

Reply | Threaded
Open this post in threaded view
|

bind issue: copying-complex-loops

Julian Reschke
Julian Reschke wrote:
> ...
> 1) copying-complex-loops
> (<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

Reply | Threaded
Open this post in threaded view
|

bind issue: locking2

Julian Reschke
In reply to this post by Julian Reschke
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

Reply | Threaded
Open this post in threaded view
|

bind issue: bind-vs-hierarchy

Julian Reschke
In reply to this post by Julian Reschke
Julian Reschke wrote:
> ...
> 2) bind-vs-hierarchy
> (<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

Reply | Threaded
Open this post in threaded view
|

Re: bind issue: locking2

Werner Donné
In reply to this post by Julian Reschke
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.


Reply | Threaded
Open this post in threaded view
|

Re: bind issue: locking2

Julian Reschke
Werner Donné wrote:

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

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