Re: new stuff in draft edits

Jim Whitehead wrote:
>> - can anybody say with confidence what has changed since RFC2518?
> 
> 
> Um, isn't this what diff tools are for? If we can't do a reasonable 
> diff, then perhaps we should move back to Word. It provides much better 
> visibility for fine-grain changes.

We can get a reasonable diff (now that we have XML version of both), see 
for instance 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-latest-from-rfc2518.diff.html>. 
  I guess this is the format people should be reviewing.

>> - does any server implementor think that (s)he has a compliant 
>> implementation of what's in?
> 
> 
> Given that we are discussing a small number of minor new features (such 
> as force-authenticate), the answer should be none.

Given the fact that we think we have only a small number of changes, 
shouldn't the answer be: almost all of them? (at least of those reading 
this list?)

>> The fact that we only have little participation nowadays even makes it 
>> more important that those who want to contribute it can do that 
>> effectively. Right now, I don't have the impression that the time I 
>> have spent in the past years has been effective at all.
> 
> 
> My view is quite different. Due to your contributions we have a rich set 
> of issues that have been documented, and we have gone some way towards 
> resolving a large number of them.
> 
> What we need to complete this revision process is active commitment from 
> the remaining active working group members. We currently have this. We 
> have an active document editor who is producing new drafts on a timely 
> basis. We have several WG members actively engaging remaining issues, 
> and a commitment to work towards consensus on remaining issues.
> 
> I know you are frustrated by the fact that text is appearing in the 
> drafts between revisions that you don't feel represents WG consensus. 
> Reflecting on the drafting of 2518, the design team sometimes shoved in 
> lots of stuff between revisions that was never agreed upon by the list 
> first. That's why we issued drafts, and then solicited comments on them. 
> That's also why we usually had a Word version of the document with 
> change tracking turned on, so people could easily see all of the 
> changes. Many times people ripped our heads off for the problems that 
> were introduced.
> 
> My personal view is the use of XML for the draft is part of the problem. 
> In order to actually read the draft, I have to download it from the 
> editing site, put it in a location where all of the stylesheets are 
> present (after finding and downloading them too). Then I have to use 
> diff, whose output is tedious to understand, to understand the 
> differences between versions. I'm no fan of Word, but its change 
> tracking feature and visibility of changes seems like it's *exactly* 
> what we need right now. The other advantage of Word is its ability to 
> let multiple authors work directly on the specification, since you can 
> see exactly what edits have been performed.

Well, sounds like pre-generated HTML with change tracking (hyper-linked 
to an issues list) is a good thing. It's not like it's impossible to get 
that with XML (check the drafts I've been editing, for instance 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12.html>).

> Finally, while I know its frustrating to have to monitor changes made to 
> the draft, I don't see how this is anything other than an essential 
> difficulty of producing a protocol specification. Anyone acting document 
> editor is likely to add text into the specification, in a good faith 
> effort to resolve an issue, that doesn't meet the approval of the rest 
> of the working group. Roy sometimes got beat up for changes he made to 
> the HTTP/1.x specifications when he was editor (and there were often 
> complaints that he wasn't making drafts fast enough). Geoff would often 
> insert large chunks of text into the Delta-V specification, and then go 
> to the list to build consensus around them. It's not reasonable to 
> expect every text change to be vetted by the list first. It also doesn't 
> reflect current IETF practice, even in our own community.

That's true, but I bet in these cases the changes were at least reported 
to the list, discussed there, and taken out when there was no consensus. 
I personally prefer drafts that represent the WG consensus at time of 
submission. But as long as the process that's used ensures that the 
result is ok, that's fine with me as well.

Right now we have the situation that feedback to previous drafts usually 
was ignored, thus the long backlog on issues we now have to go through. 
This definitively is frustrating, and please don't blame people when 
they start considering how to invest their time in a more efficient way.

> What we do seem to have is a change visibility problem. Moving back to 
> Word would be a big step in the direction of solving this. If we use a 
> reasonable document model, converting back to XML at the end shouldn't 
> be too heinous.

IMHO, it's definitively not XML which is the problem. In the end, we 
need to provide an ASCII version, and that works *much* better using 
xml2rfc. Last time we produced a draft with Word (RFC3744) it's 
formatting was so bad that we had to go through an additional 
edit/submission cycle to get it right.

Best regards, Julian

Received on Wednesday, 19 October 2005 17:30:52 UTC