- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 27 Jul 2004 21:57:43 +0200
- To: w3c-dist-auth@w3c.org
Hi, 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: <http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-06.txt>, issues list: <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html>). 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 resources" (<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, including: #1) Just release the BIND spec as is (that is, immediately do a WG last call), #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 (!): <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0049.html>). 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: <http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-05.html>, TXT: <http://www.ietf.org/internet-drafts/draft-reschke-webdav-locking-05.txt>, issues list: <http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-issues.html>). 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