Re: new stuff in draft edits

> a few questions:
>
> - how many people have been reviewing each of these drafts?

I have been doing my level best to keep up with list traffic, but  
have not performed a complete draft read in some time. I usually  
prefer to do a fewer number of deep readings rather than try to scan  
each minor draft rev.

>
> - 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.

>
> - 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.

>
> 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.

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.

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.

- Jim