Re: Review of RFC2518bis pre-draft

Julian and I discussed the remaining issues during the 12/14/2005  
teleconference. Resolution marked below.

On Dec 12, 2005, at 12:55 PM, Julian Reschke wrote:

>
> Jim Whitehead wrote:
>
>>>>> - 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.
>
> Yes, but the example doesn't use it.

Agreed. The example in Section "Example - Using 'allprop'", in the  
propfind response, has a getlastmodified header returned. This header  
does not use the rfc1123 date format. I agree this should be modified  
to use the correct date format.


>>> 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.
>
> Do we have evidence of servers putting in LWS, and clients ignoring  
> it? Otherwise I'd prefer to stick with the most simple approach  
> (forbidding the LWS).

Julian and I agreed to include language along the lines of servers  
SHOULD just use the field-content as the value of the property, and  
SHOULD NOT put LWS before or after the field-content as the value of  
the property. We decided that no statement about client behavior was  
needed (they'll strip the LWS if they ever see it anyway).

>
>>>>> 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"?
>
> This = rejecting MOVE / COPY requests where source and destination  
> are the same.

Julian and I agreed to change the language from RECOMMENDED use of  
403 to "MAY occur"  (MOVE - section 8.10.4). The section for COPY  
appears to be fine.

>
>>>>> 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.
>
> HTTP says (<http://greenbytes.de/tech/webdav/ 
> rfc2616.html#rfc.section.14.30>):
>
> "The Location response-header field is used to redirect the  
> recipient to a location other than the Request-URI for completion  
> of the request or identification of a new resource. For 201  
> (Created) responses, the Location is that of the new resource which  
> was created by the request. For 3xx responses, the location SHOULD  
> indicate the server's preferred URI for automatic redirection to  
> the resource."
>
> I'm not sure how anybody could come to the assumption that things  
> are different in case of a multistatus.
>

Julian and I agreed to keep the draft as-is on this issue. We agreed  
that there was a misunderstanding about the original issue (Content- 
Location vs Location), but that this confusion did lead us to make a  
clarification that at least Jim thought was a good idea.


>>>    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.
>
> I'm not against making that cleat (thus the example in the text  
> proposed by me in <http://greenbytes.de/tech/webdav/draft-reschke- 
> webdav-rfc2518bis-latest.html#rfc.section.12.1.1>), I just find the  
> current wording confusing. The rule applies to *any* method (not  
> only PROPFIND or PROPPATCH), and to all kinds of XML (not only  
> multistatus).

The text in section (12.2 - "URL Handling")

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.

Change to:

URIs appearing in all XML elements are still subject to all URI  
rules, including forbidding characters (this applies to PROPFIND and  
PROPPATCH, among many methods).

Agreed that we should include the example from Julian's draft in  
section 12.1.1, which clearly shows these rules in action.

- Jim

Received on Wednesday, 14 December 2005 17:40:26 UTC