Re: 200 response as conclusive evidence of an information resource

On Dec 1, 2008, at 2:47 AM, Booth, David (HP Software - Boston) wrote:

> Are you saying that you think the httpRange-14 decision itself  
> contradicts the "URI owner" section of AWWW 2.2.2.1, or are you  
> saying that my interpretation contradicts it?

The latter.

>  Any in either case, why?


The httpRange-14 rule says, in effect, two things:

1. RFC 2616 previously licensed the http: scheme for use with network  
resources (sections 1.3 and 3.2.2), without explicitly prohibiting  
other uses. We hereby license the http: scheme so that you can use it  
with arbitrary other kinds of things as well.

2.  RFC 2616 licensed the HTTP protocol for use with request-URIs that  
denote "network data objects or services", without explicitly  
prohibiting other URIs. We hereby license the HTTP protocol with http:  
URIs denoting arbitrary things. However, for things that are not  
"information resources" per AWWW, please don't deliver 2xx responses,  
even though 2xxs are not explicitly prohibited by the RFC in this  
case. They might mislead someone into thinking the resource is an AWWW  
"information resource".

(Oddly, it says nothing about the use of the HTTP protocol with non- 
network-resources named by URIs belonging to non-http: URI schemes...)

One problem, as we've discussed, is the well-meaning off-label use of  
http: before the httpRange-14 rule came along, as with Dublin Core.  
Sure, if a URI owner agrees with the httpRange-14 rule, as you and I  
would like them to (modulo some uncertainty over what is and isn't an  
IR), then they should fix their server; but they have plausible  
deniability on their side, and could say nothing in RFC 2616 told them  
they couldn't use either the http: scheme or the HTTP protocol in the  
way they do. Bad practice by today's standards, sure, but not  
prohibited by spec. Those disagreeing with, or ignorant of, the rule  
could arguably still be in compliance with RFC 2616, and nothing could  
justify imputing semantics to their 200 response.

This is not a criticism of the rule - I think the rule is a good  
thing, for the reason stated (lowering the risk of misinterpretation),  
and would like people to follow it. But when I connect to a server and  
look at status codes, I can't count on the server (or those that  
control it) being aware of the rule. If you know ahead of time that a  
server has chosen to follow the rule, or does so by accident, then I  
agree that its 200s imply something about the nature of the resource.  
But lacking that I don't. Just because you can't count on everyone  
following it doesn't mean it's a bad rule.

A second problem is the dissonance between RFC 2616 and AWWW. You have  
to do serious semantic gymnastics to make these align. I would forgive  
anyone for saying (perhaps in RDF) that their network service, for  
which a 200 is legitimately delivered according to RFC 2616, is NOT an  
information resource in the AWWW sense. It is too easy to imagine that  
there are network services that CANNOT have their essential  
characteristics conveyed in a message - or at least that a careful URI  
owner wouldn't want attributed to them an assertion that their  
resource *was* an AWWW information resource. If you say that their  
200s will be interpreted this way, they will say they are following  
RFC 2616 to the letter and don't *want* their 200s to be interpreted  
that way. It doesn't matter that *you* think there's no contradiction.

(In fact we agreed that RFC 2616 "resource" and AWWW "information  
resource" are disjoint... or did I misunderstand?)

(I take RFC 2616 as a starting point, by the way, not only because  
that's what server software designers consult, but because it's where  
you land first via the "follow your nose" algorithm (after the URI  
scheme registry itself).)

Maybe I am being dense. Maybe it should be obvious to me that every  
network data object or service can have its essential characteristics  
conveyed in a message. Or maybe it's obvious that RFC 2616 should be  
ignored, or altered, where it is dissonant with AWWW (new covenant??)  
- maybe replace its definition of "resource" with a more modern one  
such as RDF's. Or maybe AWWW can be put aside or altered: redefine  
"information resource" to mean not what the glossary says but what RFC  
2616 means by "resource" (or some superclass of it). Or maybe we  
should throw away the specs and start de novo.  Any of these is  
possible, but we need to be honest and say what we're doing.

I'm not saying we don't have *influence* here and a chance to affect  
community behavior or thought - we could rewrite RFC 2616 or AWWW, or  
produce some kind of protocol extension or addendum or finding. I  
think it would be wrong to be Talmudic and try to figure out what the  
intent was, or should have been, or should be, behind these documents.  
We should start with what they say (especially RFC 2616, since it is  
going to reflect the deployed HTTP-web), and use this foundation as a  
way to identify inadequacies, survey the design space, and make  
recommendations.

In any case -- I think we should focus not on "information resource"  
or 200, but on the more central problem of describing in RDF what the  
participants in an HTTP request/response pair are saying to one  
another (to paraphrase Stuart). I know the 200/IR issue is part of  
this, but I think it will be much easier to deal with once we have an  
ontology that can address the more fundamental parts of the problem.

Jonathan

Received on Tuesday, 2 December 2008 18:12:43 UTC