Re: Last Call: draft-ietf-webdav-rfc2518bis (HTTP Extensions for Distributed Authoring - WebDAV) to Proposed Standard

The IESG schrieb:
> The IESG has received a request from the WWW Distributed Authoring and Versioning WG (webdav) to consider the following document:
>
> - 'HTTP Extensions for Distributed Authoring - WebDAV '
>    <draft-ietf-webdav-rfc2518bis-17.txt> as a Proposed Standard
> ...

The short answer: this draft fixes a number of well-known problems in RFC2518, removes some unimplemented features, and adds some minor improvements. Some parts of the spec are clearly better than before, others are worse in that they replace the description of locking by new text which is unnecessarily confusing, partly incorrect and inconsistent. As such, the document should not be approved and published in its current state.

The long answer:

(1) History of this Last Call

RFC2518bis has been under development for an extremely long time, starting almost five (!!!) years ago. Up until autumn 2005 however, there was only very little activity. When faced with the alternative to either shut down the working group, or to produce a usable document in a relatively short of time, the most active members of the working group decided to give it a try.

Draft 14 was (WG) last-called in February 2006, containing lots of improvements, but also a new section about locking which had had almost no review (being added in draft 12, published the same month). The last call basically happened not because the working group thought that the document was ready, but to make the deadline.

After the WG Last Call, we have seen fewer reviews than we hoped for, but certainly not many. The majority of issues raised during LC (and later on) have not been addressed at all in the WG's document. Basically, there has been almost no activity on the WG's document since.

At the time of this writing, there were over fifty issues opened against the specification (see <http://ietf.osafoundation.org:8080/bugzilla/buglist.cgi?product=WebDAV-RFC2518-bis>). For many of them there were suggestions resolving the problems with spec-ready text (all mention some of them later on).


(2) Compatibility with RFC2518

The Last Call announcement states:

> While the WEBDAV working group was originally chartered to produce a
> draft standard update to RFC 2518, this documented is being targeted
> as a replacement Proposed Standard because of a number of substantive
> changes to the original semantics.

This is completely inaccurate. None of the original semantics has been changed substantively at all. The main reason why the WG didn't try to achieve Draft Status was because there was not sufficient energy for collecting the required interoperability data. We also realized that some of the minor improvements we made weren't widely implemented (nor not implemented at all), and thus decided it would make more sense doing a revision that stays at the stage of a Proposed Standard.

As a matter of fact, it was long discussed whether a new compliance level (Section 18.3) was required at all. As far as I can tell, the only change for which the new compliance level helps at all is the ability to find out about the server's support for absolute paths in the "If" and "Destination" header.


(3) Alternatives offered by the IESG

The announcement goes on saying:

> A key question for reviewers is whether
> this document is substantially better than RFC 2518 and should
> replace it.

For many of the open issues there *are* proposals how to resolve them. The recommended changes are recorded both in the issue tracker (<http://ietf.osafoundation.org:8080/bugzilla/buglist.cgi?product=WebDAV-RFC2518-bis>) and an experimental draft available at <file:///C:/projects/xml2rfc/draft-reschke-webdav-rfc2518bis-latest.html>. The latter does not resolve *all* open issues *yet*, mainly in an attempt to keep the differences to the Working Group's document to a manageable size.

So I would appreciate if reviewers not only take a look at RFC2518 and the Last Call draft, but also to the resources above.


(4) Examples for open issues

(4a) One of the things RFC2518bis was supposed to fix was the confusion around locking. Right now, it fails big time. For instance, it fails to consistently distinguish between the "owner" and the "creator" of a lock (issue 244), and is inconsistent with respect to the term "lock root" (sometime it say it's a URI, sometimes it says it's a resource; which is a significant difference when a resourse is identified by multiple URIs) (issue 251).

(4b) Unnecessary new requirements: an example is the new (MUST-level) requirement to submit a Depth header with PROPFIND (issue 213). This is just one of several cases where the draft made changes for no apparent reason; that is, there was no problem with what RFC2518 said previously.

(4c) Issue 237 raises a security issue that isn't discussed in RFC2518, and I think it's quite important. As far as I can tell, there's some sort of agreement that this really is a user agent problem. That being said, all user agents expose this problem, and the W3C WEBAPI working group was quite unresponsive when it was mentioned. Thus, it seems to me that RFC2518bis *minimally* needs to minimally mention the problem, making server implementors/admins at least aware.

I could go on and on, but all of this is in the issue tracker, and has been known to the working group.


Best regards, Julian

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Received on Monday, 15 January 2007 16:49:44 UTC