W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2006

Re: rfc2518bis-14 WGLC comments (part 2)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 15 Mar 2006 17:37:31 +0100
Message-ID: <441842CB.6010205@gmx.de>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:14 GMT