Ted Hardie schrieb:
At 5:42 PM +0100 1/15/07, Julian Reschke wrote:
(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.
It is certainly also true that the working group has very little energy, and that collecting
the required interoperability data would have likely failed. The document's listing
of changes since RFC 2518 shows several items, though, that would have caused
a recycle at Proposed no matter what energy level was present in the group. If
you see "are now required" in the listed behavior where it was not before, it
would likely have forced a recycle. As it stands, though, the key point is that this
is a replacement-in-place for 2518 and that there is no apparent energy for
a successor aiming at Draft any time soon.
Well, I still think you aver over-estimating the amount of changes that
were made. As far as I can tell, the spec mainly followed the rule of
documenting what the widely deployed servers already did. Also, I do
think that most of the "changes" are implemented in at least two
different servers, and are compatible with existing clients, so it would
have been possible to pass the criteria for "Draft" (except for lack of
energy for addressing the administrative hurdle).
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.
Reviewers are certainly welcome to look at the issue tracker and the proposed
alternative draft. But any reviewer doing so should also look at the working
group archives. The discussion and efforts by the WG chair and his predecessors
to achieve consensus and forward progress are noted there, and there have
been multiple attempts to use teleconferences etc. to move things forward as
well.
Yes. I also highly recommend to look at the archive for 2006, during
which last call comments were sent to the mailing list (and not addressed).
As the Last Call requests, reviewers are requested to consider the question:
"Is this better than the document it replaces"? That it could be better yet
is obviously true, but that has to be understood in the context of the WG's
rate of progress.
Please also consider the questions "Do we want to publish a document
that already has a long list of errata?" and "Can we do much better than
that with little effort?".
(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).
The locking issue was raised by Julian prior to last call to me and to Cullen as WG chair.
Repeated. It has been raised on this mailing list before.
It was the subject of a specific question of mine in a solicited review request sent
prior to making the IETF Last Call. I have been waiting on permission to forward those
to the IETF list; lacking that, I have entered the responses in the draft tracker as
"solicited review one" and "solicited review two". They can be read here:
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=8360&rfc_flag=0
These solicited reviews also recommend changes to the locking text and I expect
to see updated text discussed on the WG mailing list prior to the document
going to the IESG.
Thanks. It's good if these things are addressed, but keep in mind that I
mentioned them in my feedback as *examples*, not as a complete list of
thins that should be changed.
Best regards, Julian
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf