Re: Review of RFC2518bis pre-draft

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

Seems like a minor issue, so we left the example in its current  
location.


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

Um, my understanding is that we haven't decided to change the format  
of DAV:getlastmodified, which still uses rfc1123 date format.

That said, I do have a preference for the RFC 2518 style of  
representing the value of properties by explicitly referencing the  
same production in RFC 2616 that the actual header uses.

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

Well, the issue here is what to do concerning these statements in RFC  
2616, section 4.2:

    The field value MAY be preceded by any amount of LWS, though a  
single SP is preferred.

    field-value    = *( field-content | LWS )

So, if you view the contents of a header as anything to the right of  
the colon, then the LWS is part of the value, and we need to state  
something about it.

Another position we could take is to state that the property values  
only include the field-content:

  field-content  = <the OCTETs making up the field-value
                         and consisting of either *TEXT or combinations
                         of token, separators, and quoted-string>

This is a stronger statement. However, it seemed to me that some  
server, somewhere, is bound to accidentally put in some LWS either  
before or after the field-content. As a result, the more  
interoperable approach was to put in the text stating that LWS might  
appear, and to be prepared to handle it. That said, the use of the  
word "value" in:

For properties defined based on HTTP GET response headers (DAV:get*),
     the value could include LWS as defined in <xref target="RFC2616"/ 
 >, section 4.2.

Is ambiguous. A better approach would be to say:

For properties defined based on HTTP GET response headers (DAV:get*),  
the value of the property is intended to be the field-content (as  
defined in Section 4.2 of RFC2616) of the corresponding header.  
However, RFC 2616 does permit the protocol octet stream prior to the  
field-content to contain by LWS, and after the field-content to have  
LWS. As a result, server implementations SHOULD use just the field- 
content, and clients MUST be prepared to strip LWS.

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

I'm not following your reply. What is "this"?

>
>>>    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).

This is just mirroring the semantics found in RFC 2518. Seems like  
we'd need to do an interop check on this condition before making any  
changes here.


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

As we have discussed in prior teleconferences, the potential  
ambiguity comes from this: When there is just the Request-URI, there  
is only ever one resource being discussed in the request or response.  
With the multistatus response, there are potentially may resources  
being discussed in the response.

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

Agreed, although I'll note that you're the one raising concerns about  
LWS handling in properties :-) *ducks*

Let's discuss this briefly in the next telecon. If there is no  
consensus there, I recommend asking Cullen to declare consensus. I  
agree we should close this and move on.

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

OK, adding section references to RFC 3986 seems like a good idea to me.

It seemed to be that using absolute URI (section 4.3) captured the  
intent of the WG. That is, we either want a fully qualified URL (i.e,  
not a relative URL) or we want a relative reference without ""." or  
"..".

As far as I can tell, the only difference between URI (section 3):

       URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

  and absolute-URI (section 4.3):

    absolute-URI  = scheme ":" hier-part [ "?" query ]

Is the optional ["#" fragment] part. While I don't see an immediate  
use case for including the fragment, I also don't see a compelling  
reason to forbid it, so I'm fine with using "URI" instead of  
"absolute-URI".

> Also note that "URI-reference" means "URI / relative-ref", so we  
> could use just that.

Ah, good find. I agree that we should use this instead.


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

OK.

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

Agreed -- this is too restrictive. The percent encoding rules apply  
to all URIs.

>
>    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...).

I disagree. We're making it clear that, just because a URI appears in  
XML, doesn't mean existing rules don't apply to it.


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

Ah. I misread the specification when we were editing last Friday. I  
agree it should be changed back to Version.

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

I don't recall. I'm fine with putting this back in.

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

I think so -- 10 is still open, I believe.

I'm fine with moving XML Infoset into the normative category.

- Jim

Received on Monday, 12 December 2005 19:16:19 UTC