Re: new stuff in draft edits

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.


On 10/17/05 12:47 PM, "Julian Reschke" <julian.reschke@gmx.de> wrote:

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

Received on Wednesday, 19 October 2005 00:00:31 UTC