Re: Review of new HTTPbis text for 303 See Other

On Jul 16, 2009, at 8:26 PM, Henrik Nordstrom wrote:

> tor 2009-07-16 klockan 06:42 -0500 skrev Pat Hayes:
>
>> Alternatively, it may be (cf my recent message to Richard) that the
>> phrase "the requested resource" is **always** understood to refer to
>> the resource that the URI denotes, or is intended to denote, even  
>> when
>> this is not the resource that the URI resolves to.
>
> It is.
>
> HTTP does not care how servers resolve URIs and should not. Nor does
> HTTP care about any meaning of URIs, just the existence of URIs and  
> that
> the indicated servers map these to resources.

Unfortunately, this use of 'map' terminology only confuses things even  
further. Many cases of the denotation relationship between URIs and  
resources cannot be mapped by any server, if 'map' refers to any kind  
of computable operation. I am using some words in these emails very  
exactly. In particular. "denote" (syn: "refers to") means that the  
symbol is a name for the entity denoted. This is the relationship  
between "Julius Caesar" and Julius Caesar, between "Patrick J, Hayes"  
and me, between "27" and the number twenty-seven. It has *absolutely  
nothing* to do with *anything* to do with network transport  
architecture,. It does not imply that any agent, natural or  
artificial, can do anything with the name to achieve any useful  
effect. It is not a computable relationship, and it is not one that  
can be used to gain any kind of access to the denotation starting with  
the name. There is no transport protocol for denotation. It simply  
refers to the semantic relationship between a name of something and  
the thing it is a name of. Nevertheless, HTTP URIs are used in this  
way to denote things. All this http-range-14 business comes up only  
because there is a need to make sense of these relationships between  
names, what they denote, and what HTTP responses they give rise to  
when servers are handed them. But the thing named need have no  
relationship, indeed no *possible* relationship, to any server or  
anything that can map anything to anything else.

> My reading of what you say above is that the URI resolves into a
> resource on the server even if the URI isn't meant to resolve into  
> that
> resource,

No, that is not what I said, and your misunderstanding of what I said  
is typical of the communication problems we find in these discussions.  
The relationship of denoting (referring to, naming, being a name of)  
is, prima facia at least, completely unrelated to issues of resolving  
on servers. Servers and networks and transport protocols simply have  
nothing to do with naming, unless and until we say that they do in  
some authoritative way. Any connection between these two notions can  
arise only by fiat: it does not follow from the definitions of the  
technical terminology being used. So when I refer to "the resource the  
URI denotes", I am not saying anything about resolution. I am simply  
talking about *denotation*. If a URI denotes me, then whatever happens  
to it when it gets to a server, whatever it gets mapped to, has  
nothing directly to do with me, and certainly does not involve me in  
any causal way: I do not take part in the transaction. I might be  
asleep, or in the future I might not even exist, and still the URI  
will be denoting me, and a server will need to do something  
appropriate with the URI.

The picture given by Richard, and to which I was reacting in the above  
quote, was this. URIs denote things. The HTTP GET takes a URI and  
resolves it to a server (not a resource) which responds with a  
**representation of the denoted resource** attached to a 200 code, if  
it has a suitable such representation. ("Suitable representation" here  
has to be given further gloss, as it is a nonstandard usage.) That  
makes sense, given that we further specify that some resources just  
don't have representations, so the server must issue a 303 code in  
those cases. Note that the represented, requested resource itself  
plays no part in this picture: it is all about servers and  
representations of resources.

> which at least to me doesn't make much sense. If this happens
> then either the wrong URI was used, or the server-side resource  
> mapping
> is wrong (broken). Or perhaps you use a different meaning for resource
> than intended by the HTTP protocol.

Well, part of the passion in these exchanges arose from Richard C's  
insistence that HTTP said *absolutely nothing* about meanings of URIs,  
so I am surprised to hear that the HTTP protocol intends any notion of  
meaning at all. But more to the point, it is now simply a fact that  
URIs are used as denoting names on the Web. Published W3C specs  
require them to play this role. Seems to me that http has two choices:  
it can completely ignore this fact, in which case it cannot intend any  
kind of meaning, or it can address the denotational meanings that URIs  
actually have. What is should not do is make rulings on these meanings  
which violate existing assumptions by the TAG, or which have  
consequences which do that.

>
> HTTP does intentionally not define any URI naming scheme or resolution
> model on servers, just the syntax of how valid HTTP-URIs may be built.
>
> The wording is meant to be read "for this specific Requested-URI",  
> as is
> any other property related to HTTP responses in general.

OK, that is good. It would help if that were stated explicitly, since  
the same server and the same resource can be located/identified by a  
different URI also. The wording which I was objecting to refers only  
to resources, so this point is not clear, as the same resource might  
be identified by several URIs.

> Not in a global
> sense, and bears no relation to any possibly related resources the
> server may have available privately or published at other URI  
> locations.
> 303 means that the server knows about the meaning of the requested URI
> but DO NOT have a representation suitable to be sent in response to
> requests for that specific URI,

The suggested wording refers to the 'requested resource'. You here are  
talking about the 'requested URI'. These are not the same. Which is  
correct? Ive been assuming that it is the resource that gets  
requested, and the URI is part of the request.

> which includes matching the intended
> meaning of that URI by whatever name scheme the server implements

No, it cannot possibly do that, in many cases. No implementation of  
anything is ever going to match anything to Julius Caesar, who has not  
existed for around 2000 years.

> even
> if the servers internal URI naming scheme resolver happens to find one
> or more possibly related resources but of which none which actually
> matches the servers intended meaning of the requested URI..

>
> What makes a resource suitable to be sent or not in response to  
> requests

Resources aren't sent in response, representations are. Did you mean  
representation?

Pat

> for a given URI is outside of HTTP specifications and nothing HTTP  
> cares
> about. That's purely a server side implementation decision.
>
> Regards
> Henrik
>
>
>

------------------------------------------------------------
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, 18 July 2009 17:56:27 UTC