Re: new stuff in draft edits

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


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

Received on Monday, 17 October 2005 19:48:06 UTC