Subject: new stuff in draft edits

From: Julian Reschke <[email-masked]>
Date: Sun, 16 Oct 2005 18:10:23 +0200

Hi,

I was looking at the current edits and couldn't help noticing that it 
again contains stuff that wasn't announced at all. As far as I can tell, 
drafts submitted to the IETF should optimally represent the working 
group's consensus, and putting in stuff silently into the working edits 
doesn't seem to be the best way to achieve this.

In particular:

1) "Hosting malicious scripts executed on client machines" 
(http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-latest.html#rfc.section.19.8>) 
looks interesting; but I don't see an issue raised for this topic. In 
particular, the recommendation to strip script from HTML pages looks a 
fishy (upon GET? PUT? for all users?). This certainly needs more 
discussion if this should be added to the spec.

2) Summary of changes from RFC2518 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-latest.html#rfc.section.B.3.1>):

> B.3.1  Summary of changes from RFC2518
> 
>    This section describes changes that are likely to result in
>    implementation changes due to tightened requirements or changed
>    behavior.  A more complete list of changes has been published in a
>    separate document.

Really? I think readers of the spec really would prefer to have a 
complete (not only a "more complete") list right here.

> B.3.1.1  Changes Notable to Server Implementors
> 
>    Tightened requirements for storing property  values (Section 4.4)
>    when "xml:lang" appears and also when values are XML fragments
>    (specifically on preserving prefixes, namespaces and whitespace.)
> 
>    Several tightened requirements for general response  handling
>    (Section 8.1), including response bodies for use with errors, use of
>    Date header, ETag and Location header.

- The response bodies for errors are optional, right?
- What did change regarding the other response headers?

>    Tightened requirements for URL construction in PROPFIND (Section 8.2)
>    responses.
> 
>    Tightened requirements for checking identity of lock  owners
>    (Section 7.1) during operations affected by locks.
> 
>    Tightened requirements for copying properties (Section 8.9.2) and
>    moving properties (Section 8.10.1).

(to be discussed)

>    Tightened requirements on preserving owner field in locks
>    (Section 8.11).  Added "lockroot" element to lockdiscovery
>    information.
> 
>    New value for "DAV:" header (Section 9.1) to advertise support for
>    this specification.
> 
>    Tightened requirement for "Destination:"  header (Section 9.3) to
>    work with path values
> 
>    New "Force-Authentication:" (Section 9.4) header added.
> 
>    Several changes for "If:" header (Section 9.5), including requirement
>    to accept commas and "DAV:no-lock" state token.

"DAV:no-lock" is no new requirement.

>    Support for UTF-16 now required (ref (Section 18)).

I don't think the requirement changed. The spec merely wasn't properly 
repeating what XML defines, and this was fixed.

>    Removed definition of "source" property and special handling for
>    dynamic resources
> 
>    Replaced lock-null resources with simpler locked empty resources
>    (Section 7.6)
> 
> B.3.1.2  Changes Notable to Client Implementors
> 
>    Tightened requirements for supporting WebDAV collections
>    (Section 5.2) within resources that do not support WebDAV (e.g.
>    servlet containers).
> 
>    Redefined 'allprop' PROPFIND requests so that the server does not
>    have to return all properties.

That affects servers as well, right? Maybe splitting the list in two 
parts isn't worthwhile.

>    Required to handle empty multistatus responses in PROPFIND  responses
>    (Section 8.2)
> 
>    No more "propertybehavior" specification allowed in MOVE and COPY
>    requests
> 
>    Support for UTF-16 now required (ref (Section 18)).
> 
>    Removed definition of "source" property and special handling for
>    dynamic resources.

Missing changes:

- PROPFIND dead-props 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-latest.html#rfc.section.13.28>)

- implicit lock refresh removed (see 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.section.B.1.1>)

...and potentially more.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 17 Oct 2005 12:24:53 -0700

The text on hosting malicious scripts was suggested by Barry Lind.

I put in the summary of changes in response to your suggestion on the  
phone, Julian.

Cullen, could you please respond about putting proposed text in the  
working copy of the draft either posted at ietf.webdav.org/webdav  or  
submitted to Internet-Drafts archive.

Lisa

On Oct 16, 2005, at 9:10 AM, Julian Reschke wrote:

> again contains stuff that wasn't announced at all. As far as I can  
> tell, drafts submitted to the IETF should optimally represent the  
> working group's consensus, and putting in stuff silently into the  
> working edits doesn't seem to be the best way to achieve this.
>
> In particular:
>
> (http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis- 
> latest.html#rfc.section.19.8>) looks interesting; but I don't see an  
> issue raised for this topic. In particular, the recommendation to  
> strip script from HTML pages looks a fishy (upon GET? PUT? for all  
> users?). This certainly needs more discussion if this should be added  
> to the spec.
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 17 Oct 2005 21:47:24 +0200

Clarifying...

I'd like to see stuff put into the draft *after* it has been discussed 
on the list, or at least that changes that are made are announced to the 
list for review. In the past, people have burned lots of cycles trying 
to find out what changed without notice, and reporting issues with these 
changes. It would really be nice if we could avoid that in the future.

Best regards, Julian

Lisa Dusseault wrote:
>> I don't think the requirement changed. The spec merely wasn't 
>> properly  repeating what XML defines, and this was fixed.
>>

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 18 Oct 2005 17:00:17 -0700

I just don't think we will every finish if we have to review every single
little change on the list before it is made. I would rather assume that the
editor of a document can mostly get it right, then fix what they get wrong
instead of assuming that they will get it all wrong.

We call these things drafts because they are a draft for the WG to review,
comment on, and fix. We call the folks writing them an author because they
are taking their best stab at coming up with a draft that the WG can form
consensus around. Now when it is a WG drafts, such as this one, the author
does need to reflect the things WG agreed to into the document because in
the end it will not move forward without WG consensus. If the author of a
working group document is maliciously failing to put in the things the WG
has agreed to, I will find a new author for the document. However, lets not
confuse this with the author trying to find some draft text that we can all
agree to and then having the WG help refine that text until it is something
we can all live with.

A natural difficulty with this is that it is non trivial to see all the
change to a document. I really don't know any way to solve this other than
diff tools. It good to catch the major diffs in the changes section of the
document but it's unreasonable to get all the trivial ones. The changes
being made to this document are small enough and local enough that it is not
that hard to catch them with diff.

I'm saying this poorly - it's hard to describe the difference between
reasonable changes and an author being way off in left field and introducing
garbage that the WG would never agree to.

I really like us to focus on what changes to we have to make to draft to get
it to the point it is all something we can live with. I hope the bugs are a
way of focusing on these issues.

Cullen

PS. Consider this email a draft :-) I (and we) might have to refine it a few
times before I get it right.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Oct 2005 07:22:30 +0200

> times before I get it right.

OK,

a few questions:

- how many people have been reviewing each of these drafts?

- can anybody say with confidence what has changed since RFC2518?

- does any server implementor think that (s)he has a compliant 
implementation of what's in?

The answers we *should* be getting are:

-> the majority of the WG members

-> see above

-> most of the active implementors of servers

However I'm pretty sure the actual situation is different, and I think 
this is caused by the way how the editorial process has been working in 
the past.

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.

Best regards, Julian

---

From: Jim Whitehead <[email-masked]>
Date: Wed, 19 Oct 2005 09:55:02 -0700

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

> 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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Oct 2005 19:29:47 +0200

Jim Whitehead wrote:
> 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.

> 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?)

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

---

From: Jim Whitehead <[email-masked]>
Date: Wed, 19 Oct 2005 11:39:39 -0700

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

That's very nice! Are you planning on consistently producing this  
page (or is it created automatically)?

Since it's easy to see the differences using this tool, it seems to  
me the concern about seeing changes from draft to daft is reduced. Is  
this true?

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

This also sounds like a plus. Is there some place that documents how  
to do this?
>
> 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.

My feeling is the modification process is now back on track, and we  
have a responsive document editor.

> 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  

I agree that's a pain, and a big advantage of XML. But, if the lack  
of change awareness from draft to draft frustrates people so much we  
never create a final draft, the ability to convert to text isn't  
super important. But, perhaps it's easy to create a cron job that  
automatically creates an HTML diff between revisions of 2518bis?  
Also, automatically converting the latest draft to HTML would also be  
a plus.

Making it easier to see the latest draft might improve participation.

- Jim

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 19 Oct 2005 12:04:26 -0700

> reasonable document model, converting back to XML at the end shouldn't 

Having migrated *from* Word in the midst of this process ( I think 
bis-06 was the first draft produced from XML) I am loath to go back.  I 
have a couple ideas to make the process easier however:

  - When I submit a draft I have to generate a text version anyway -- I 
usually save that to the ietf.webdav.org/webdav area as well.  I can 
generate an HTML version too.  It's a bit of a pain to do that for 
every single change I do (the ones that aren't submitted to the 
official internet-drafts repository) but perhaps I can automate that if 
there's demand, and I'll certainly do that whenever we get an official 
draft version bump.

  - I can do XML diffs and save them to the same place.  Again, not 
every week, but every so often.  We'd eventually have a set of diffs 
that constitutes the entire set of changes starting from the oldest XML 
version available -- 07-08diff.txt, 08-09diff.txt and so on.

  - I already maintain a complete list of changes including those made 
before the draft format went from Word to XML.  Each change has draft 
#'s along with it and issue codes so it's got a lot of context for 
understanding specific changes.  If there's anything missing at all 
it's an oversight and can probably be fixed if it's pointed out to me.
http://ietf.webdav.org/webdav/rfc2518bis/RFC2518%20Changes.doc

  - When I write significant new text in the draft, I can also submit it 
to the mailing list -- particularly when it's new sentences or entire 
paragraphs.  I did this with the partial-success text on Oct 11.  I can 
continue to do this as it seems appropriate , on special request, etc.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Oct 2005 23:36:01 +0200

Jim Whitehead wrote:
> 
>> 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.
> 
> 
> That's very nice! Are you planning on consistently producing this  page 
> (or is it created automatically)?

I can do that semi-automatically once the source on ietf.webdav.org 
actually is well-formed (and doesn't need manual fixes anymore before 
running it through an XML parser).

> Since it's easy to see the differences using this tool, it seems to  me 
> the concern about seeing changes from draft to daft is reduced. Is  this 
> true?

The drafts used to use a format where rfcdiff couldn't generate sensible 
diffs (hint: they were generated from Word). Now that readable diffs can 
be produce from both the revision and the original version this is less 
of a concern. I didn't think about generating a diff against rfc2518 
until today, but this makes a lot of sense.

>> 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>).
> 
> 
> This also sounds like a plus. Is there some place that documents how  to 
> do this?

It's an extension to xml2rfc that uses extension elements for 
del/ins/replace. If somebody wants to use it I''ll be happy to (finally) 
write down documentation.

>> 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.
> 
> 
> I agree that's a pain, and a big advantage of XML. But, if the lack  of 
> change awareness from draft to draft frustrates people so much we  never 
> create a final draft, the ability to convert to text isn't  super 
> important. But, perhaps it's easy to create a cron job that  
> automatically creates an HTML diff between revisions of 2518bis?  Also, 

Revisions between drafts that have been submitted are online at 
<http://tools.ietf.org/wg/webdav/draft-ietf-webdav-rfc2518bis/>.

> automatically converting the latest draft to HTML would also be  a plus.

Once the source document is fixed that'll be trivial.

> Making it easier to see the latest draft might improve participation.

Yep.