Review of RFC2518bis pre-draft

...as of today; as seen at 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-latest.txt>. 
This review mainly covers minor changes compared to -08 which 
(hopefully) do not need a BugZilla entry. Please try to fix those before 
submitting a new draft.

3. Terminology

Inconsistent typography (":" vs "-")

"A URI mapping can be thought of as a URL pointing to a resource."

I'm not sure what this is supposed to mean. Please remove it or clarify.


7.6  Write Locks and Unmapped URLs

    A successful lock request to an unmapped URL MUST result in the
    creation of an locked resource with empty content.  Subsequently, a
    successful PUT request (with the correct lock token) provides the
    content for the resource, and the server MUST also use the content-
    type and content-language information from this request.

Making this a MUST creates a conflict with an upcoming TAG finding by 
Roy Fielding.


8.2.6 Example - Using 'allprop' to Retrieve Dead Properties and RFC2518 
Properties

Nits:

- move it back where it was in RFC2518
- avoid the term RFC2158 properties in the title
- XML in example to be fixed, for instance whitespace in D:getlastmodified
- intra-doc reference to Section 13 is incorrect

Obviously this has been copied verbatim from RFC2518 without any sanity 
checks.


8.3.1

    200 (OK) - The property set or change succeeded.  Note that if this
    appears for one property, it MUST appear for every property in the
    response, due to the atomicity of PROPPATCH.

(2nd sentence) Again, this is correct, but

a) doesn't really need to be mentioned,

b) but if is mentioned, then using MUST is incorrect here. This is imply 
an observation based on normative text somewhere else, not a new interop 
requirement.


8.7  DELETE

    WebDAV adds some requirements to DELETE handling.  Locks rooted on a
    resource MUST be destroyed in a successful DELETE of that resource.

This is still a lame way to introduce DELETE. Please move the second 
sentence somewhere else, potentially a subsection (see also 
<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=103#c2>).



8.9.5  Status Codes

    403 (Forbidden) - The operation is forbidden.  A special case for
    COPY could be that the source and destination resources are the same
    resource.

Confusing. Servers may treat this as a nop, just returning 200. Just be 
silent about it.


8.10.4  Status Codes

    204 (No Content) - The source resource was successfully moved to
    overwrite pre-existing destination resource.

Sentence broken compared to -08.

    403 (Forbidden) - In addition to general reasons for forbidding a
    MOVE operation, it could be that the source and destination resources
    are the same.

And being source and destination identical would be a problem exactly why?


12.1  Response headers

    Use of the Location header with the Multi-Status response is
    intentionally undefined.  The server MAY always redirect the entire
    request by responding with a 300 level status response instead of a
    Multi-Status response.

This section doesn't provide any useful information. In particular, the 
second sentence seems to be completely out of context.


12.2  URL handling

    When a Multi-Status body is returned in response to a PROPFIND or
    another request with a single scope (no Destination header), it can
    contain one or more 'response' element with an 'href' element for the
    URL of the resource described in that 'response' element.  Each of

And in the other case this is not true?

    these response URLs MUST be equal to or inside the Request-URI.  The
    response URLs MAY be absolute or relative references but MUST NOT
    include "." or ".." as path elements.

URLs never are relative references. There is no such thing as an 
absolute reference.

    If a response URL is relative reference, it MUST be resolved against
    the Request-URI.  A relative reference MUST be an absolute path (note
    that clients are not known to support relative paths).

May I again recommend to just use the text I proposed earlier? It uses 
the proper terminology from RFC3986.

    URLs for collections appearing in the results SHOULD end in a '/'
    character.

And the rule does not apply if it's not a URL, such as a relative reference?

    If a server allows resource names to include characters that aren't
    legal in HTTP URL paths, these characters must be URI-escaped on the

Again, terminology. It's called "Percent-Encoding", and we should refer 
to the exact section in RFC3986.

    wire.  For example, it is illegal to use a space character or double-
    quote in a URI.  URIs appearing in PROPFIND or PROPPATCH XML bodies
    (or other XML marshalling defined in this specification) are still
    subject to all URI rules, including forbidden characters.


12.3  Handling redirected child resources

    Redirect responses (300-303, 305 and 307) defined in HTTP 1.1
    normally take a Location header to indicate the new URI for the
    single resource redirected from the Request-URI.  Multi-Status
    responses contain many resource addresses, but the original
    definition in RFC2518 did not have any place for the server to
    provide the new URI for redirected resources.  This specification
    does define a 'location' element for this information (see
    Section 13.9).  Servers MAY use this new element or MAY stick with
    the original syntax.

Sounds like "We don't care what servers do".


19.7  Risks Connected with Lock Tokens

    This specification encourages the use of "A Universally Unique
    Identifier (UUID) URN Namespace" ([RFC4122]) for lock tokens
    Section 6.3, in order to guarantee their uniqueness across space and
    time.  The security considerations for UUIDs do not apply because
    WebDAV does not assume that lock tokens are supposed to be hard to
    ...

Wow! They don't apply? Why can't we just stick with what RFC2518 said,
just updating what needs to be updated, and leaving the rest alone?
Proposed text:

    This specification, in Section 6.3, encourages the use of Universal
    Unique Identifiers (UUIDs) in lock tokens, in order to guarantee
    their uniqueness across space and time.  Version 1 UUIDs, as defined
    in Section 4 of [RFC4122], may contain a "node" field which "consists
    of an IEEE 802 MAC address, usually the host address.  For systems
    with multiple IEEE 802 addresses, any available one can be used".
    Since a WebDAV server will issue many locks over its lifetime, the
    implication is that it may also be publicly exposing its IEEE 802
    address.

    There are several risks associated with exposure of IEEE 802
    addresses.  Using the IEEE 802 address:

    o  It is possible to track the movement of hardware from subnet to
       subnet.

    o  It may be possible to identify the manufacturer of the hardware
       running a WebDAV server.

    o  It may be possible to determine the number of each type of
       computer running WebDAV.

    This risk only applies to host address based UUID versions.  Section
    4 of [RFC4122] describes several other mechanisms for generating
    UUIDs that do involve the host address and therefore do not suffer
    from this risk.




22.1 Normative References

[2518] still appears under "normative".



Best regards, Julian

Received on Friday, 9 December 2005 19:48:28 UTC