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