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

IETF meeting comments

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 27 Jul 2004 21:57:43 +0200
Message-ID: <4106B3B7.7000601@gmx.de>
To: w3c-dist-auth@w3c.org


I'll not be able to attend the meeting, neither personally, nor using 
the text conferencing facilities. BTW: will the meeting actually take 
place? I'm asking because it's in one week, and no agenda has been posted.

Anyway, here's what I think *should* be discussed primarily:

The BIND spec has been stuck in it's current (IMHO finished) state for 
several months now, and the updated working group charter 
(<http://www.ietf.org/html.charters/webdav-charter.html>) says it should 
have been (wg-) last-called two months ago. This hasn't happened.

Note the current BIND spec is version 06 (HTML: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-06.html>, TXT: 
issues list: 

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.

As far as other specs are concerned (SEARCH, REDIRECT), I expect to get 
back to them as soon as we have made progress on the BIND issue.

Best regards, Julian

<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 27 July 2004 15:58:34 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:30 UTC