- From: Kendall Clark <kendall@monkeyfist.com>
- Date: Wed, 11 Jan 2006 14:55:52 -0500
- To: Mark Baker <distobj@acm.org>
- Cc: public-rdf-dawg-comments@w3.org
On Jan 11, 2006, at 2:33 PM, Mark Baker wrote: > > I've been following along ... > > Though I mostly side with Kendall, I think he's in error when he > refers to HTTP 403 as a "transport" level error. It is an application > level error, because HTTP is an application protocol. First, I don't concede that (1) HTTP is always in every usage context an application protocol (or that the best way to conceive of it is as an application protocol, or (2) that every error defined by an application protocol is necessarily an application-level error. In short, none of these terms is crisp or isolate enough to bear that kind of definitional or rhetorical weight. In particular, the distinction between "application" and "transports" is notoriously migratory. (So, for example, imagine that HTTP is an application protocol for the most part. Further imagine that someone decides they want to use HTTP, the application protocol, to transport some other kind or level of application, in which case it makes some sense to conceive of HTTP as an application protocol in some linguistic situations but as a transport protocol in some other linguistic situations. It's not *necessarily* one thing or the other. It may be both, relative to some set of interests and sensitive to some context.) More to the point, I may have said that 403 is a transport level error, but nothing important rests on my having said it. What I have said dominantly is that 403 is merely an *HTTP* status code because none of our WSDL overloads it in order to serialize a *WSDL* fault. Whether HTTP is a transport or an application protocol is not germane here. WSDL 2.0 says that WSDL faults are for application level bits. Thus, lacking any explicit serialization via any other HTTP code than 400 or 500, every HTTP code other than 400 or 500 is *not* a WSDL fault and, thus, is an HTTP status code. In which case the meaning of that code is to be interpreted according to RFC 2116. > IMO, WSDL's support for describing RESTful services is pretty poor, so > if you're going to use it I'd highly recommend defining the WSDL > *after* the HTTP interface is completely defined, so as to prevent > these problems with WSDL from messing up your messages. The latest CR draft is much better IMO (that doesn't mean it's *great* for this purpose, but it's less poor than it was). > So if you > need a corresponding WSDL fault in order to permit an HTTP 403 > response to be interpreted with QueryRequestConfused semantics, then I > think that should be defined. Yeah, if we wanted a WSDL level fault like that, we'd define one and serialize it with HTTP 403. But Andy's point, inasmuch as I understand it, has been that (1) we can't return anything but 400 or 500, per our spec; and (2) the use of "refuse" in QueryRequestRefused and HTTP 403 is problematic in some way. No one has shown much interest in defining additional WSDL faults, though I have proposed to simply remove QueryRequestRefused altogether. Thanks for your comments, Mark. Cheers, Kendall
Received on Wednesday, 11 January 2006 19:56:07 UTC