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

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

Received on Wednesday, 17 January 2007 12:46:31 UTC