Re: new issue: requirements on dav:error responses

Yeah, it's always hard to get the wording of these just right.  We  
might have been better off saying in the first place "When used, the  
XML element MUST appear inside...."   That would cover both the  
"UNLESS otherwise negotiated" and the "UNLESS in response to GET"  
cases.  We have this wording problem a lot, particularly describing  
error responses.  Like "If the client doesn't have the permissions to  
do the action the server MUST return 403":  well, UNLESS there's an  
even higher-level error, like the syntax was wrong or the server is  
down for maintenance!

I'd like to think that implementors are smart enough to understand  
the implied exceptions -- the "UNLESS..." -- in these kinds of  
requirements.  But I'll admit that occasionally list arguments crop  
up about strictly enforcing without taking into account the implied  
exceptions.  Are these just arguments on the list or is there some  
non-rare cause of  implementation errors?  Can we even hope to think  
of all the reasonable exceptions?  Is there a better pattern of  
English statements to use that allows exceptions without stating them  
all -- and if so can we use it in the future (but maybe not now)?

Thanks,
Lisa

On Nov 28, 2006, at 3:33 AM, Julian Reschke wrote:

>
> Hi,
>
> I just realized that an issue recently discovered for RFC3744 (see  
> <http://www.lyra.org/pipermail/acl/2006-October/001918.html> and  
> <http://greenbytes.de/tech/webdav/draft-reschke-rfc3744bis- 
> latest.html#rfc.issue.7.1.1-error-body-vs-GET>) also applies to  
> RFC2518bis.
>
> Currently it says (<http://greenbytes.de/tech/webdav/draft-ietf- 
> webdav-rfc2518bis-16.html#rfc.section.16>):
>
> "Each precondition and postcondition has a unique XML element  
> associated with it. In a 207 Multi-Status response, the XML element  
> MUST appear inside an 'error' element in the appropriate 'propstat  
> or 'response' element depending on whether the condition applies to  
> one or more properties or to the resource as a whole. In all other  
> error responses, the XML element MUST be returned as the child of a  
> top-level 'error' element in the response body, unless otherwise  
> negotiated by the request, along with an appropriate response  
> status. The most common response status codes are 403 (Forbidden)  
> if the request should not be repeated because it will always fail,  
> and 409 (Conflict) if it is expected that the user might be able to  
> resolve the conflict and resubmit the request. The 'error' element  
> MAY contain child elements with specific error information and MAY  
> be extended with any custom child elements."
>
> Note:
>
> "In all other error responses, the XML element MUST be returned as  
> the child of a top-level 'error' element in the response body,  
> unless otherwise negotiated by the request, along with an  
> appropriate response status."
>
> The problem here is that for a simple "GET" request (without Accept  
> header), a server implementor will always return HTML, otherwise  
> he'll get lots of support calls. On the other hand, the "unless  
> otherwise negotiated by the request" loophole doesn't really apply  
> here.
>
> Best regards, Julian
>