W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

new stuff in draft edits

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 16 Oct 2005 18:10:23 +0200
Message-ID: <43527B6F.3000506@gmx.de>
To: w3c-dist-auth@w3.org


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

> 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 

- implicit lock refresh removed (see 

...and potentially more.

Best regards, Julian
Received on Sunday, 16 October 2005 16:10:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:33 UTC