Re: HTTP Status Codes for QueryRequestRefused

Kendall Clark wrote:
> Here's my position:
> 
> 1. Having a WSDL for a service doesn't constrain the HTTP layer in  
> any other way. It simply cannot do so.
 >
> 2. The only thing WSDL can say or describe (and thus "constrain" if a  
> service conforms to WSDL) is (relevantly) WSDL *faults*, which in  
> HTTP are serialized as HTTP status codes (and in other ways, I think,  
> but that's not relevant here).
> 
> So, if these status codes yr worried about people thinking they can't  
> use are WSDL faults, let's make them WSDL faults and choose HTTP  
> status codes to serialize them.
> Otherwise they are merely HTTP status codes, in the HTTP layer, and  
> WSDL doesn't say anything about them, and thus doesn't abjure them.

Thank you for summarizing your position.

Mine is that the protocol document says a QueryRequestRefused *must* be 
returned and that "*must*" is an absolute requirement (using RFC2119 
terminolgy).  That leaves no room to return another status code and claim to 
be an implementation of the SPARQL interface.

I am only seeking clarification for the HTTP case.  The SOAP case is clearer 
because it can directly encode the fault in the message.

> If you want a statement to that effect in the document, I drafted one  
> in my previous message. You reject it because you think it  
> contradicts "intended interaction". But it doesn't.

If that is:

"A SPARQL Protocol service may employ the full range of HTTP status
codes consistent with the usage of QueryRequestRefused and
MalformedQuery as describe in section 2.1.4."

[[I didn't see that as an offer because you then provided alternative, 
preferred text quoting from the current document which is not acceptable.]]

As it's a redrafting of my initial text (:-), the "employ the full range" text 
is acceptable even though the use of *must* (RFC2119) is used in tehfault 
definition when the "*should*" meaning seems to fit better ("may exist valid 
reasons").

	Andy

> 
> Cheers,
> Kendall
>

Received on Friday, 6 January 2006 19:10:12 UTC