- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 15 Mar 2006 17:37:31 +0100
- To: WebDAV <w3c-dist-auth@w3.org>
[Page 76]
All DAV headers follow the same basic formatting rules as HTTP
headers. This includes rules like line continuation and how to
combine (or separate) multiple instances of the same header using
commas. WebDAV adds two new conditional headers to the set defined
in HTTP: the If and Overwrite headers.
-> Insert paragraph break after "...commas."
The value is a comma-separated list of all compliance class
identifiers that the resource supports. Class identifiers may be
Coded-URLs or tokens (as defined by [RFC2616])...
-> Remove the last part, but add it to the BNF with a precise reference
to the Section in RFC2616.
A resource must show class 1 compliance if it shows class 2 or 3
compliance. In general, support for one compliance class does not
entail support for any other, and in particular, support for
compliance class 3 does not require support for compliance class 2.
Please refer to Section 18 for more details on compliance classes
defined in this specification.
-> Organization: I think it would be better if this section would just
define the syntax, and delegate statements about syntax to Section 18.
[Page 78]
Please note, however, that it is always an error to submit a value
for the Depth header that is not allowed by the method's definition.
Thus submitting a "Depth: 1" on a COPY, even if the resource does not
have internal members, will result in a 400 (Bad Request). The
method should fail not because the resource doesn't have internal
members, but because of the illegal value in the header.
-> Seems that we shouldn't say "MUST be ignored" after all :-)
If the Destination value is an absolute URI, it may name a different
server (or different port or scheme). If the source server cannot
attempt a copy to the remote server, it MUST fail the request. Note
that copying and moving resources to remote servers is not fully
defined in this specification (e.g. specific error conditions).
-> s/absolute URI/absolute-URI (Section 4.3 of [RFC3986])/
o The first purpose is to make a request conditional by supplying a
series of state lists. If the state lists are tested and all
fail, then the request MUST fail with a 412 (Precondition Failed)
status. On the other hand, the request can succeed only if one of
the described state lists succeeds. The success criteria for
state lists are defined in Section 10.4.4 below.
-> Replace by:
"o The first purpose is to make a request conditional by supplying a
series of state lists. If none of the state lists match the state of the
resource it applies to, the request MUST fail with a 412 (Precondition
Failed) status. Otherwise, the request may succeed. The matching
functions for ETags and state tokens are defined in Section 10.4.4 below."
o Additionally, the mere fact that a state token appears in an If
header means that is has been "submitted" with the request. In
general, this is used to indicate that the client has knowledge of
that state token. The meaning of submitting a state token depends
on its type (for lock tokens, please refer to Section 6).
-> Replace by:
"o Additionally, the mere fact that a state token appears in an If
header means that it has been "submitted" with the request. In general,
this is used to indicate that the client has knowledge of that state
token. The semantics of the "submission" of a state token depends on
its type (for lock tokens, please refer to Section 6)."
[Page 80]
10.4.3. List Evaluation
-> s/List Evaluation/Evaluation/
10.4.4. Matching Tokens and ETags
-> s/Matching Tokens and ETags/Matching State Tokens and ETags/
Matching unmapped URLs: for both ETags and state tokens, treat as if
the URL identified a resource that exists but does not have the
specified state.
-> Replace by:
"Note that for the purpose of matching entity tags and state tokens, the
URL being unmapped should be treated the same way as if the resource
existed, but did not have the specified state."
[Page 81]
(
is-locked-with(urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2) AND
matches-etag("I am an ETag")
)
OR
(
matches-etag("I am another ETag")
)
-> Indentation missing, replace by:
(
is-locked-with(urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2) AND
matches-etag("I am an ETag")
)
OR
(
matches-etag("I am another ETag")
)
[Page 83]
The Overwrite request header specifies whether the server should
overwrite a resource mapped to the destination URL during a COPY or
MOVE. A value of "F" states that the server must not perform the
COPY or MOVE operation if the state of the destination URL does map
-> s/state of the//
[Page 84]
If a COPY or MOVE is not performed due to the value of the Overwrite
header, the method MUST fail with a 412 (Precondition Failed) status
code. The server MUST do authorization checks before checking this
or any conditional header.
-> s/or any conditional// (doesn't belong here)
[Page 86]
These HTTP codes are not redefined, but their use is somewhat
extended by WebDAV methods and requirements. In general, many HTTP
status codes can be used in response to any request, not just in
cases described in this document. Note also that WebDAV servers are
known to use 300-level redirect responses (and early interoperability
tests found clients unprepared to see those responses). A 300-level
request MUST NOT be used when the server has created a new resource
in response to the request.
-> s/request/response/
-> Don't we usually say "3xx class" instead of "300-level"?
12.2. 414 Request-URI Too Long
This status code is used in HTTP 1.1 only for Request-URIs, not URIs
in other locations.
-> So it's the same thing as in HTTP. Why is it then mentioned here???
[Page 87]
13. Multi-Status Response
-> See comments and proposed text in
<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=177>.
Clients encountering redirected resources in Multi-Status MUST NOT
rely on the 'location' element being present with a new URI. If the
-> Inconsistency: if servers MUST include the location element, why
can't clients rely on it being present???
element is not present, the client MAY reissue the request to the
individual redirected resource, because the response to that request
can be redirected with a Location header containing the new URI.
-> Language: clients MAY do whatever they want. This is nothing normative.
[Page 89]
In this section, the final line of each section gives the element
type declaration using the format defined in [REC-XML]. The "Value"
field, where present, specifies further restrictions on the allowable
contents of the XML element using BNF (i.e., to further restrict the
values of a PCDATA element). The "Extensibility" field discusses how
the element may be extended in the future (or in existing extensions
to WebDAV.
-> Replace last sentence by "Note that all elements can be extended
according to the rules defined in Section 17.".
All of the elements defined here may be extended by the addition of
attributes and child elements not defined in this specification. All
elements defined here are in the "DAV:" namespace.
-> Remove that sentence (already defined in Section 17).
<!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,
locktoken?, lockroot)>
-> Indentation, make it:
<!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,
locktoken?, lockroot)>
[Page 90]
Purpose: Error responses, particularly 403 Forbidden and 409
Conflict, sometimes need more information to indicate what went
wrong. When an error response contains a body in WebDAV, the body
is in XML with the root element 'error'. The 'error' element
SHOULD include an XML element with the code of a failed
precondition or postcondition.
-> Language: "...the body is in XML..."
-> s/code of a failed/name of a failed/
Description: Contains at least one XML element, and MUST NOT
contain text or mixed content. Any element that is a child of the
'error' element is considered to be a precondition or
postcondition code. Unrecognized elements SHOULD be ignored.
-> As a matter of fact, they must be ignored.
Purpose: Specifies an exclusive lock
-> s/lock/lock./
[Page 91]
Value: Simple-ref
-> Link to definition in spec???
<!ELEMENT location (href)>
-> Inconsistent indentation (nees to be outdented)
[Page 92]
Purpose: The 'lockinfo' XML element is used with a LOCK method to
specify the type of lock the client wishes to have created.
-> Misleading: not necessarily with a LOCK method; can appear in
PROPFIND as well, for instance.
Description: The href contains a HTTP URL with the address of the
root of the lock. The server SHOULD include this in all DAV:
lockdiscovery property values and the response to LOCK requests.
-> s/the address of//
[Page 93]
Purpose: Provides information about the creator of a lock.
-> No, we have defined the lock creator to be something else.
[Page 94]
Description: This XML element is a container for the information
required to modify the properties on the resource. This XML
element is multi-valued.
-> Language: I have no idea what "multivalued" means in this context.
[Page 95]
Description: The propstat XML element MUST contain one prop XML
element and one status XML element. The contents of the prop XML
element MUST only list the names of properties to which the result
in the status element applies. The optional precondition/
postcondition error code and 'responsedescription' text also apply
to the properties named in 'prop'.
-> s/error//
Description: The 'href' element contains a HTTP URL pointing to a
WebDAV resource when used in the 'response' container. A
particular 'href' value MUST NOT appear more than once as the
child of a 'response' XML element under a 'multistatus' XML
element. This requirement is necessary in order to keep
processing costs for a response to linear time. Essentially, this
prevents having to search in order to group together all the
responses by 'href'. There are, however, no requirements
regarding ordering based on 'href' values. The optional
precondition/postcondition error code and 'responsedescription'
text can provide additional information about this resource
relative to the request or result.
-> s/error//
[Page 96]
<!ELEMENT response (href, ((href*, status)|(propstat+)),
error?, responsedescription? , location?) >
-> Indentation.
Description: The 'set' XML element MUST contain only a prop XML
element. The elements contained by the prop XML element inside
-> s/prop/'prop'/
Purpose: Specifies a shared lock
-> /lock/lock./
[Page 97]
Purpose: Holds a single HTTP status-line
-> s/status-line/status-line./
Value: status-line (status-line defined in Section 6.1 of
[RFC2616])
-> s/status-line defined in/defined in/
[Page 98]
COPY and MOVE behavior refers to local COPY and MOVE operations.
-> as opposed to?
For properties defined based on HTTP GET response headers (DAV:get*),
the value could include LWS as defined in [RFC2616], section 4.2.
Server implementors SHOULD NOT include extra LWS in these values,
however client implementors MUST be prepared to handle extra LWS.
-> My understanding was that LWS is not allowed, see
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/1251.html>.
Also insert:
"Note that all property elements can be extended according to the rules
defined in Section 17."
[Page 99]
Description: The DAV:creationdate property SHOULD be defined on all
DAV compliant resources. If present, it contains a timestamp of
the moment when the resource was created. Servers that are
incapable of persistently recording the creation date SHOULD
instead leave it undefined (i.e. report "Not Found")
-> trailing dot missing.
Description: The DAV:displayname property should be defined on all
DAV compliant resources. If present, the property contains a
-> Why should it be defined? If the server doesn't have a displayname,
it indeed should not be defined.
[Page 101]
Description: The getetag property MUST be defined on any DAV
compliant resource that returns the Etag header. Refer to RFC2616
for a complete definition of the semantics of an ETag, and to
Section 8.6 for a discussion of ETags in WebDAV.
-> s/to RFC2616/to Section 3.11 of [RFC2616]/
[Page 102]
COPY/MOVE behaviour: This property value is dependent on the last
modified date of the destination resource, not the value of the
property on the source resource. Note that some server
implementations use the file system date modified value for the
DAV:getlastmodified value, and this can be preserved in a MOVE
even when the HTTP Last-Modified value SHOULD change. Note that
-> I honestly don't understand that statement.
Description: Note that the last-modified date on a resource SHOULD
only reflect changes in the body (the GET responses) of the
resource. A change in a property only SHOULD NOT cause the last-
modified date to change, because clients MAY rely on the last-
modified date to know when to overwrite the existing body. The
DAV:getlastmodified property MUST be defined on any DAV compliant
resource that returns the Last-Modified header in response to a
GET.
-> Language: starts with a note (IMHO unneeded), but then makes a
normative statement.
[Page 104]
>>Response
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D='DAV:'>
<D:response>
<D:href>http://www.example.com/container/</D:href>
<D:propstat>
<D:prop>
<D:lockdiscovery>
<D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>0</D:depth>
<D:owner>Jane Smith</D:owner>
<D:timeout>Infinite</D:timeout>
<D:locktoken>
<D:href
>urn:uuid:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76</D:href>
</D:locktoken>
<D:lockroot>
<D:href>http://www.example.com/container/</D:href>
</D:lockroot>
</D:activelock>
</D:lockdiscovery>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
-> Fix indentation.
Protected: SHOULD be protected. Resource type is generally decided
through the operation creating the resource (MKCOL vs PUT), not by
PROPPATCH.
-> Language confusing: why "generally"?
[Page 105]
COPY/MOVE behaviour: Generally a COPY/MOVE of a resource results in
the same type of resource at the destination.
-> That's true for the collection type, but I doubt it's true in general
(where types often depend on specific locations in the server namespace).
COPY/MOVE behaviour: This property value is dependent on the kind
of locks supported at the destination, not on the value of the
property at the source resource. Servers attempting to COPY to a
destination should not attempt to set this property at the
destination.
-> That's generally true for any protected property, right?
[Page 107]
16. Precondition/postcondition XML elements
-> See comments in
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2006JanMar/0733.html>
and <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=181>.
[Page 112]
With DTD validation relaxed by the rules above, the constraints
described by the DTD fragments are normative (see for example
Appendix A A recipient of a WebDAV message with an XML body MUST NOT
validate the XML document according to any hard-coded or dynamically-
declared DTD.
-> Missing ")." after "Appendix A".
[Page 113]
E.g. a server could have a sub-repository where an advanced feature
like server was supported, even if that feature was not supported on
all servers.
-> "like server"?
A resource that is class 2 compliant must also be class 1 compliant,
and a resource that is class 3 compliant must also be class 1
compliant.
-> "A resource that is class 2 or class 3 compliant must also be class 1
compliant."
[Page 119]
External XML entities have no inherent trustworthiness and are
subject to all the attacks that are endemic to any HTTP GET request.
Furthermore, it is possible for an external XML entity to modify the
DTD, and hence affect the final form of an XML document, in the worst
case significantly modifying its semantics, or exposing the XML
processor to the security risks discussed in [RFC3023]. Therefore,
implementers must be aware that external XML entities should be
treated as untrustworthy. If a server implementor chooses not to
handle external XML entities, it SHOULD respond to requests
containing external entities with the precondition defined above (no-
external-entities).
-> "...should respond ... with precondition..."?
[Page 124]
22. Acknowledgements
-> I think three sections of thanks is way too much, this probably
should be collapsed into a single one.
[Page 137]
E.2. Changes for Server Implementors
-> "Changes for Server Implementations"
Received on Wednesday, 15 March 2006 16:39:09 UTC