Re: Review of RFC2518bis pre-draft

Elias Sinderson wrote:
> 
>> 3. Terminology
>> Inconsistent typography (":" vs "-")
> 
> Fixed.

Thanks.

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

Thanks.

>> 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.
> 
> Discussion needed; created new bugzilla issue.

Done: <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=205>

>> 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
> 
> Renamed; brief explanatory note added.

It would be nice if it also could be moved back to where it was in 
RFC2518 in order to avoid needless diffs.

>> - XML in example to be fixed, for instance whitespace in 
>> D:getlastmodified
> 
> Fixed the example. However, since DAV:get* properties are based upon 
> definitions made in rfc2616, LWS may be found in some implementations -- 
> explanatory text added to section 14.

a) the date doesn't use rfc1123 syntax

b) I object to that change, LWS is not part of the value of the header, 
that is whitespace is not allowed here (any evidence of a server adding 
this???). Do I need to open an issue for that?

>> - intra-doc reference to Section 13 is incorrect
> 
> Fixed.

Thanks.

>> 8.3.1 [...] (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. [...]
> 
> 2nd sentence left in, with MUST removed.

Thanks.

>> 8.7  DELETE [...] This is still a lame way to introduce DELETE.  [...]
> 
> 
>> 8.9.5  Status Codes [...] 403 (Forbidden) [...] Confusing. Servers may 
>> treat this as a nop, just returning 200. Just be silent about it.
> 
> Discussed this but left the text in, as the semantics were defined in 
> 2518 (see similar comment below).

Well, it was mentioned, but the spec never contained a requirement for 
servers to reject this.

>> 8.10.4  Status Codes
>>    204 (No Content) - [...] Sentence broken [...]
> 
> Rewrote text to clarify 204 and 201.

Thanks.

>>    403 (Forbidden) [...] And being source and destination identical 
>> would be a problem exactly why?
> 
> Semantics defined in 2518, left alone as a change could compromise 
> resource identity (e.g. creation date may change, corruption of version 
> history, etc.).

I don't buy that rational, because that would just mean that the server 
did what the client told him to do. In particular, the version history 
would not be corrupted nor removed (see RFC3253 COPY semantics).

>> 12.1  Response headers [...] This section doesn't provide any useful 
>> information. In particular, the second sentence seems to be completely 
>> out of context.
> 
> Rewrote this section (originally added following discussion of issue 
> 47). Second sentence has been removed.

It now says:

    HTTP defines the Location header to indicate a preferred URL for the
    resource that was addressed in the Request-URI (e.g. in response to
    successful PUT requests or in redirect responses).  However, use of
    this header creates ambiguity when there are URLs in the body of the
    response, as with Multi-Status.  Thus, use of the Location header
    with the Multi-Status response is intentionally undefined.

I still don't understand this. How does the presence of a Location 
header create an ambiguity here? The URLs in the response mean exactly 
what this spec defines them to mean, and there is absolutely no 
ambiguity here.

I'd also like to point out that we've been wasting an incredible amount 
of time undoing a change that was meant to talk about the 
"Content-Location" header, not "Location". As far as I can tell, nobody 
has asked questions about "Location" until I asked why it was put in 
without prior discussion, and I fail to see how this addition makes this 
a better spec. Please remove it.

>> 12.2  URL handling [...]
> 
> Rewrote most of this section, incorporating some of your proposed text, 
> and paying attention to RFC3986 language -- please review.

Now says:

12.2  URL Handling

    A Multi-Status body contains one or more 'response' elements.  Each

Zero or more.

    response element describes a resource, and has an 'href' element
    identifying the resource.  The 'href' element MUST contain an
    absolute URI or relative reference.  It MUST NOT include "." or ".."
    as path elements.

It would be helpful if this would refer to the sections of RFC3986 
defining this terms. In particular, I fail to see why we are now 
restricted to "absolute-URI" instead of "URI". Also note that 
"URI-reference" means "URI / relative-ref", so we could use just that.

    If a 'href' element contains a 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).

Again, a reference to the right places in RFC3986 grammar seems to be 
useful.

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

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

Why restrict to HTTP URL?

    the wire (see [RFC3986], section 2.1).  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.

The last sentence doesn't seem to be useful; what we're saying here 
applies to all uses of multistatus bodies, including error responses, or 
extensions (REPORT...).

>> 12.3  Handling redirected child resources [...]  Sounds like "We don't 
>> care what servers do".
> 
> After some discussion, we now care and have rewritten the last sentence.

Great. It now says:

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 MUST use this new element with redirect
    responses in Multi-Status.

I think the last two sentences belong into the Changes appendix, not here.

  >> 19.7  Risks Connected with Lock Tokens [...]
> 
> Proposed text inserted with a couple of tweaks (title of RFC, version / 
> variant language, and minor wordsmithing introducing the list).

Still :-)

1) Says "Variant x UUID" when it should say "Version x UUID"

2) Misses the statement "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.". Why?

>> 22.1 Normative References [...]
> 
> Reference to 2518 moved to informative references.

Thanks. I just noted that the XML Infoset reference appears under 
"informative", but that is indeed normative. But we're still discussing 
the "property value" proposal, based on what's in BugZilla 
(<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10>), right?

Best regards, Julian

Received on Saturday, 10 December 2005 15:04:57 UTC