Re: Review of new HTTPbis text for 303 See Other

Pat,

On 10 Jul 2009, at 01:32, Pat Hayes wrote:
>> If the server has a transferable representation, it would
>> respond to the GET with the appropriate status code (200 or 304).
>
> Well, yes, IF it were driven solely by what one might call rational  
> HTTP architectural principles. BUt surely the whole issue about  
> httprange14 is that it introduces new principles which on their face  
> have nothing to do with http architecture as such, but to do with  
> denotation and naming.

Not as far as HTTP is concerned. HTTP is just a transfer protocol. The  
HTTP world is really simple:

1. There are URIs. URIs are thought to identify things called  
resources. As far as HTTP is concerned, it does not matter much what  
the resource actually is -- a document, a file on a server, a person,  
whatever.

2. Resources (whatever they are) are thought to have things called  
representations. As far as HTTP is concerned, it is totally up to the  
server owner to decide what's a representation of what. After the  
server owner has made their decision, a resource either has a  
representation or not.

3. If a resource has a representation, then a GET to its URI should be  
answered by 200. If not, then 303, 404 or 410 would be fine choices.

I repeat: For the operation of the HTTP protocol, IT DOES NOT MATTER  
what exactly a resource is and what the exact relationship between  
resources and representations is. All these matters of denotation,  
information resources and so on are introduced by higher layers of the  
architecture.

Yes, it would be useful to provide guidance to publishers about how  
best to model their information space as resources and  
representations. But this is out of scope for the HTTP protocol. The  
HTTP protocol kicks in AFTER the publisher has made up their mind  
about what resources they have and wether they have representations or  
not.

Now, different subcommunities have different opinions on how to model  
resources and representations. That's not a good thing, and it would  
be good for interoperability if everyone agreed. However, this is  
pretty much orthogonal to any discussion of the HTTP protocol. As long  
as the subcommunities subscribe to the basic "URI-identifies-resource- 
which-can-have-representations" model, HTTP can accomodate them.

Now let me take off my RDF hat for a bit.

The suggested change for the 303 text came about because one  
subcommunity had the funny idea that some resources SHOULD have URIs  
but NO representations and it should STILL be possible to get  
information about them via HTTP. It beats me why anyone would want to  
do that; but if we can make them happy with a minimal tweak to the  
language of an existing status code, then why not. HTTP is for everyone.

> If the URI in the GET request is not intended to denote the resource  
> to which the GET is directed, then that resource must issue a 303  
> redirection, and must not return a representation using a 200 status  
> code.

There is no such thing as denotation in HTTP. The only relation  
between URIs and resources in HTTP is "identifies". If you care about  
other relations, you have to figure out how to translate them into the  
"URI-identifies-resource-which-can-have-representations" model of HTTP.

> That has nothing to do with the existence or not of such a  
> representation. Even if the representation exists and the server has  
> access to it, it cannot return it with a 200 code when the URI is  
> intended to denote some other thing, in particular a non-information  
> resource of some kind.

Wether a representation exists or not for a particular kind of  
resource is entirely up to the server owner, as far as HTTP is  
concerned. If you subscribe to a religion that says, "Thou shall not  
make a representation of me, for I am not an information resource",  
then that's great, and let me shake your hand brother, but this has no  
effect on HTTP.

> If we follow your rule, above, and also httprange14, then a server  
> can be placed in an impossible position. If it has a representation  
> of itself which  could be put into a 200-code response, and it  
> receives a GET request with a URI which it knows (somehow, perhaps  
> by some externally agreed convention) is being used to denote a non- 
> information resource; what should it do? HTTPrange14 requires it to  
> not deliver a 200-coded reply, but your criterion requires that it  
> must. This is why I think the wording should make absilutely minimal  
> assumptions about what exactly the 303 means.

(RDF hat back on) Any sensible definition of "non-information  
resource" obviously MUST entail "does not have representations in the  
HTTP sense". In fact, that IS the definition of "non-information  
resource", in my book.

Wrapping up:

For the function of the HTTP transfer protocol, it does not matter  
what exactly the nature of the things identified by URIs is.

For the function of the HTTP transfer protocol, it does not matter  
wether the things you serve as representations on your server make  
particularly good representations of the resources.

There are different schools of thought that try to clarify the nature  
of the "identifies" and "has representation" relationships, and this  
is critically important if we want to use HTTP URIs as identifiers for  
things that exist outside of the Web. But the HTTP protocol itself is  
and should be agnostic with regard to your position in these debates.  
That's layering.

Best,
Richard



>
> Pat
>
>> ....Roy
>>
>>
>>
>
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 or (650)494  
> 3973
> 40 South Alcaniz St.           (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>
>
>

Received on Saturday, 11 July 2009 10:27:43 UTC