summary of BIND/RFC2518 status

Hi,

in this mail, I'll try to clarify both the current state of things and 
what Geoff and I are actually proposing.

Let's start with some facts that we hopefully all agree on.


1) Multiple URIs mapping to the same resource are not introduced by the 
BIND spec. They've been a fact of live for HTTP per se, are explicily 
mentioned in RFC2518, and can be created as side effect in some RFC3253 
operations. The BIND spec doesn't introduce bindings as new feature; it 
only clarifies some namespace operations, adds authoring methods for 
*explicitly* creating new bindings; adds discovery mechanisms and error 
marshalling.

2) Locking is a useful, but *optional* feature of RFC2518. Many clients 
require locking to be able to author a resource, for instance MS Office. 
However, there are valid server implementation scenarios where locks 
won't be available, and clients will have to cope with that as well. In 
many cases, strong ETags are more useful than locking. Ideally a server 
provides both.

3) RFC3253, RFC3648 and ACL (RFC to be published soon) work both with 
and without locking. In particular, they don't specify any specific lock 
behaviours; the just rely on the base document RFC2518.

4) The locking definitions in RFC2518 need to be updated; most if not 
all issues are on the RFC2518 issues list 
(<http://www.webdav.org/wg/rfcdev/issues.htm>). This includes extensions 
(DAV:lockroot, If header syntax), clarifications (LOCK operation 
returning Lock-Token header, DAV:owner content...), simplifications (get 
rid of special lock-null resources, simplify lock refresh). It also 
should include an updated general description of write lock behaviour, 
which should be identical to what we wrote down in GULP 
(<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0001.html>).


Given this base, I personally conclude:

A) We should avoid a situation where optional specs need to specifically 
define interaction with other optional features. Rather than that, that 
interaction should follow from the definition in the base spec. If the 
base locking model is clear about where state resides, and what a lock 
protects, the additional semantics for new features (such as versioning, 
or ACL) will follow automatically.

A1) Example: the ACL spec that the IETF just accepted does not state 
that if a resource is locked, you'll need to provide the lock token in 
the request to modify the ACL. It doesn't need to, because the spec 
states that the ACL belongs to the state of the resource. Similar 
considerations apply to versioning and ordering methods.

B) WebDAV's locking definitions needs to be fixed and updated. 
Optimally, this would be done in RFC2518bis; but for reasons that I 
currently don't understand this spec doesn't seem to progress at all.

C) A big part of what changes in RFC2518bis relates to locking. On the 
other hand, locking is the area where we have/had the most 
interoperability problems. If we can't get RFC2518bis finished in the 
near future, it makes sense to extract all this information into a 
separate document (starting at standards level "proposed").

D) This separate document shouldn't be an appendix to BIND, because it's 
relevant to all WebDAV specs, not only BIND. In particular, people not 
interested in BIND may not even be aware of this appendix. For the same 
reason, we should now last-call BIND. This is the best way to find out 
about other possible issues unrelated to the locking question.

E) If we decide to clarify/update outside the RFC2518bis spec, we need 
support for that activity from the WG in general and the RFC2518bis 
authors in particular. A "fork" in the locking spec is a no-no. Whatever 
the new document says *must* be repeated (modulo fixes) in RFC2518bis, 
unless...

F) ...we publish a standalone document that fully specifies WebDAV 
locking and updates RFC2518 (in which case, locking can simply be 
removed from RFC2518bis). This is what Geoff and I are both proposing 
*and* volunteering to do.

G) It was said that this very discussion is the reason for the slow 
progress of RFC2518bis. In fact, this discussion has started *because* 
of the slow progress. Removing the optional locking feature from 
RFC2518bis will make that spec more manageable and will cause it to 
contain much less *changes* from RFC2518, probably making the transition 
to "Draft" much easier.

Ted, Patrik: I'll assume that removing an optional feature from a spec 
when going from "Draft" to "Proposed" is absolutely ok. If I'm wrong 
here, please clarify.



Feedback appreciated,

Julian



-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Friday, 9 April 2004 05:26:14 UTC