W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2004

BIND issue "locking", was: I-D ACTION:draft-ietf-webdav-bind-07.txt

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 15 Oct 2004 21:27:35 +0200
Message-ID: <417024A7.4040700@gmx.de>
To: Lisa Dusseault <lisa@osafoundation.org>
CC: w3c-dist-auth@w3.org

<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0016.html> and

This is in fact *the* permathread which is IMHO caused by the fact that 
the locking semantics in RFC2518 are underspecified (because of which 
the working group has produced a summary of locking semantics that 
should go into RFC2518bis which is called "GULP", latest version at 

As far as I can tell from re-reading the whole thread, there was nobody 
(except Lisa) particulary asking for adding LOCK clarifications into the 
BIND spec itself, because these clarifications are needed completely 
independantly of BIND. So they should either appear in RFC2518bis or  in 
a separate WebDAV locking spec (as suggested and demonstrated by myself).

To summarize: this is not really an issue with the BIND spec, but with 
how this working group is approaching the various locking related 
problems in RFC2518. My (latest) summary about this issue can be found 
and I think it would be good if the working group would finally start a 
discussion about it:

"As far as I can tell, the only remaining open question is whether
RFC2518's treatment of locks is sufficient to explain the relation
betweem (multiple) bindings and locks. The (active) authors of the spec
(Geoff and myself) agree that the BIND spec is compatible with what
RFC2518 says about locks, and no further clarification is stricly
required. Note that RFC2518 already talks about locking "replicated
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.3>), so
this has been explicitly planned for even back then. The important fact
here being that multiple bindings to a resource and locks are already
compatible, and nothing needs to ne explicitly changed for that.

Now, how should that spec proceed? There seem to be several options,

#1) Just release the BIND spec as is (that is, immediately do a WG last

#2) Add locking specific clarifications to BIND, then release it,

#3) Release the BIND spec with a normative reference to RFC2518bis
(essentially delaying it until RFC2518bis is finished) or

#4) Extract locking out of RFC2518bis into a separate spec, resolve all
open locking-related issues, and submit this as a new specification
(updating RFC2518) for publication as a proposed standard (note there's
a long summary about this option posted by me in April (!):
Note that none of these open locking issues (those listed on RFC2518's
issues list at <http://www.webdav.org/wg/rfcdev/issues.htm> actually has
*anything* to do with the relation to multiple bindings). BIND then can
either be released independantly or with a normative reference to that
new spec.

Personally I see nothing wrong with option #1. Several implementors
already have BIND working experimentally as defined in the spec (for
instance Apache Slide and SAP in Netweaver). More people seem to look at
it but may be waiting for it to become an RFC. Unless there's an actual
risk of people misunderstanding BIND and lock interactions (something we
*could* take care of on this mailing list), having possible lock
clarifications appear in something published slightly later doesn't seem
to be any problem at all.

#2 IMHO would be an *extremely* bad idea, because it would duplicate
specification text in several specs, so spec revisions either need to be
100% compatible with it; or BIND would soon need to be updated itself by
these revisions. So there'd be additional work and risk of being
inconsistent with very little gain. Remember that support for multiple
bindings and locking are completely separate things (you can have
multiple bindings on a server without locking support because locking is
an *optional* WebDAV feature).

#3 makes sense if RFC2518bis is actually going to be finished anytime
soon. I made my contribution by pushing for resolutions for almost all
locking-related questions; but it's up to the authors to give an
estimate about when it can be done. (I'll try to review the new draft
before next week; and it would be good if others would do that as well).

#4 is the option I've been working on the last three months (HTML:
issues list:

As far as I'm concerned, this spec is almost done (with the notable
exception of finding the right place for the GULP summary and discussing
the locking-related questions of "If" header semantics). Even if the
working group decides not to adopt this as a WG document, the effort
still will have been worth it for the progress we've been making on open
locking issues. Of course I personally would like to see this to be used
as a basis for a new specification so that the locking feature can be
removed from RFC2518bis. This would actually make it *easier* for
RFC2518bis to progress to a "draft" standard, because it would be
significanly simplified.
In the case the WG makes that decision, I'll happily work together with
volunteers to finish this as a working group document."

I still think that no harm is done by just releasing BIND with no 
changes (option #1) -- as a matter of fact it represents the consensus 
of various implementors *and* running code. This way we get the top 
priority from our working group's agenda done, and we can concentrate on 
the next steps (being RFC2518bis and the RDEDIRECT spec).

Best regards, Julian

<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Friday, 15 October 2004 19:28:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:32 UTC