Subject: Re: draft 16 vs issue bz238

From: Lisa Dusseault <[email-masked]>
Date: Fri, 1 Dec 2006 11:16:44 -0800

Yeah, the section reference is wrong, I can fix that.  I'll continue  
to use my own wording for the rest as it's not quite true that  
there's two different formats (I can think of three: empty body,  
'error' body or 'multistatus').

Lisa

On Nov 28, 2006, at 5:36 AM, Julian Reschke wrote:

>
> From <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi? 
> id=238#c2>:
>
> Draft 16 added:
>
> "If a server attempts to make any of the property changes in a  
> PROPPATCH request (i.e. the request is not rejected for high-level  
> errors before processing the body), the response MUST be a Multi- 
> Status response (Section 13)."
>
> That's incorrect. The whole point is that in this case, the Multi- 
> Status reponse format is *not* the one defined in Section 13. So  
> please replace with the previously suggested text:
>
> "The response to a PROPPATCH request can be in two different  
> formats: should the server reject the request altogether (because  
> of missing access rights, failed conditional headers, malformed  
> request syntax, etc.), the status SHOULD be non-2xx HTTP status. On  
> the other hand, if the server did attempt the property  
> modification, the response status SHOULD be 207 Multistatus, using  
> the 'multistatus' response body format defined below (Section 9.2.1)."
>
> Best regards, Julian
>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 01 Dec 2006 20:22:34 +0100

Lisa Dusseault schrieb:
> 
> Yeah, the section reference is wrong, I can fix that.  I'll continue to 
> use my own wording for the rest as it's not quite true that there's two 
> different formats (I can think of three: empty body, 'error' body or 
> 'multistatus').

So then why does Section 13 say 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-16.html#rfc.section.13>):

---
A Multi-Status response uses one out of two distinct formats for 
representing the status:

    1. A 'status' element as child of the 'response' element indicates 
the status of the message excecution for the identified resource as a 
whole (for instance, see Section 9.6.2). Some method definitions provide 
information about specific status codes clients should be prepared to 
see in a response. However, clients MUST be able to handle other status 
codes, using the generic rules defined in Section 10 of [RFC2616].
    2. For PROPFIND and PROPPATCH, the format has been extended using 
the 'propstat' element instead of 'status', providing information about 
individual properties of a resource. This format is specific to PROPFIND 
and PROPPATCH, and is described in detail in Section 9.1 and Section 9.2.
---

??

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 1 Dec 2006 11:31:03 -0800

These two statements are not inconsistent.  There are two formats for  
Multi-status responses; there are at least three legal formats for  
PROPFIND responses.  A PROPFIND response is not always a Multi-Status  
response (in the case of errors).

Lisa

On Dec 1, 2006, at 11:22 AM, Julian Reschke wrote:

> Lisa Dusseault schrieb:
>> Yeah, the section reference is wrong, I can fix that.  I'll  
>> continue to use my own wording for the rest as it's not quite true  
>> that there's two different formats (I can think of three: empty  
>> body, 'error' body or 'multistatus').
>
> So then why does Section 13 say (<http://greenbytes.de/tech/webdav/ 
> draft-ietf-webdav-rfc2518bis-16.html#rfc.section.13>):
>
> ---
>    1. A 'status' element as child of the 'response' element  
> indicates the status of the message excecution for the identified  
> resource as a whole (for instance, see Section 9.6.2). Some method  
> definitions provide information about specific status codes clients  
> should be prepared to see in a response. However, clients MUST be  
> able to handle other status codes, using the generic rules defined  
> in Section 10 of [RFC2616].
>    2. For PROPFIND and PROPPATCH, the format has been extended  
> using the 'propstat' element instead of 'status', providing  
> information about individual properties of a resource. This format  
> is specific to PROPFIND and PROPPATCH, and is described in detail  
> in Section 9.1 and Section 9.2.
> ---
>
> ??
>
> Best regards, Julian