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

[Ted Hardie <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf