- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 09 Jun 2009 00:23:31 +0200
- To: WebDAV <w3c-dist-auth@w3.org>
- CC: Alexey Melnikov <alexey.melnikov@isode.com>, Cyrus Daboo <cyrus@daboo.name>
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
Received on Monday, 8 June 2009 22:24:18 UTC