Re: Review of RFC2518bis pre-draft

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.

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

Of course.

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

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

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

As far as I can tell, there's no interoperability to worry about. A 
server just must make sure that kind of request does not unintentionally 
destroy the resource (which could happen with a naive implementation 
that DELETEs the destination first). Telling servers what to do exactly 
is micro-managing the issue. If people are concerned about this problem, 
just warn implementors that requests like that may occur, and that the 
server must be prepared for them.


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

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

Ahem. I did raise a concern because of a *change* in the spec that I 
think isn't required, and makes life harder for clients. Again, for 
these types of changes it would be really good to understand what 
problem we're actually trying to fix.

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

Fine with me.

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

> ...

Best regards, Julian

Received on Monday, 12 December 2005 20:57:28 UTC