Does WebDAV BIND attempt to *change* RFC4918?

[Julian Reschke <[e-mail]>]

Hi,

the IESG discussed WebDAV BIND last week, and apparently some of the ADs
came to the conclusion that it attempts to redefine aspects of RFC
4918, in particular through the clarification it proposes in Appendix
A (<http://tools.ietf.org/html/draft-ietf-webdav-bind-24#appendix-A>).

This is incorrect. In general, the BIND specification has been carefully
written so it does not require any behavior that would be incompatible
with RFC 3253 (Delta-V), RFC 3744 (ACL), or RFC 4918 (Base WebDAV). In
particular, while RFC 4918 was discussed, we (the WebDAV WG) made sure 
that it would  be clarified so that it became *possible* to specify BIND 
without changing WebDAV. Changes we made in RFC 4918 for that purpose 
(and also to better align with Delta-V) were:

- clarifying DELETE,

- clarifying the *additional* effects of a WebDAV lock on the URI it was
requested for (in addition to the resource itself being protected), and

- not requiring servers to implement COPY/Overwrite as implied DELETE on
the target (this allows keeping versioning information for DeltaV, and
the resource's identity for BIND).

So, again, all these changes are in RFC 4918!

The one thing BIND tries to do in Appendix A is to address a terminology
bug in RFC 4918, which, when talking about the "lock-root" or root of a
lock, *most* of the times refers to it as the URI through which the
resource was locked, and only in one place implies that it identifies a
resource. That is an inconsistency in RFC 4918, which, for systems that
do not support multiple bindings, is mostly harmless, but becomes
confusing in the multiple-binding case.

Due to the aforementioned feedback I've gone again through RFC 4918,
double-checking all mentions of "root" in the context of locking
(results attached at the end of the mail). I have also revised Appendix
A to be more precise on what the problem is that is being solved, and
also slightly revised the proposed replacement text for RFC 4918. Here
we go:

-- snip --

Appendix A.  Clarification to RFC2518bis' 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].

-- snip -- 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.A>

I hope this clarifies this issue.

Best regards,

Julian

-- snip --
Appendix: use of the term "root" in the context of locking in RFC 4918

I have inlined my analysis of what's meant in each case (look out for 
"JR:").


6.1.  Lock Model

    This section provides a concise model for how locking behaves.  Later
    sections will provide more detail on some of the concepts and refer
    back to these model statements.  Normative statements related to LOCK
    and UNLOCK method handling can be found in the sections on those
    methods, whereas normative statements that cover any method are
    gathered here.

    1.  A lock either directly or indirectly locks a resource.

    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.

JR: introduces the term "lock-root" the first time, and makes it a URL. (a)

        ...

    8.  If a request causes the lock-root of any lock to become an
        unmapped URL, then the lock MUST also be deleted by that request.

JR: for the lock-root to *become* an unmapped URL, it needs to be a URL. (b)



7.  Write Lock

    ...

    3.  A modification of the mapping of the root of the write lock,
        either to another resource or to no resource (e.g., DELETE).

    ...

JR: uses the term "root of the ... lock" as indicating a URL ("mapping
to a ... resource") (c)

    ...

7.4.  Write Locks and Collections

    ...

    In addition, a depth-infinity lock affects all write operations to
    all members of the locked collection.  With a depth-infinity lock,
    the resource identified by the root of the lock is directly locked,
    and all its members are indirectly locked.

JR: "resource identified by the root of the lock", so it's talking about
the URI (d)

    ...


9.6.  DELETE Requirements

    DELETE is defined in [RFC2616], Section 9.7, to "delete the resource
    identified by the Request-URI".  However, WebDAV changes some DELETE
    handling requirements.

    A server processing a successful DELETE request:

       MUST destroy locks rooted on the deleted resource

JR: uses "rooted", the difference between URL and resource isn't 
significant here I think (e)

       MUST remove the mapping from the Request-URI to any resource.

    ...

    Thus, after a successful DELETE operation (and in the absence of
    other actions), a subsequent GET/HEAD/PROPFIND request to the target
    Request-URI MUST return 404 (Not Found).

    ...

9.10.1.  Creating a Lock on an Existing Resource

    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.  LOCK method requests

JR: resource, not URL (f)

    to create a new lock MUST have an XML request body.  The server MUST
    preserve the information provided by the client in the 'owner'
    element in the LOCK request.  The LOCK request MAY have a Timeout
    header.

    ...


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.

    Description:   The href element contains the root of the lock.  The
       server SHOULD include this in all DAV:lockdiscovery property
       values and the response to LOCK requests.

    <!ELEMENT lockroot (href) >

JR: "The href element contains the root of the lock", *not "...the URI 
of the root..."; but that is clear anyway, as you can't put a resource 
into an XML element :-) (g)
    ...

16.  Precondition/Postcondition XML Elements

    ...

    Name:  no-conflicting-lock (precondition)

    Use with:  Typically 423 Locked

    Purpose:  A LOCK request failed due the presence of an already
       existing conflicting lock.  Note that a lock can be in conflict
       although the resource to which the request was directed is only
       indirectly locked.  In this case, the precondition code can be
       used to inform the client about the resource that is the root of
       the conflicting lock, avoiding a separate lookup of the
       "lockdiscovery" property.

    <!ELEMENT no-conflicting-lock (href)* >

JR: this is another case where it's used for the resource (h), maybe it 
should be clarified as well