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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf