Re: new issue: requirements on dav:error responses

Lisa Dusseault schrieb:
> 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 think that after all, we are specifying something which is really 
optional, at least for GET. Throwing in normative requirements here 
doesn't really help; I can easily imagine cases where somebody returns 
XHTML, and wants to embed DAV:error somewhere in the response document. 
Would that really violate a MUST level requirement? I don't think so; it 
just means that a client written to *this* spec won't see it.

So why don't we just specify the format (multistatus/non-multistatus 
case), and leave it at that?

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

The issue came up over here because my colleague stumbled upon the 
similar requirement in RFC3744 which obviously is not implementable. If 
this applies to RFC3744, it applies to RFC2518bis as well. And as this 
is *new* stuff (not inherited from RFC2518), we really should get it 
right. Or are we already planning for the next revision?

Best regards, Julian

Received on Wednesday, 29 November 2006 08:55:57 UTC