Review of new HTTPbis text for 303 See Other

[Richard Cyganiak-2]

On 15 Jul 2009, at 18:22, Pat Hayes wrote:

>>> A 303 response to a GET request indicates that the server does
>>> not have a transferable representation of the requested resource
>
> Maybe I am misreading this. Consider an example, to help clarify. I  
> have an HTTP URI which, for reasons that need not detain us here but  
> which are set in stone, refers to a (non-information) resource, say  
> Richard Cyganiak the person. A GET with that URI resolves to an  
> endpoint which itself is (of course) a resource also, but not (of  
> course) the one that the URI denotes ("identifies"). Let us call  
> this resource R. This is the classical case that http-range-14  
> requires to have a 303 emitted to the client by R, or at least by  
> the http endpoint associated with R. (I am never quite sure of  
> exactly how the 'resource' relates to the http endpoint, but let us  
> try to ignore that issue here: the main point is that R, whatever it  
> is, is certainly not Richard Cyganiak .) Now, in this scenario, what  
> exactly is "the requested resource" in the above wording?

A good and helpful question.

So let's do a GET on http://example.com:8080/people/richard_cyganiak.

The way I see it, the requested resource is Richard Cyganiak. When I'm  
resolving the HTTP URI, a request is sent to a *server*, example.com,  
at port 8080, using the HTTP protocol, and the server responds with a  
certain status code. The HTTP interface/endpoint is the *server*, and  
not the individual resource. The resource -- the thing identified by  
the URI -- does not directly take part in the HTTP conversation. Its  
only relationship to the server is that a) the URI owner intends the  
URI to identify that resource, hence the server becomes responsible  
for answering requests to it, and b) the server holds (or not)  
representations of the resource.

This is certainly not the only possible interpretation supported by  
the language in the relevant documents, and it requires some mental  
gymnastics, but this interpretation works well for me and answers the  
"how are you going to attach an HTTP endpoint to an imaginary thing"  
argument.

Richard

> Is it R or is it Richard Cyganiak? Because I have been assuming that  
> this must mean R; but if it can mean a non-Webbish thing like a  
> person, then indeed the above makes perfect sense. In which case I  
> would only ask that the spec wording make it absolutely clear that  
> the "requested resource" need not be the resource that the URI  
> resolves to in a GET request. If, on the other hand, this is what  
> the phrase "requested resource" means, so that in my example it  
> refers to R rather than to Richard, then I object to the above  
> wording on the grounds that it is false: the 303 response should  
> *not* be taken to indicate that the server has no transferrable  
> representation of R. It may well have one (the fact is irrelevant to  
> the response) and indeed it may be able to make use of it under  
> other circumstances, as for example when resolved to by a GET using  
> a different URI. (For example, it might be important to be able to  
> discover what is 'acting for' Richard Cyganiak in these http  
> transactions, for security or trust purposes.)
>
> The basic point is that http-range-14 means that there may be  
> circumstances which have nothing whatever to do with  
> awww:representations, but which nevertheless require a server to  
> emit a 303 code; and the wording used should allow for this.
>
> Pat
>
>>> and is instead redirecting the client to some other resource
>>> for further information.
>>> then I think the objection is handled without watering down
>>> the purpose of using the status code on a GET.
>>
>> I'm happy to make this change if there are no objections, and it  
>> does make at least a few people less unhappy.
>>
>> BR, Julian
>>
>>
>>
>
> ------------------------------------------------------------
> IHMC                                     [phone] or (650)494  
> 3973
> 40 South Alcaniz St.           [phone]   office
> Pensacola                            [phone]   fax
> FL 32502                              [phone]   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>
>

[Dan Brickley-2]

On 16/7/09 10:01, Richard Cyganiak wrote:

> On 15 Jul 2009, at 18:22, Pat Hayes wrote:
>>>> A 303 response to a GET request indicates that the server does
>>>> not have a transferable representation of the requested resource
>>
>> Maybe I am misreading this. Consider an example, to help clarify. I
>> have an HTTP URI which, for reasons that need not detain us here but
>> which are set in stone, refers to a (non-information) resource, say
>> Richard Cyganiak the person. A GET with that URI resolves to an
>> endpoint which itself is (of course) a resource also, but not (of
>> course) the one that the URI denotes ("identifies"). Let us call this
>> resource R. This is the classical case that http-range-14 requires to
>> have a 303 emitted to the client by R, or at least by the http
>> endpoint associated with R. (I am never quite sure of exactly how the
>> 'resource' relates to the http endpoint, but let us try to ignore that
>> issue here: the main point is that R, whatever it is, is certainly not
>> Richard Cyganiak .) Now, in this scenario, what exactly is "the
>> requested resource" in the above wording?
>
> A good and helpful question.
>
> So let's do a GET on http://example.com:8080/people/richard_cyganiak.
>
> The way I see it, the requested resource is Richard Cyganiak. When I'm
> resolving the HTTP URI, a request is sent to a *server*, example.com, at
> port 8080, using the HTTP protocol, and the server responds with a
> certain status code. The HTTP interface/endpoint is the *server*, and
> not the individual resource. The resource -- the thing identified by the
> URI -- does not directly take part in the HTTP conversation. Its only
> relationship to the server is that a) the URI owner intends the URI to
> identify that resource, hence the server becomes responsible for
> answering requests to it, and b) the server holds (or not)
> representations of the resource.
>
> This is certainly not the only possible interpretation supported by the
> language in the relevant documents, and it requires some mental
> gymnastics, but this interpretation works well for me and answers the
> "how are you going to attach an HTTP endpoint to an imaginary thing"
> argument.

Hope this doesn't seem too much of a tangent, but I've been meaning to
mention this for a while: a long time ago, Andy Powell made a nice demo
of URN resolution using HTTP proxies, based on Netscape 4's behaviour of
passing URNs along to proxies.

See http://www.dlib.org/dlib/june98/06powell.html

"However, Netscape Navigator version 4 does contain some support for
URNs: if an HTTP proxy servier has been appropriately configured (see
next section), it will pass URNs on to an HTTP proxy for resolution."

This reminds me - apparently it is OK to ask an HTTP server (or at least
a proxy like http://en.wikipedia.org/wiki/Squid_(software) ) about
things (er, resources) whose URIs don't begin http*. In the above case,
Andy sent GETs for things with URNs...

I wonder how many of the URN namespaces registered in
http://www.iana.org/assignments/urn-namespaces/ are used to name
non-digital / non-serializable things?

cheers,

Dan

[Pat Hayes]

On Jul 15, 2009, at 10:11 PM, Mark Nottingham wrote:

> With my HTTPbis WG chair hat on:
>
> While some aspects of this thread have been related to HTTPbis'  
> work, it appears that we've resolved that portion, and many of the  
> other messages are not on-topic.

Agreed about the latter, but I do not accept that we have resolved the  
HTTPbis-relevant portion. The heated part of this thread began when I  
objected to Roy's proposed wording change on the grounds that the mere  
existence of a 200-level transmittable representation should not  
require that a 200-level response be returned. It seems to me, from  
the wording in the draft, that there could be circumstances in which a  
server has an associated resource, has a transmittable representation  
of it, and still is required (by http-range-14) to return a 303  
response **because the URI does not denote that resource**. Now, I  
quite understand if the HTTPbis WG prefers to not use language like  
"denotes" in the spec. In which case, all that needs to be done is to  
simply not **require** that the presence of a transmittable  
representation requires sending a 200 coded response (equivalently,  
not specify that a 303 response means that no transmittable  
representation **exists**.) This is enough slack to allow a server to  
handle the case in question without violating http-range-14.

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. If this is the  
case, then my objection to the wording, above, no longer applies. But  
then I would ask that the spec make this point extremely clear  
somewhere in the text, preferably by stating it explicitly. I realize  
of course that this would require using the word 'denotes', though I  
note that this word has crept into the recent URI specification also.

Thanks

Pat Hayes

[Pat Hayes]

On Jul 16, 2009, at 3:01 AM, Richard Cyganiak wrote:

> On 15 Jul 2009, at 18:22, Pat Hayes wrote:
>>>> A 303 response to a GET request indicates that the server does
>>>> not have a transferable representation of the requested resource
>>
>> Maybe I am misreading this. Consider an example, to help clarify. I  
>> have an HTTP URI which, for reasons that need not detain us here  
>> but which are set in stone, refers to a (non-information) resource,  
>> say Richard Cyganiak the person. A GET with that URI resolves to an  
>> endpoint which itself is (of course) a resource also, but not (of  
>> course) the one that the URI denotes ("identifies"). Let us call  
>> this resource R. This is the classical case that http-range-14  
>> requires to have a 303 emitted to the client by R, or at least by  
>> the http endpoint associated with R. (I am never quite sure of  
>> exactly how the 'resource' relates to the http endpoint, but let us  
>> try to ignore that issue here: the main point is that R, whatever  
>> it is, is certainly not Richard Cyganiak .) Now, in this scenario,  
>> what exactly is "the requested resource" in the above wording?
>
> A good and helpful question.
>
> So let's do a GET on http://example.com:8080/people/richard_cyganiak.
>
> The way I see it, the requested resource is Richard Cyganiak. When  
> I'm resolving the HTTP URI, a request is sent to a *server*,  
> example.com, at port 8080, using the HTTP protocol, and the server  
> responds with a certain status code. The HTTP interface/endpoint is  
> the *server*, and not the individual resource. The resource -- the  
> thing identified by the URI -- does not directly take part in the  
> HTTP conversation. Its only relationship to the server is that a)  
> the URI owner intends the URI to identify that resource, hence the  
> server becomes responsible for answering requests to it, and b) the  
> server holds (or not) representations of the resource.
>
> This is certainly not the only possible interpretation supported by  
> the language in the relevant documents, and it requires some mental  
> gymnastics, but this interpretation works well for me and answers  
> the "how are you going to attach an HTTP endpoint to an imaginary  
> thing" argument.

I agree, and this works very well for me also. If this is what the  
specs have meant all along, then I have been guilty of a multi-year  
misunderstanding. So, the whole HTTP thing is about servers and URIs,  
and 'resources" are simply the things that the URIs refer to, and they  
play no operational role in the protocol machinery. The URI resolves  
to a server, not to a resource.

Yes, I like that. Can one read the whole spec consistently with this  
picture, I wonder?

Pat

>
> Richard
>
>
>
>> Is it R or is it Richard Cyganiak? Because I have been assuming  
>> that this must mean R; but if it can mean a non-Webbish thing like  
>> a person, then indeed the above makes perfect sense. In which case  
>> I would only ask that the spec wording make it absolutely clear  
>> that the "requested resource" need not be the resource that the URI  
>> resolves to in a GET request. If, on the other hand, this is what  
>> the phrase "requested resource" means, so that in my example it  
>> refers to R rather than to Richard, then I object to the above  
>> wording on the grounds that it is false: the 303 response should  
>> *not* be taken to indicate that the server has no transferrable  
>> representation of R. It may well have one (the fact is irrelevant  
>> to the response) and indeed it may be able to make use of it under  
>> other circumstances, as for example when resolved to by a GET using  
>> a different URI. (For example, it might be important to be able to  
>> discover what is 'acting for' Richard Cyganiak in these http  
>> transactions, for security or trust purposes.)
>>
>> The basic point is that http-range-14 means that there may be  
>> circumstances which have nothing whatever to do with  
>> awww:representations, but which nevertheless require a server to  
>> emit a 303 code; and the wording used should allow for this.
>>
>> Pat
>>
>>>> and is instead redirecting the client to some other resource
>>>> for further information.
>>>> then I think the objection is handled without watering down
>>>> the purpose of using the status code on a GET.
>>>
>>> I'm happy to make this change if there are no objections, and it  
>>> does make at least a few people less unhappy.
>>>
>>> BR, Julian
>>>
>>>
>>>
>>
>> ------------------------------------------------------------
>> IHMC                                     [phone] or (650)494  
>> 3973
>> 40 South Alcaniz St.           [phone]   office
>> Pensacola                            [phone]   fax
>> FL 32502                              [phone]   mobile
>> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>>
>>
>>
>>
>>
>
>
>

------------------------------------------------------------
IHMC                                     [phone] or [phone]
40 South Alcaniz St.           [phone]   office
Pensacola                            [phone]   fax
FL 32502                              [phone]   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

[Xiaoshu Wang-3]

Alan Ruttenberg wrote:

> On Wed, Jul 15, 2009 at 6:01 PM, Xiaoshu Wang <xiao@...> wrote:
>  
>> That is my point of argument.  What is this "close-to-identical" (the fidelity as in this Sotomayor's defense) is non-sense.  The "fidelity" is always be interpreted by some one or some group.  There is no escape of this "personal" context.   Take your "high resolution"as an example, how do you know if I am not wanting the high resolution in terms of the molecular structure of that book, instead of its content or image? You must define your 'resolution' before making it high.  You cannot say compare two things without setting the criteria of comparison.  In other word, you cannot say which thing is a better awww:representation better than the other.
>>    
>
> We are in a bit of trouble, then, unless we remove whatever
> corresponds to rfc2616 section
> 3.9: 'Quality Values' from the new spec. That section presumes that it
> is indeed possible to make assessments of similarity/quality (or
> relative degradation) of a representation as compared to a resource.
>
> BTW, this wouldn't be semantics creeping into the nice neat
> specification, would it?
>
> Here is what I expect the form of the answer will be, given the
> previous parts of this conversation. The words "quality" and
> "degradation" are not what you and I mean by "quality" (closest
> wordnet http://www.golovchenko.org/cgi-bin/wnsearch?q=quality#2n) and
> "degradation" (closes wordnet sense, nominalization of
> http://www.golovchenko.org/cgi-bin/wnsearch?q=degrade#3v). They are
> awww:quality and awww:degradation, terms which allow for some scale
> along which to order representations, the exact nature of such
> ordering this spec need not be concerned with.
>
> -Alan
>
> (ietf-http-wg cc removed per request of Mark)
>  

I would think otherwise.  As long as there is a URI owner, it is fine.  
All the semantics are semantics expressed by that URI owner.  I have
thought about this but I don't see there is any other solution.
Transparent content negotiation might help but only on very complicated
cases. At last, it is a communication between two parties with no
previous knowledge of each other.

Xiaoshu  

[David Booth-6]

Oops!  That was intended to be off list, of course.  I guess I should
have trimmed the CC list before composing.  :)

On Wed, 2009-07-15 at 10:54 -0400, David Booth wrote:

> [Off list]
>
> FWIW, I wasn't able to follow Pat's point either, but I'd like to
> understand it, so if you and Pat don't mind copying me on your
> correspondence I would be interested.
>
> Thanks,
> David Booth
>
> On Wed, 2009-07-15 at 03:11 +0200, Richard Cyganiak wrote:
> > Thanks Larry. I wish I could talk with such clarity.
> >
> > I want to take the discussion with Pat a bit further, but will do so  
> > off-list. (Tomorrow, Pat -- I need to mull it over a bit.)
> >
> > I initially joined the thread to say this: The HTTP spec, with Roy's  
> > proposed new 303 text, accommodates all Semantic Web use cases I can  
> > think of. Including using HTTP URIs to denote people. It's good to see  
> > httpRange-14 slowly "trickle down" into the specs.
> >
> > Cheers,
> > Richard
> >
> >
> > On 14 Jul 2009, at 21:46, Larry Masinter wrote:
> >
> > > This conversation is filling my mailbox. Some general
> > > observations:
> > >
> > > (Pat, your arguments are laced with ad hominem, which makes reading
> > > the dialog unpleasant. I don't think Richard is being
> > > silly, intellectually dishonest, bloody arrogant, or any of the
> > > other terms you've used, please refrain.)
> > >
> > > It's the nature of standards discussions that people speak
> > > their point of view; doing so isn't arrogant.
> > >
> > > It is the nature of technical specifications that it is frequently
> > > necessary to take normal English words in particular technical
> > > way; it is not intellectually dishonest to do so.
> > >
> > > It is good practice for technical specifications in standards
> > > groups to say as little as possible in order to meet the
> > > needs of interoperability and the purpose for which the
> > > specification is being written.
> > >
> > > It is not necessary or even possible for a technical specification
> > > to answer questions that may be fundamental for applications
> > > that are outside of its scope. It is common, reasonable,
> > > and traditional for standards specifications to "not answer"
> > > questions because answering the question isn't necessary
> > > for the purpose for which the standard was written.
> > >
> > > It isn't necessary for the proper functioning of the web and
> > > to accomplish interoperability of web clients and servers
> > > to agree on how to use HTTP URIs and the HTTP protocol --
> > > for that purpose, it isn't necessary to answer the question
> > > of whether a HTTP URI can identify a person.
> > >
> > > It may be necessary to answer the question in a technical
> > > specification for the semantic web and in the RDF
> > > specification  -- but the answer more likely
> > > belong in those specifications and not in the
> > > IETF HTTP specification.
> > >
> > > It may be necessary for the IETF HTTP specification
> > > be edited in a way that made it clear that it didn't
> > > contain the answer to this question, but I'm not
> > > sure where to draw the line of describing things
> > > it doesn't answer.
> > >
> > > It's easy to imagine a system in which a URI is used
> > > to identify a person for the purpose of that system.
> > > But I can't see how IETF, W3C, or continued discussion
> > > on any of our mailing lists are going to converge
> > > any time soon on answers to the philosophical questions
> > > that have been with us for millennia. What is it
> > > that "Pat Hayes" identifies, anyway? Can I use
> > > mailto:phayes@... as a URI to identify you?
> > > Well, that's a question outside of the "mailto:"
> > > URI spec, I think.
> > >
> > > Perhaps  there needs to be a better way of distinguishing
> > > the statements "this specification does not limit the scope
> > > of applicability" and "this specification applies in all
> > > circumstances".
> > >
> > > If you had some better way of phrasing it so that it would
> > > be clear the former was meant rather than the latter, I
> > > think that would be helpful.
> > >
> > > The fact that something "does matter" -- to you, to the
> > > RDF community, to the W3C, to the world at large --
> > > does not mean that it is appropriate to "matter" in
> > > the context of the HTTP spec.
> > >
> > > It is an important design principle for developing
> > > specifications to keep specifications orthogonal: for the purposes
> > > of the HTTP protocol, it does not matter what resources
> > > are exactly. For the purpose of resource identification, it should
> > > not matter what the protocol is; tying semantic web
> > > interpretation to a particular error code in the HTTP
> > > protocol seems like bad design to me.
> > >
> > > The idea that the HTTP working group should care about the
> > > semantic web and change its specification to meet some
> > > semantic web requirement for use of HTTP URIs in semantic
> > > web applications  -- well, that raises several red flags
> > > for me, that we're building specifications that are not
> > > sufficiently orthogonal that things that *shouldn't* matter
> > > are taken as important questions that *must* be answered.
> > >
> > > The HTTP specification is *not* about what a "resource" is.
> > > It *is* about how to use and implement the HTTP protocol.
> > >
> > > There continues to be some confusion in the discussion between
> > > "URI" and "HTTP URI" that I find disturbing and confusing, because
> > > I think sometimes statements about one are attributed to the
> > > other. Not all URIs are HTTP URIs. Please try to be more careful.
> > >
> > > Regards,
> > >
> > > Larry
> > > --
> > > http://larry.masinter.net
> > >
> > >
> > >
> >
> >
> >
> >

--
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

[Henrik Nordstrom-5]

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.

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, 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.

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. 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, which includes matching the intended
meaning of that URI by whatever name scheme the server implements 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
for a given URI is outside of HTTP specifications and nothing HTTP cares
about. That's purely a server side implementation decision.

Regards
Henrik

[Pat Hayes]

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                                     [phone] or [phone]
40 South Alcaniz St.           [phone]   office
Pensacola                            [phone]   fax
FL 32502                              [phone]   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

[Henrik Nordstrom-5]

[resent from the correct address]

lör 2009-07-18 klockan 12:55 -0500 skrev Pat Hayes:

> 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.

And the point is?

HTTP does not care how URIs map to resources (in any terminology, but
see the end for what resource is in HTTP terminology), it's the role of
the server implementers and webmasters/authors to define such
relationships if any.

For some URIs the mapping is trivial and often even 1-1 (but may be
n-m), for some it's less obvious, and for some it may even be
impossible. HTTP does not care. What HTTP cares about is to provide
means for representing this at suitable level of detail as needed for
proper operation of HTTP where the proposed 303 response to GET is one
possible outcome.

HTTP operates with URIs and the representations of resources servers
return in response to requests to those URIs. End of story. Such
accesses MAY render effects outside HTTP (such as items being shipped to
you from a web shop, robots making some move, some electron bouncing
around, a valve opening/closing somewhere etc) but those effects are
outside of HTTP specifications.

In addition it places certain protocol level restrictions on how servers
may behave when there is many possible representations accessible via
the same URI, but that's a different topic.

> 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,

Good. So what is your argument exactly? At the level, view and context
of HTTP, ignoring the rest of the world.

> 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.)

In the context it simply means that the server is responsible to
determine if there is a representation available suitable to be used
when building the response and what that is if any. HTTP does not really
care how the server decides that.

> 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.

Yes, or to be exact when there is no suitable representation available
to be used for the HTTP response to this request for a valid URI which
do refer to some kind of resource as identified by the server.

> Note that the represented, requested resource itself  
> plays no part in this picture: it is all about servers and  
> representations of resources.

Fully agree.

> Well, part of the passion in these exchanges arose from Richard C's  
> insistence that HTTP said *absolutely nothing* about meanings of URIs,  

And it doesn't. That's part of the application of URIs to something, not
HTTP itself. For most the semantics of such application of URIs is even
outside the URI specifications and solely left to the actual
implementation/application of URIs.

> so I am surprised to hear that the HTTP protocol intends any notion of  
> meaning at all.

Not in my world.

> But more to the point, it is now simply a fact that  
> URIs are used as denoting names on the Web.

HTTP does not really care about this either.

> Published W3C specs require them to play this role.

At the level of HTTP, or at the level of user experience of URIs when
accessed via some user agent?

And what does those unnamed W3C specs have to do with the HTTP
specifications?

> 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.

The wording is in the context of how a sever can build a response to a
request for a specific URI, with no relevance to requests for other
URIs.

HTTP does not care much if the same resource has multiple URIs, with
just one minor optional exception (Content-Location).

> The suggested wording refers to the 'requested resource'.

Yes, as defined by HTTP. Not in the general English meaning (whatever
that is, I would not know what a "requested resource" is in general
English, or even Swedish for that matter).

> You here are talking about the 'requested URI'.

Yes, as a slight simplification I choose to ignore server driven
negotiation in this discussion, but that's besides the point.

> These are not the same. Which is correct?

In the terminology defined by HTTP the difference between an (HTTP-)URI
and resource is more of a special case, and not related to any of what
you talk about.

resource in HTTP terminology is NOT the general resource of anything you
seem to refer to, but in specific the resource within the server which
holds the information and/or processing required to build a suitable
representation to be used within HTTP (or as close to that you can get).
Yes it's a simplification, but defining or assume anything about
resources anywhere beyond that is outside of HTTP scope and nothing HTTP
cares about and is left to the application of HTTP and/or URIs. HTTP
does not care or imply anything about how those resources map to any
real-world or abstract resources beyond the operation of HTTP.

To quote the specifications:

p1-messaging, 2.1 Uniform Resource Identifiers

        HTTP does not limit what a resource may be; it merely defines an
        interface that can be used to interact with a resource via HTTP.
       
        [and reference to RFC3986 for further details about URI and
        resource in general]

p1-messaging, C. Terminology

        resource

                A network data object or service that can be identified
                by a URI, as defined in Section 2.1. Resources may be
                available in multiple representations (e.g. multiple
                languages, data formats, size, and resolutions) or vary
                in other ways.

Note: "resource" in 2.1 above refers to the more general RFC3986
meaning, in the rest of the HTTP documents it generally refers to the
HTTP definition of resource.

> > 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.

Not what I was talking about, and I don's see what your point with this
is either.

This response was in response to your talk about a resource (in general
terms) having multiple URIs with different meanings. My response is that
it's the servers role to select a suitable representation of the
resource based on the meaning of the URI. A server ignoring such meaning
as defined by the server would be in error with itself. In the terms of
HTTP each of those URIs actually refer to a resource of it's own as they
have different URIs and meaning, even if those resources perhaps are
very closely related.

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

Yes and no. The resource to be used when making an HTTP representation
of the requested resource. But see above for the HTTP meaning of
resource in this context.

Regards
Henrik

[Larry Masinter-3]

I'd like to ask that we start a separate task force and
mailing list on the topic of resolving any remaining issues
around the use of the word "resource" and the semantics
associated with it, with the task force chartered to come up with
satisfactory wording to propose as amendments, errata,
or updates to relevant documents. The initial
documents to be considered are:

(a) the URI specification RFC 3986
(b) the HTTP specification being developed in HTTPbis
 and (1) its definitions of "resource"
     (2) its definition of HTTP URI scheme
(c) the W3C TAG document AWWW
(d) the W3C TAG httpRange-14 finding
(e) the W3C RDF recommendation

Other documents and uses of the word "resource" may
be added to the scope once the task force has agreement
on this issues.

If we can get the participants in this discussion to focus
on specific proposals for updates to the documents in
question, I think it will help converge the discussion.

I observe that usage between W3C and IETF, TAG and HTTPwg
have been somewhat at odds, but the continued debate
cc'd between http-wg and W3C TAG mailing lists doesn't
seem to be converging.

I'd suggest that the task force, once established,
also have regular phone conferences.

I have bcc-d the HTTP-WG and TAG mailing lists,
because if we can get first get agreement among the major
participants of this discussion to work together to
produce a document representing an agreed perspective,
I'm sure the others on the mailing list will go along.

Regards,

Larry
--
http://larry.masinter.net

[Pat Hayes]

To cut to the chase, scroll down to [[**]]

Pat

On Jul 18, 2009, at 3:30 PM, Henrik & Anna Nordstrom wrote:

> lör 2009-07-18 klockan 12:55 -0500 skrev Pat Hayes:
>
>> 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.
>
> And the point is?
>
> HTTP does not care how URIs map to resources (in any terminology, but
> see the end for what resource is in HTTP terminology), it's the role  
> of
> the server implementers and webmasters/authors to define such
> relationships if any.

Apparently you have not understood my point, above. There are cases  
where NO implementation of ANY KIND can POSSIBLY map a URI to the  
resource it identifies. So one cannot simply toss this issue over the  
wall to some other, unspecified, "implementer". Its nothing to do with  
implementation.

>
> For some URIs the mapping is trivial and often even 1-1 (but may be
> n-m), for some it's less obvious, and for some it may even be
> impossible. HTTP does not care. What HTTP cares about is to provide
> means for representing this at suitable level of detail as needed for
> proper operation of HTTP where the proposed 303 response to GET is one
> possible outcome.
>
> HTTP operates with URIs and the representations of resources servers
> return in response to requests to those URIs. End of story. Such
> accesses MAY render effects outside HTTP (such as items being  
> shipped to
> you from a web shop, robots making some move, some electron bouncing
> around, a valve opening/closing somewhere etc) but those effects are
> outside of HTTP specifications.

I understand, but I am not talking about 'effects', but about semantics.

>
> In addition it places certain protocol level restrictions on how  
> servers
> may behave when there is many possible representations accessible via
> the same URI, but that's a different topic.

I am also not talking about behaviors.

>
>> 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,
>
> Good. So what is your argument exactly? At the level, view and context
> of HTTP, ignoring the rest of the world.

My point is that you cannot completely ignore the rest of the world.

>
>> 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.)
>
> In the context it simply means that the server is responsible to
> determine if there is a representation available suitable to be used
> when building the response and what that is if any. HTTP does not  
> really
> care how the server decides that.

Well, OK, that is fair enough, and I can live with that, provided we  
are clear about what exactly the 'requested resource' is. See [[**]]  
below.

>
>> 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.
>
> Yes, or to be exact when there is no suitable representation available
> to be used for the HTTP response to this request for a valid URI which
> do refer to some kind of resource as identified by the server.
>
>> Note that the represented, requested resource itself
>> plays no part in this picture: it is all about servers and
>> representations of resources.
>
> Fully agree.
>
>> Well, part of the passion in these exchanges arose from Richard C's
>> insistence that HTTP said *absolutely nothing* about meanings of  
>> URIs,
>
> And it doesn't. That's part of the application of URIs to something,  
> not
> HTTP itself. For most the semantics of such application of URIs is  
> even
> outside the URI specifications and solely left to the actual
> implementation/application of URIs.
>
>> so I am surprised to hear that the HTTP protocol intends any notion  
>> of
>> meaning at all.
>
> Not in my world.

BUt you yourself said that I was thinking about the wrong kind of  
meaning, not the kind of meaning intended by the spec. Really, you  
cannot have it both ways. Please make up your mind which is your  
position, and stick to it.

>
>> But more to the point, it is now simply a fact that
>> URIs are used as denoting names on the Web.
>
> HTTP does not really care about this either.

I know it does not wish to, but http-range-14 has left it no choice  
but to care about it, at least a little.

>
>> Published W3C specs require them to play this role.
>
> At the level of HTTP, or at the level of user experience of URIs when
> accessed via some user agent?

The semantics of URIs has nothing at all to do with layering. It is  
part of the specification **of URIs themselves**. When anyone talks  
about the relationship between a URI and the resource it identifies,  
or denotes, or refers to, or is used to request, or indeed pretty much  
any relationship between a URI and a resource, they are talking about  
semantics.

>
> And what does those unnamed W3C specs have to do with the HTTP
> specifications?

Because the HTTP specs also talk about this. And it is generally a  
good idea, when two specs talk about the same thing using the same  
language, that some effort is expended to make sure they are intending  
to use this language in the same way.

>
>> 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.
>
> The wording is in the context of how a sever can build a response to a
> request for a specific URI, with no relevance to requests for other
> URIs.

I understand, but it refers to resources. If for example the spec says  
(as I believe it does, currently) that if the server has available a  
transmittable representation of the requested resource, then it must  
return that with a 200 code, this statement makes no reference to the  
URI that was used to identify the resource. The only way I can read it  
is as saying that this applies **independently of the URI**, and hence  
to any URI which identifies the same requested resource. So the  
'context' you mention is irrelevant.


>
> HTTP does not care much if the same resource has multiple URIs, with
> just one minor optional exception (Content-Location).
>
>> The suggested wording refers to the 'requested resource'.
>
> Yes, as defined by HTTP. Not in the general English meaning (whatever
> that is, I would not know what a "requested resource" is in general
> English, or even Swedish for that matter).

In English, it would be the topic of a request for something that  
could be used for some purpose, as in "Please pass me the salt."

>
>> You here are talking about the 'requested URI'.
>
> Yes, as a slight simplification I choose to ignore server driven
> negotiation in this discussion, but that's besides the point.

No, it is quite on the point. If the server can respond differently to  
different URIs which both identify the same resource, that changes the  
game.

>
>> These are not the same. Which is correct?
>
> In the terminology defined by HTTP the difference between an  
> (HTTP-)URI
> and resource is more of a special case, and not related to any of what
> you talk about.

It is related. In fact it is critical.

>
> resource in HTTP terminology is NOT the general resource of anything  
> you
> seem to refer to, but in specific the resource within the server which
> holds the information and/or processing required to build a suitable
> representation to be used within HTTP (or as close to that you can  
> get).

Ah. That certainly makes sense, and indeed is what I understood when I  
first became involved in these URI-meaning debates. But this position  
is not consistent with what is said about resources in other  
standards.  And moreover, if this is true, then the http-range-14  
decision is simply untenable. For in that case, the 'requested  
resource' is something that cannot possibly be inside a server. Julius  
Caesar, let us say, might be the requested resource.

> Yes it's a simplification, but defining or assume anything about
> resources anywhere beyond that is outside of HTTP scope and nothing  
> HTTP
> cares about and is left to the application of HTTP and/or URIs.

No, sorry, that position is simply untenable. See me earlier replies  
to Richard on this point. HTTP cannot hide inside a 'layer' and  
pretend it is only dealing with computational identifiers which 'map'  
to computational artifacts. Both the uses and the specifications of  
http URIs have extended its scope beyond that narrow purview.

> HTTP
> does not care or imply anything about how those resources map to any
> real-world or abstract resources beyond the operation of HTTP.

The operation of HTTP, according to http-range-14, is ALREADY  
concerned with how URIs denote real-world entities beyond the  
operation of http. (Not, by the way, with how *resources* map to real-
world resources. In the cases in question, the relationship between  
the URI and the real-world entity is direct, not mediated through some  
other resource inside a server.)

>
> To quote the specifications:
>
> p1-messaging, 2.1 Uniform Resource Identifiers
>
>        HTTP does not limit what a resource may be; it merely defines  
> an
>        interface that can be used to interact with a resource via  
> HTTP.

But the phrase "that can be used to interact with a resource" ALREADY  
limits what a resource can be. You cannot interact with the number 27  
or with Julius Caesar.

>
>        [and reference to RFC3986 for further details about URI and
>        resource in general]
>
> p1-messaging, C. Terminology
>
>        resource
>
>                A network data object or service

That is not the definition of resource used in RFC3986, however. HTTP  
URIs can identify resources in the broader RFC3986 sense; and for  
those URIs, there may well not be any resource in this narrow sense  
identified by the URI at all. And yet, still, a GET on them might  
resolve to an http endpoint. What does the http spec say about such a  
case? What is the endpoint to do?

> that can be identified
>                by a URI, as defined in Section 2.1. Resources may be
>                available in multiple representations (e.g. multiple
>                languages, data formats, size, and resolutions) or vary
>                in other ways.
>
> Note: "resource" in 2.1 above refers to the more general RFC3986
> meaning, in the rest of the HTTP documents it generally refers to the
> HTTP definition of resource.
>
>>> 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.
>
> Not what I was talking about, and I don's see what your point with  
> this
> is either.

My point was only that the task which you said above is included,  
cannot in general always be included, since this task may be  
impossible in some cases.

>
> This response was in response to your talk about a resource (in  
> general
> terms) having multiple URIs with different meanings.

I don't know what 'meaning of a URI' means. I think of URIs as names  
which refer, and thats all the semantic meaning they have. The case in  
question was one in which the same HTTP endpoint - server - might have  
to process one URI which denotes an http-resource, and also another  
URI which has no such associated resource, and hence for which it, the  
endpoint, is obliged to emit a 303 response. And my point was only  
that in this case, it is at best confusing any maybe actually wrong to  
say that IF the server has a transmittable representation available  
then it must send it with a 200 code. For what are we to say about the  
second case? It all depends on what is meant by the "requested  
resource".  if, in the second case, that can be the denoted (non-http:  
but legally awww:) resource, then all is well. But if it simply means  
'an http:resource attached to the URI endpoint', then this requirement  
is inconsistent, in such a case, with http-range-14.

(It seems to me that HTTP rather shoots itself in the foot by this  
insistence that its specs must not refer to or even acknowledge the  
existence of resources that are other than network data or services,  
since it has defined out of existence the very case that it should be  
able to refer to, if only to explicitly say that its not going to  
specify what happens in it. This is rather an ostrich way of writing  
specs, to pretend that all of the world that you don't like doesn't  
exist, so that you aren't obliged to say anything about it.)

> My response is that
> it's the servers role to select a suitable representation of the
> resource based on the meaning of the URI.

Does that mean, of the resource that the URI identifies? And does  
"identify" mean, denote?

> A server ignoring such meaning
> as defined by the server would be in error with itself. In the terms  
> of
> HTTP each of those URIs actually refer to a resource of it's own as  
> they
> have different URIs and meaning, even if those resources perhaps are
> very closely related.

??!!? Of course two different URIs can refer to the same resource. If  
HTTP is built on a different supposition, then HTTP is simply wrong.

>
>> Resources aren't sent in response, representations are. Did you mean
>> representation?
>
> Yes and no. The resource to be used when making an HTTP representation
> of the requested resource.

[[**]]
?? I am trying to make sense of this, and not sure I have it right.  
Take the case in my email to Richard, where there is a URI denoting  
him, Richard C., the actual person. (Note, this is not a topic that  
HTTP gets to rule out or refuse to acknowledge, because this can in  
fact happen. My question is about what HTTP should do in such a case.)  
In this case, according to Richard, he is the 'requested resource'.  
The GET request is directed to a server which has some other resource  
inside it, call this resource R. R is a resource in your narrower  
sense (a network data object or service), but this is *not* the  
requested resource in this case, even though the URI resolves to (the  
server containing) R. (Do you agree?) In this case, http-range-14  
requires that the server emit a 303 coded response, because even  
though there may well be a transmittable (awww-) representation of R,  
there is none of Richard C., and he is the requested resource.

 From what you say here, I think you may have a different picture in  
mind, where the "requested resource" in this case must be R itself.  
That indeed is the picture I had originally, when I entered this  
thread. But in that case, Roy's suggested wording is inconsistent with  
http-range-14, because in this case it would prevent the server  
issuing a 303, as required by that decision.

Now, just to clarify, it seems to me that this case could arise even  
when R itself does not exist at all: there is simply a server which is  
able to recognize, somehow, that the URI in question identifies  
something other than a network data object or service, and so it  
cannot return a transmittable awww:representation of it. In HTTP  
terms, no http:resource exists at that endpoint to construct a  
transmittable representation from. Do you agree that this is a  
possibility, and is consistent with a 303 response? Or would you say  
that in this case, the only acceptable response would be a 400-code?

> But see above for the HTTP meaning of
> resource in this context.

Frankly. Im not very interested in any definition of 'resource' other  
than that in the URI specification, and I don't think that any  
published specification which refers to URIs should use any other  
definition. HTTP URIs are, in fact, being used to refer to resources  
in this broader sense. If the HTTP spec refuses to acknowledge this,  
then the world will simply go on and ignore the http spec in critical  
cases. Which would be a pity, but would not be a complete disaster.

Pat

>
> Regards
> Henrik
>
>
>

------------------------------------------------------------
IHMC                                     [phone] or [phone]
40 South Alcaniz St.           [phone]   office
Pensacola                            [phone]   fax
FL 32502                              [phone]   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

[Roy T. Fielding]

On Jul 19, 2009, at 7:28 AM, Larry Masinter wrote:

> I'd like to ask that we start a separate task force and
> mailing list on the topic of resolving any remaining issues
> around the use of the word "resource" and the semantics
> associated with it, with the task force chartered to come up with
> satisfactory wording to propose as amendments, errata,
> or updates to relevant documents. The initial
> documents to be considered are:
>
> (a) the URI specification RFC 3986
> (b) the HTTP specification being developed in HTTPbis
>  and (1) its definitions of "resource"
>      (2) its definition of HTTP URI scheme
> (c) the W3C TAG document AWWW
> (d) the W3C TAG httpRange-14 finding
> (e) the W3C RDF recommendation
>
> Other documents and uses of the word "resource" may
> be added to the scope once the task force has agreement
> on this issues.

For the record, I do not believe there is anything wrong with the way
resource is defined in RFC 3986.  I have no interest in discussing
it further because all of these arguments have already been covered
three times over.

The fact that some people insist that their personal/professional
ontology doesn't have room for any of the other definitions found
in a common dictionary is not, in my opinion, a protocol issue.
The term is defined in one place (3986) for the sake of documentation
and consistency, not for the sake of perfection in the minds of
every observer.  As far as the protocols are concerned, the fact
that it is a defined term is all that matters: it's definition
does not matter outside the philosophical realm.

We already spent six years of 2396 and 3986 development talking about
these issues.  HTTP (2616bis) is currently under revision and the plan
is to make it entirely consistent with 3986 (mostly by removing any
and all overlapping prose).  Change-requests to that text are welcome
on the httpbis lists/trac.  In particular, b1 and b2 on the list above
are currently waiting on me to get my act together, so expect them
both to be radically changed in httpbis over the next two weeks so
that they just point to 3986.

I cannot imagine revising 3986 (STD 66) again, at least not in our
lifetimes.  If you want to establish an official bike-shed painting
committee for the purpose of discussing what resource means, then
I suggest it should be done entirely within W3C, fed to the TAG for
review, and then (if any changes are warranted) an official errata
request be placed with the IETF.

....Roy

[Xiaoshu Wang-3]

Roy T. Fielding wrote:

> On Jul 19, 2009, at 7:28 AM, Larry Masinter wrote:
>
>> I'd like to ask that we start a separate task force and
>> mailing list on the topic of resolving any remaining issues
>> around the use of the word "resource" and the semantics
>> associated with it, with the task force chartered to come up with
>> satisfactory wording to propose as amendments, errata,
>> or updates to relevant documents. The initial
>> documents to be considered are:
>>
>> (a) the URI specification RFC 3986
>> (b) the HTTP specification being developed in HTTPbis
>>  and (1) its definitions of "resource"
>>      (2) its definition of HTTP URI scheme
>> (c) the W3C TAG document AWWW
>> (d) the W3C TAG httpRange-14 finding
>> (e) the W3C RDF recommendation
>>
>> Other documents and uses of the word "resource" may
>> be added to the scope once the task force has agreement
>> on this issues.
>
> For the record, I do not believe there is anything wrong with the way
> resource is defined in RFC 3986.  I have no interest in discussing
> it further because all of these arguments have already been covered
> three times over.
>
> The fact that some people insist that their personal/professional
> ontology doesn't have room for any of the other definitions found
> in a common dictionary is not, in my opinion, a protocol issue.
> The term is defined in one place (3986) for the sake of documentation
> and consistency, not for the sake of perfection in the minds of
> every observer.  As far as the protocols are concerned, the fact
> that it is a defined term is all that matters: it's definition
> does not matter outside the philosophical realm.

I agree with that -- how the word "resource" is defined in 3986 and
2616bis is O.K. as far as the protocol is concerned.  But the issue is:
whether AWWW and httpRange-14 has stretched that definition.  For
instance, the entire argument of AWWW/httpRange-14 is based on the
ambiguous concept of "ambiguity".  That is: one URI can only be used to
denote one thing.  But what is the "one" is no where to be defined.  If
a URI is used to denote both a person and a web page, it is *one* thing
that is both a person and a web page, unless there is an ontology
explicitly claim that Person disjoint with WebPage.

But what is relevant to  RFC3986/2616bis would be this.  Given a URI as
defined in RFC3986, would the resource that the URI denotes and the
representation (which 2616bis deals) are the same thing?  Should this
ontological question be answered?  If so, where?  AWWW?  If so, which
spec takes precedence?

There are two options:

One: RFC3986/RFC2616bis takes precedence and AWWW is built on top of
them.  In this case, anyone can built their own version of AWWW as long
as they comply with RFC3986/RFC2616.

Two, AWWW should prescribe over RFC3986/RFC2616bis.  If this is the
case, then we might need to think about RFC3986/RFC2616bis while
straightening out AWWW/httpRange-14.

I think here is what Larry's suggestion makes sense.  I do not think he
is suggesting that RFC3986 must be changed except the fact there needs
to be a cohesive story among these specs.

Xiaoshu

[Pat Hayes]

On Jul 20, 2009, at 1:23 PM, Roy T. Fielding wrote:

> On Jul 19, 2009, at 7:28 AM, Larry Masinter wrote:
>
>> I'd like to ask that we start a separate task force and
>> mailing list on the topic of resolving any remaining issues
>> around the use of the word "resource" and the semantics
>> associated with it, with the task force chartered to come up with
>> satisfactory wording to propose as amendments, errata,
>> or updates to relevant documents. The initial
>> documents to be considered are:
>>
>> (a) the URI specification RFC 3986
>> (b) the HTTP specification being developed in HTTPbis
>> and (1) its definitions of "resource"
>>     (2) its definition of HTTP URI scheme
>> (c) the W3C TAG document AWWW
>> (d) the W3C TAG httpRange-14 finding
>> (e) the W3C RDF recommendation
>>
>> Other documents and uses of the word "resource" may
>> be added to the scope once the task force has agreement
>> on this issues.
>
> For the record, I do not believe there is anything wrong with the way
> resource is defined in RFC 3986.

I would note that it is not in fact **defined** there. But, hasten to  
add, that is fine: the intent of RFC 3986 is perfectly clear. It could  
have been stated more succinctly by simply saying that the word  
"resource" was being used to mean "anything whatever that can be  
referred to and identified", but let us not split hairs. But this  
thread started because HTTPbis explicitly disagrees with RFC 3986 on  
what a resource is. Surely these various documents should at least  
agree on their uses of the basic technical terminology.

>  I have no interest in discussing
> it further because all of these arguments have already been covered
> three times over.
>
> The fact that some people insist that their personal/professional
> ontology doesn't have room for any of the other definitions found
> in a common dictionary

That is silly, and offensive. There is not, and never has been, an  
English dictionary that would give the RFC 3986 meaning for  
"resource", other than by this new use creeping into corpora such as  
Wikipedia. (The Wikipedia article documents this history quite well,  
in fact.)  And the issue (for me, at any rate, and I speak as one of  
the noisy ones on this issue) has never been to impose my personal  
ontologies on anyone, only to gain clarification of the intended  
meanings of the words in the specs as written: which, before RFC 3986,  
were extremely underdefined and indeed internally inconsistent.  
Personally, I find the RFC3986 usage ludicrous, pretentious and  
misleading, but it is the standard, so I am reconciled to using it.  
But then when I do, I expect other uses in other standards  
documentation to at least conform to this usage.

Being told to consult a 'common dictionary' is both unhelpful and  
extremely discourteous: it implies that I do not have an adequate  
grasp of my native language, a language in which I have been speaking,  
teaching and writing technical papers since you, Roy Fielding, were a  
babe in arms. And frankly, if you think that this usage of "resource"  
is found in a common dictionary, then you are the one who needs to  
spend more time with English dictionaries.

> is not, in my opinion, a protocol issue.
> The term is defined in one place (3986) for the sake of documentation
> and consistency, not for the sake of perfection in the minds of
> every observer.  As far as the protocols are concerned, the fact
> that it is a defined term is all that matters: it's definition
> does not matter outside the philosophical realm.

All of which would be fine if it actually had a definition. which is  
(still) does not. Not that it really matters, but just to set the  
record straight.

>
> We already spent six years of 2396 and 3986 development talking about
> these issues.  HTTP (2616bis) is currently under revision and the plan
> is to make it entirely consistent with 3986 (mostly by removing any
> and all overlapping prose).

I trust then that this will be removed (cited from Henrik's recent  
email) :

---------
p1-messaging, C. Terminology

        resource

                A network data object or service that can be identified
                by a URI, as defined in Section 2.1. Resources may be
                available in multiple representations (e.g. multiple
                languages, data formats, size, and resolutions) or vary
                in other ways.

Note: "resource" in 2.1 above refers to the more general RFC3986
meaning, in the rest of the HTTP documents it generally refers to the
HTTP definition of resource.
----------

Apparently the HTTP meaning of "resource" is, currently, explicitly  
different from the RFC3986 sense. So we are left with what might be  
called a comprehension impasse. When the HTTP documents refer to (for  
example) "the requested resource", do they use the word in this  
narrower sense or in the wider RFC3986 sense? If the former, what does  
this say about requested resources? That they **must** be, **by  
definition**, a 'network data object or service'?  (In which case,  
what about the case where an HTTP URI is being used to denote  
something which is not a resource in this narrower sense? Such cases  
exist. Does the HTTP spec simply ignore these cases? Or implicitly  
deny that they can occur, or implicitly prohibit them? Or does it  
imply, without explicitly saying so, that the resource (RFC3986 sense)  
being denoted by the URI may not be the resource (HTTPbis sense) which  
the URI identifies?)  Or, does the HTTP document in fact intend  
"resource" in the phrase "requested resource" to be understood in the  
wider RFC3986 sense? That would make sense, but I would not have any  
confidence that this was in fact what was intended, from the document  
as written or from any of the suggested wordings in this thread.

These are not questions that arise from my private ontology, they are  
critical questions which arise when trying to understand the actual  
words used in the specification documents themselves. The words are  
simply too ambiguous, too under-determined, to allow anyone to extract  
a clear answer to such questions; but they must be answered, and  
different answers will have different consequences for how actual  
software must be written. To make this point more forcibly, it seems  
clear for example that Henrik Nordstrom has an overall view of what  
the HTTP text is saying which is different from that which Richard  
Cyganiak has, at least based on their emails to this thread. For  
Henrik, if I understand him correctly, a "requested resource" must be  
a network object of some kind, located immediately behind the HTTP  
endpoint ('server') interface; for Richard, it is whatever the URI is  
understood to denote, whatever its nature. And it is surely not  
difficult to be more precise here. For example, just a simple sentence  
along the lines of  "A requested resource must be a network data  
object or service." would at least  clear up this misunderstanding,  
although it would not answer the other questions above.

I cannot recommend any text here, by the way, precisely because I do  
not want to impose any interpretations of my own. I want only to  
clarify the authors' intentions. But I cannot discern what those  
intentions are.

Pat Hayes

>  Change-requests to that text are welcome
> on the httpbis lists/trac.  In particular, b1 and b2 on the list above
> are currently waiting on me to get my act together, so expect them
> both to be radically changed in httpbis over the next two weeks so
> that they just point to 3986.
>
> I cannot imagine revising 3986 (STD 66) again, at least not in our
> lifetimes.  If you want to establish an official bike-shed painting
> committee for the purpose of discussing what resource means, then
> I suggest it should be done entirely within W3C, fed to the TAG for
> review, and then (if any changes are warranted) an official errata
> request be placed with the IETF.
>
> ....Roy
>
>
>

------------------------------------------------------------
IHMC                                     [phone] or [phone]
40 South Alcaniz St.           [phone]   office
Pensacola                            [phone]   fax
FL 32502                              [phone]   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

[Henrik Nordstrom-5]

mån 2009-07-20 klockan 13:16 -0500 skrev Pat Hayes:

> Apparently you have not understood my point, above. There are cases  
> where NO implementation of ANY KIND can POSSIBLY map a URI to the  
> resource it identifies. So one cannot simply toss this issue over the  
> wall to some other, unspecified, "implementer". Its nothing to do with  
> implementation.

For the kinds of URIs that HTTP deals with it can, as far as HTTP is
concerned with the definition of "resource" as used by http which for
technical specification writing reasons is slightly narrower than the
general URI definition of resource.

> I understand, but I am not talking about 'effects', but about semantics.

And HTTP is completely ignorant of any semantics that the URIs accessed
via HTTP may have.

What HTTP cares about is if there may be effects on the resource state
by actions requested by HTTP. (i.e. DELETE is assumed to have certain
effect when executed on the http resource)

> My point is that you cannot completely ignore the rest of the world.

When writing a technical specification you can, as the relevant part of
the world is then the parts that the specification intends to cover and
only those parts.

> BUt you yourself said that I was thinking about the wrong kind of  
> meaning, not the kind of meaning intended by the spec. Really, you  
> cannot have it both ways. Please make up your mind which is your  
> position, and stick to it.

HTTP places absolutely no meaning at all on the general term "resource"
as used in english or even the "resource" as defined by URI
specifications.

The only kind of resource HTTP places any meaning on at all is the very
much narrowed down "resource" as defined by the HTTP specifications, and
even then it's just as an abstract concept to simplify the world
description somewhat. To HTTP it does not matter at all what those
resources are, only if they can be accessed and/or transmitted via HTTP
or not as defined by whoever "owns" the resource and who also defines
their intended URI semantics (again completely outside of HTTP
specifications).

> I know it does not wish to, but http-range-14 has left it no choice  
> but to care about it, at least a little.

Has it? Care to explain that again then, using the term meanings as
defined by HTTP.

> The semantics of URIs has nothing at all to do with layering. It is  
> part of the specification **of URIs themselves**. When anyone talks  
> about the relationship between a URI and the resource it identifies,  
> or denotes, or refers to, or is used to request, or indeed pretty much  
> any relationship between a URI and a resource, they are talking about  
> semantics.

Ok. My point here is that HTTP does not care about those semantics. All
it possibly cares about is that the server is the ultimately responsible
for executing that semantic mapping of URI to resource (in URI terms),
and that this mapping results in HTTP network accessible resources
(which you seem to sometimes call a representation where HTTP calls it a
resource) and their possible representations as defined by HTTP.

> Because the HTTP specs also talk about this. And it is generally a  
> good idea, when two specs talk about the same thing using the same  
> language, that some effort is expended to make sure they are intending  
> to use this language in the same way.

Unfortunately if a new term is to be defined for every slight variation
there is of the term "resource" in this I am afraid it would be even
more confusing.

There is very good reasons why "resource" in the URI specifications
broader than "resource" in HTTP specifications and both being narrower
than the general English "resource".

> I understand, but it refers to resources. If for example the spec says  
> (as I believe it does, currently) that if the server has available a  
> transmittable representation of the requested resource, then it must  
> return that with a 200 code, this statement makes no reference to the  
> URI that was used to identify the resource.

The URI reference is implicit as the whole text is in the context of
builiding a response to a request for a specific URI. Trying to read the
text outside that context is non-sense.

>  The only way I can read it  
> is as saying that this applies **independently of the URI**, and hence  
> to any URI which identifies the same requested resource. So the  
> 'context' you mention is irrelevant.

You can not take random sentences from any specification and apply them
or draw conclusions without taking into account the context within the
specifications where that sentence was found.

> In English, it would be the topic of a request for something that  
> could be used for some purpose, as in "Please pass me the salt."

Yes, but that something may be pretty much anything, substantial,
abstract, quantifiable or non-quantifiable.

> No, it is quite on the point. If the server can respond differently to  
> different URIs which both identify the same resource, that changes the  
> game.

If the defined semantics of the URIs says the server should respond
differently then they in the world as defined by HTTP refer to different
resources, but possibly very closely related such.

It all boils down to the definition of what a resource is, and the HTTP
resource is as I already explained NOT as general as the URI resource.

> > In the terminology defined by HTTP the difference between an  
> > (HTTP-)URI
> > and resource is more of a special case, and not related to any of what
> > you talk about.
>
> It is related. In fact it is critical.

To me when talking about HTTP it's not.

> Ah. That certainly makes sense, and indeed is what I understood when I  
> first became involved in these URI-meaning debates. But this position  
> is not consistent with what is said about resources in other  
> standards.  And moreover, if this is true, then the http-range-14  
> decision is simply untenable. For in that case, the 'requested  
> resource' is something that cannot possibly be inside a server. Julius  
> Caesar, let us say, might be the requested resource.

And is what we have been saying all along. Trying to use Julius Casear
as an example when talking about HTTP resources just does not make any
sense as the two by definition can not be the same thing.

> > Yes it's a simplification, but defining or assume anything about
> > resources anywhere beyond that is outside of HTTP scope and nothing  
> > HTTP
> > cares about and is left to the application of HTTP and/or URIs.
>
> No, sorry, that position is simply untenable. See me earlier replies  
> to Richard on this point. HTTP cannot hide inside a 'layer' and  
> pretend it is only dealing with computational identifiers which 'map'  
> to computational artifacts. Both the uses and the specifications of  
> http URIs have extended its scope beyond that narrow purview.

And I disagree. The semantics of the application of HTTP is and should
be much broader than the semantics as used by the HTTP wire protocol.

> The operation of HTTP, according to http-range-14, is ALREADY  
> concerned with how URIs denote real-world entities beyond the  
> operation of http.

And my viewpoint is that that's completely outside of what the HTTP
specifications or operations is concerned about. In fact it
intentionally does not care about any such concerns and leaves that to
the application of HTTP to any such entities. Anyone is free to define
HTTP applications for such entities, by defining HTTP resources mapping
to such entities as they please. HTTP only defines how one may interface
with those once defined in terms of HTTP resources. What relations those
HTTP resources have to any real-world entities is defined by that
application, not by HTTP.

>  (Not, by the way, with how *resources* map to real-
> world resources. In the cases in question, the relationship between  
> the URI and the real-world entity is direct, not mediated through some  
> other resource inside a server.)

And in my world that's an impossible condition, as those real-world
resources do not exists in HTTP terms and need to be mediated via some
server defined HTTP resource to be accessible via HTTP, or requests for
that HTTP-URI would simply result in a 404 until a such HTTP resource is
implemented for mapping to the real-world resource.


> But the phrase "that can be used to interact with a resource" ALREADY  
> limits what a resource can be. You cannot interact with the number 27  
> or with Julius Caesar.

Please note that this part is just explanatory text trying to explain
the relationship between HTTP and URI specifications, not a normative
definition.

The definition of "resource" in the HTTP specifications is found in the
terminology section.


> >        resource
> >
> >                A network data object or service
>
> That is not the definition of resource used in RFC3986, however.

What I said, and why I highlighted it here. The definitions are
different, and you need to use the right definition for each
specification or you'll get confused when discussing borderline issues
like this.

For most practical considerations in the use of HTTP the difference is
negligible however.

> HTTP  
> URIs can identify resources in the broader RFC3986 sense; and for  
> those URIs, there may well not be any resource in this narrow sense  
> identified by the URI at all. And yet, still, a GET on them might  
> resolve to an http endpoint. What does the http spec say about such a  
> case? What is the endpoint to do?

Yes it's correct that HTTP URIs can identify resources in the broader
sense, but not something the HTTP specifications as such concerns itself
about. HTTP specifications end at the http endpoint and it's http mapped
resource.

> And my point was only  
> that in this case, it is at best confusing any maybe actually wrong to  
> say that IF the server has a transmittable representation available  
> then it must send it with a 200 code.

And we don't. We say "suitable to be transmitted", which is quite
different from "transmittable" as there is representations that MAY be
transmittable in theory but which is still deemed unsuitable (by the
http server endpoint or it's policy)

>  For what are we to say about the  
> second case? It all depends on what is meant by the "requested  
> resource".

The difference between a "resource" (as identified by a specific URI)
and an HTTP "requested resource" not what you think. The two differ when
there are multiple independent representations available by the exact
same URI, such as content in different language based on the language
preferences of the client etc.

> (It seems to me that HTTP rather shoots itself in the foot by this  
> insistence that its specs must not refer to or even acknowledge the  
> existence of resources that are other than network data or services,  
> since it has defined out of existence the very case that it should be  
> able to refer to, if only to explicitly say that its not going to  
> specify what happens in it. This is rather an ostrich way of writing  
> specs, to pretend that all of the world that you don't like doesn't  
> exist, so that you aren't obliged to say anything about it.)

I don¨t agree here. HTTP specifications places a technical limit on what
the word "resource" means within the HTTP specifications, which is
purely a technical definition.


> > My response is that
> > it's the servers role to select a suitable representation of the
> > resource based on the meaning of the URI.
>
> Does that mean, of the resource that the URI identifies? And does  
> "identify" mean, denote?

Sorry if I am unclear some times. English is not at all my native
language, and the word "denote" is not really part of my limited English
vocabulary.

>From my understanding of "denote" it's:

Of the HTTP resource the HTTP-URI identifies.

Where identifies as in is in the sense of how an Universal Resource
Identifier identifies a network-accessible resource, ignoring completely
what that resource denotes in the broader sense.

> ??!!? Of course two different URIs can refer to the same resource. If  
> HTTP is built on a different supposition, then HTTP is simply wrong.

Sure they can. The points here is:
 * that HTTP does not care if they do
 * and that HTTP has the view that if the semantics of those URIs is
different then they do in fact NOT refer to the same resource They may
refer to different facets of some larger/broader resource but not the
same.

If those URIs happens to really refer to the same resource both URIs
will respond identically, and further is indistinguishable from two
identical copies of the same resource.

> ?? I am trying to make sense of this, and not sure I have it right.  
> Take the case in my email to Richard, where there is a URI denoting  
> him, Richard C., the actual person. (Note, this is not a topic that  
> HTTP gets to rule out or refuse to acknowledge, because this can in  
> fact happen. My question is about what HTTP should do in such a case.)  

HTTP handles the case by restricting it's notion of resource to the
network-accessible resource used for interfacing with Richard C. That
resource MAY or MAY NOT have an actual interface with Richard C, HTTP
does not care and need not care for it's operations.

> In this case, according to Richard, he is the 'requested resource'.  
> The GET request is directed to a server which has some other resource  
> inside it, call this resource R. R is a resource in your narrower  
> sense (a network data object or service), but this is *not* the  
> requested resource in this case, even though the URI resolves to (the  
> server containing) R.

In terms of HTTP R is the requested resource.

>  (Do you agree?) In this case, http-range-14  
> requires that the server emit a 303 coded response, because even  
> though there may well be a transmittable (awww-) representation of R,  
> there is none of Richard C., and he is the requested resource.

That's up to R (or whoever/whatever defines R) to decide.

> From what you say here, I think you may have a different picture in  
> mind, where the "requested resource" in this case must be R itself.

Yes.

> That indeed is the picture I had originally, when I entered this  
> thread. But in that case, Roy's suggested wording is inconsistent with  
> http-range-14, because in this case it would prevent the server  
> issuing a 303, as required by that decision.

Roys answer is based on the HTTP definition of resource, not in the
broader sense.

If the server do have a an available representation of the resource
meant to be returned by access to this URI then it SHOULD be returned,
not an 303 response.

But even in the broader sense, if the server do have an available
representation of the resource but it's not meant to be returned and
should not be returned by access to this URI then it's not a valid
representation of the resource identified by this URI as the two (by URI
definitions, assuming here that there is another HTTP accessible URI for
accessing that representation) are different resources.

> Now, just to clarify, it seems to me that this case could arise even  
> when R itself does not exist at all: there is simply a server which is  
> able to recognize, somehow, that the URI in question identifies  
> something other than a network data object or service, and so it  
> cannot return a transmittable awww:representation of it.

In which case there still is an R in a technical sense as the server can
identify the resource (in the broader sense) and somehow act based on it
or information about it, thereby building an internal R http resource
with the details of what the requested URI refers to.

>  In HTTP  
> terms, no http:resource exists at that endpoint to construct a  
> transmittable representation from. Do you agree that this is a  
> possibility, and is consistent with a 303 response?

Yes.

> Or would you say  
> that in this case, the only acceptable response would be a 400-code?

No.

> Frankly. Im not very interested in any definition of 'resource' other  
> than that in the URI specification, and I don't think that any  
> published specification which refers to URIs should use any other  
> definition. HTTP URIs are, in fact, being used to refer to resources  
> in this broader sense.

The difference is because the broader sense has many implications which
has no impact on HTTP, and using the broader sense would complicate the
HTTP specifications as we would then need to apply these limitations
everywhere, resulting in even more confusing text.

> If the HTTP spec refuses to acknowledge this,  
> then the world will simply go on and ignore the http spec in critical  
> cases. Which would be a pity, but would not be a complete disaster.

The rest of the world is obviously free (and in many cases should)
ignore the HTTP definition of resource as it's of no relevance to them
just as the possible existence of real-world resources has no relevance
to the HTTP specifications.

Regards
Henrik

[Roy T. Fielding]

On Jul 20, 2009, at 1:27 PM, Pat Hayes wrote:

>> The fact that some people insist that their personal/professional
>> ontology doesn't have room for any of the other definitions found
>> in a common dictionary
>
> That is silly, and offensive. There is not, and never has been, an  
> English dictionary that would give the RFC 3986 meaning for  
> "resource", other than by this new use creeping into corpora such  
> as Wikipedia. (The Wikipedia article documents this history quite  
> well, in fact.)  And the issue (for me, at any rate, and I speak as  
> one of the noisy ones on this issue) has never been to impose my  
> personal ontologies on anyone, only to gain clarification of the  
> intended meanings of the words in the specs as written: which,  
> before RFC 3986, were extremely underdefined and indeed internally  
> inconsistent. Personally, I find the RFC3986 usage ludicrous,  
> pretentious and misleading, but it is the standard, so I am  
> reconciled to using it. But then when I do, I expect other uses in  
> other standards documentation to at least conform to this usage.
>
> Being told to consult a 'common dictionary' is both unhelpful and  
> extremely discourteous: it implies that I do not have an adequate  
> grasp of my native language, a language in which I have been  
> speaking, teaching and writing technical papers since you, Roy  
> Fielding, were a babe in arms. And frankly, if you think that this  
> usage of "resource" is found in a common dictionary, then you are  
> the one who needs to spend more time with English dictionaries.

Did I say "You", "Pat", or even include you in the address line?

I will point out, again, that I have twice posted the dictionary
entries and that they do encompass the meaning in 3986.  Of course
they are not the same *description* paragraph.

> I trust then that this will be removed (cited from Henrik's recent  
> email) :
>
> ---------
> p1-messaging, C. Terminology
>
>        resource
>
>                A network data object or service that can be identified
>                by a URI, as defined in Section 2.1. Resources may be
>                available in multiple representations (e.g. multiple
>                languages, data formats, size, and resolutions) or vary
>                in other ways.
>
> Note: "resource" in 2.1 above refers to the more general RFC3986
> meaning, in the rest of the HTTP documents it generally refers to the
> HTTP definition of resource.
> ----------

Yes, that is one of the many things already slated for removal,
along with finding and eliminating the cases where many different
authors used slightly varying terms to describe the stuff behind
the HTTP interface that they had no business describing in the
first place.

....Roy

[Dan Brickley-2]

On 21/7/09 03:37, Henrik Nordstrom wrote:

> mån 2009-07-20 klockan 13:16 -0500 skrev Pat Hayes:
>
>> Apparently you have not understood my point, above. There are cases
>> where NO implementation of ANY KIND can POSSIBLY map a URI to the
>> resource it identifies. So one cannot simply toss this issue over the
>> wall to some other, unspecified, "implementer". Its nothing to do with
>> implementation.
>
> For the kinds of URIs that HTTP deals with it can, as far as HTTP is
> concerned with the definition of "resource" as used by http which for
> technical specification writing reasons is slightly narrower than the
> general URI definition of resource.
>
>> I understand, but I am not talking about 'effects', but about semantics.
>
> And HTTP is completely ignorant of any semantics that the URIs accessed
> via HTTP may have.
>
> What HTTP cares about is if there may be effects on the resource state
> by actions requested by HTTP. (i.e. DELETE is assumed to have certain
> effect when executed on the http resource)

Perhaps we should all be talking about DELETE a bit more than about GET.
Some of the issues are starker...

if http://www.ihmc.us/users/phayes/PatHayes is directly Pat Hayes the
person (not a document about him), should HTTP DELETE remove Pat from
the world, or just remove that URI from the universe of information?

What's a compliant implementation to do?

>> The semantics of URIs has nothing at all to do with layering. It is
>> part of the specification **of URIs themselves**. When anyone talks
>> about the relationship between a URI and the resource it identifies,
>> or denotes, or refers to, or is used to request, or indeed pretty much
>> any relationship between a URI and a resource, they are talking about
>> semantics.
>
> Ok. My point here is that HTTP does not care about those semantics. All
> it possibly cares about is that the server is the ultimately responsible
> for executing that semantic mapping of URI to resource (in URI terms),
> and that this mapping results in HTTP network accessible resources
> (which you seem to sometimes call a representation where HTTP calls it a
> resource) and their possible representations as defined by HTTP.

So would be perfectly reasonable to have two Web sites / services /
installations, call them www-A and www-B, run according to similar
readings of HTTP?:

  * Both of them agree that
http://www-a.ihmc.us/users/phayes/PatHayesAbout and
http://www-b.ihmc.us/users/phayes/PatHayesAbout are names/identifiers
for Pat Hayes (ie. the person whose mailbox is phayes@...), rather
than for a page/document
  * Both of them implement HTTP verbs that proxy Pat into the Web, by
allowing (through GETs, 303 redirections etc) representations of him to
be exposed and accessed via the HTTP protocol
  * One of them reads an HTTP DELETE on the Pat URIs as a request to
adjust the world such that www-a no longer shares any information about
Pat via http://www-a.ihmc.us/users/phayes/PatHayesAbout (ie. "forget
this resource mapping").
  * the other reads a DELETE on
http://www-b.ihmc.us/users/phayes/PatHayesAbout as a request to adjust
the world such that Pat is no longer in it. an altogether more serious,
expensive and irreversible action.

Is there a fact-of-the-matter about whether website / webmaster www-A or
www-B has the correct reading of HTTP? Or the two are perfectly free to
diverge in their readings? If I am considering sending an HTTP DELETE
message to www-a and/or www-b, what information should I take into
account, while trying to determine how my messages will be understood?
Is there any way to find out?

If all HTTP verbs (including extensions) are always with regard to the
information-wrapping things, even if the URI is taken to name a "thing
in the non-digital world", this is important to know and to agree. If
it's up to the Web server, that's important to know. If nobody knows and
it's all a bit vague still, that's also important to know. I don't think
we collectively have a clear account of these issues yet.

>> No, it is quite on the point. If the server can respond differently to
>> different URIs which both identify the same resource, that changes the
>> game.
>
> If the defined semantics of the URIs says the server should respond
> differently then they in the world as defined by HTTP refer to different
> resources, but possibly very closely related such.

So HTTP always interposes a wrapper / proxy entity-thing-object (sheesh,
we're running out of neutral words :) ...

ie. even if we all agree that
http://www-a.ihmc.us:8080/users/phayes/PatHayesAbout
http://www-a.ihmc.us:80/users/phayes/PatHayesAbout
...are two names for the self-same thing (namely Pat), they are in
HTTP-speak inevitably going to be different (http:)"resources"? That's
my reading of your last post, at least.

(irrespective even of whether the same Apache webserver exposes
either/both of these, or different servers, or whatever - that's all
internal and not directly relevant)

> It all boils down to the definition of what a resource is, and the HTTP
> resource is as I already explained NOT as general as the URI resource.

(following through my example)

So, still in the world where we all "agree" that both
http://www-a.ihmc.us:8080/users/phayes/PatHayesAbout AND
http://www-a.ihmc.us:80/users/phayes/PatHayesAbout "are Pat"...

1. we have two different URIs
2. we have one wordly thing ("a URI resource?") that they name/identify;
a human person in this case.
3. we have two other kinds of thing (HTTP resources) that proxy/wrap
that person into the Web; each such "wrapping" is implemented by some
"HTTP server" thing that speaks HTTP to the digital world, and typically
has some private link to the single underlying thing named.
4. HTTP Verbs such as DELETE are understood in the context of one of
these (possibly many) bindings, rather than "in the abstract": the
server isn't getting a message saying "DELETE Pat Hayes" it is getting a
message saying "DELETE the HTTP resource /phayes/PatHayesAbout"
5. It isn't clear how much DELETing the server is expected to do; in OO
or SQL-backed sites, a DELETE might also cause the bound thing to be
removed, ie. information removed from some external backend system.
6. Whether the HTTP client who sent can be considered to have
*requested* for anything more than the resource-to-thing mapping to be
DELETEd isn't clear.


>>> In the terminology defined by HTTP the difference between an
>>> (HTTP-)URI
>>> and resource is more of a special case, and not related to any of what
>>> you talk about.
>> It is related. In fact it is critical.
>
> To me when talking about HTTP it's not.

At this point I picture someone stood up in court of law, flapping a
printout of the HTTP/1.1 spec, saying "but but ... you DELETEd my
*car*... Sure, we agreed the HTTP resource identified my car, but all I
wanted to do was remove that *mapping* when I sent an HTTP DELETE to
/car/32".

Do HTTP/1.1 experts have a role in adjudicating in such disputes?

How much deleting is http-justifiable?

>> The operation of HTTP, according to http-range-14, is ALREADY
>> concerned with how URIs denote real-world entities beyond the
>> operation of http.
>
> And my viewpoint is that that's completely outside of what the HTTP
> specifications or operations is concerned about.

HTTP DELETE is a destructive act, we can agree that I hope. To request
or to honour an HTTP DELETE request is to do something potentially
damaging (or potentially life-saving, even). If we don't know quite
clearly what an "HTTP DELETE" message is asking, how can anyone ever
risk sending one? Especially to complex Web services, that connect to
backend databases, sensors and to a rich world of ecommerce, users etc.

Yet these messages are regularly sent and handled. I can only assume
they are typically interpreted conservatively, or by a tighter
client/server implicit understanding than is mandated by HTTP alone.

> In fact it intentionally does not care about any such concerns and leaves that to
> the application of HTTP to any such entities. Anyone is free to define
> HTTP applications for such entities, by defining HTTP resources mapping
> to such entities as they please. HTTP only defines how one may interface
> with those once defined in terms of HTTP resources. What relations those
> HTTP resources have to any real-world entities is defined by that
> application, not by HTTP.

Can the nature of those mapping be hinted at or otherwise revealed
*through* HTTP?

>>   (Not, by the way, with how *resources* map to real-
>> world resources. In the cases in question, the relationship between
>> the URI and the real-world entity is direct, not mediated through some
>> other resource inside a server.)
>
> And in my world that's an impossible condition, as those real-world
> resources do not exists in HTTP terms and need to be mediated via some
> server defined HTTP resource to be accessible via HTTP, or requests for
> that HTTP-URI would simply result in a 404 until a such HTTP resource is
> implemented for mapping to the real-world resource.

>> URIs can identify resources in the broader RFC3986 sense; and for
>> those URIs, there may well not be any resource in this narrow sense
>> identified by the URI at all. And yet, still, a GET on them might
>> resolve to an http endpoint. What does the http spec say about such a
>> case? What is the endpoint to do?
>
> Yes it's correct that HTTP URIs can identify resources in the broader
> sense, but not something the HTTP specifications as such concerns itself
> about. HTTP specifications end at the http endpoint and it's http mapped
> resource.

So - just as any server that changes the *underlying* resource in
response to an HTTP GET is exceeding it's http-requested mandate, any
server that removes the *underlying*  real world (rather than
http-wrapping) resource on an HTTP DELETE is also exceeding what was asked?

concrete example (using SQL information objects as the real world object):

A car database, information about specific cars, stored in MySQL, and
exposed via Apache+PHP.

The SQL has a table, known_cars. that table has fields reg_number,
owner_email, price, for_sale, description_text, photo_url, car_id.

The Web site exposes each as /car/001 /car/002 using the car_id field.

Forget everything for now about whether /car/001 is a document or a car.
Here I am interested only in the question of where the "http resource"
stops, and the thing it maps to starts. And the mapping is firstly
through a set of descriptions that happen to live in a mysql db.

* do we agree that HTTP servers who change the underlying database
record after a GET are doing something that wasn't asked of them?
* do we agree that HTTP servers who change the underlying database
record after a DELETE are doing something that wasn't asked of them?


[...]

> The rest of the world is obviously free (and in many cases should)
> ignore the HTTP definition of resource as it's of no relevance to them
> just as the possible existence of real-world resources has no relevance
> to the HTTP specifications.

To be explicit ... The Car example here is supposed to emphasise that we
run into these same inclarities, even when the concern is with purely
digital stuff. An HTTP server wrapped around a database server, for
example. Do we consider the records in the SQL server to be intimate
pieces of the "http resources" (and hence they live and die by the same
HTTP verbs), or are they somehow merely mapped/linked.

I can imagine sysadmins and Web developers who quite reasonably answer
such questions differently, and structure their data integrity policies
accordingly. This matter of understanding how deep a DELETE request
should go isn't one which only arises when we are talking about cars and
people... but also when dealing with backend car SQL records or people
directly entries.

cheers,

Dan

[mnot]

Again, with my HTTPbis Chair hat on:

Since informally asking people to desist didn't work, I'll repeat my  
request more formally.

I'm declaring that discussion of this (roughly, the TAG's httpRange-14  
issue and the semantics of a resource) is temporarily off-topic on the  
ietf-http-wg mailing list, to allow the WG to focus on its chartered  
work during the lead-up to our meeting next week.

Further posts on this topic will be considered disruptive (see:  
RFC3934).

It will be on-topic again after the Stockholm meeting (i.e., next  
Friday). You are, of course, free to discuss it on the www-tag list.

Thank you for your cooperation,


--
Mark Nottingham     http://www.mnot.net/

[Henrik Nordstrom-5]

tis 2009-07-21 klockan 09:52 +0200 skrev Dan Brickley:

> if http://www.ihmc.us/users/phayes/PatHayes is directly Pat Hayes the
> person (not a document about him)

And I would argue it's not. It's one possible interface to Pat Hayes,
but it's not the person as such. There may be many other URIs which
references different aspects of Pat Hayes.

And based on the URI I would say it's possibly the Person Pat Hayes in
the context of being a user at ihmc, and is likely to cease exist some
time after has left/quitted his position at imhc. Not Pat Hayes the
person in the general sense, or other unrelated context. But I don't
know as it's up to whoever defined and implemented that URI.

> should HTTP DELETE remove Pat from
> the world, or just remove that URI from the universe of information?

As far as the HTTP specifications is concerned the DELETE is on the HTTP
resource as defined by the server, not the general term resource. For
resources having multiple URIs with the same meaning delete of one URI
does not neccesarily mean the other ones gets deleted as well as HTTP
does not say anything about how those relate to each other. It's up to
the server to define.

> What's a compliant implementation to do?

Well, at least I would not expect it remove Pat Hayes from the face of
the world only because someone sufficiently authorized asked for the
HTTP resource as published by the imhc http server to be removed.

> So would be perfectly reasonable to have two Web sites / services /
> installations, call them www-A and www-B, run according to similar
> readings of HTTP?:
>
>   * Both of them agree that
> http://www-a.ihmc.us/users/phayes/PatHayesAbout and
> http://www-b.ihmc.us/users/phayes/PatHayesAbout are names/identifiers
> for Pat Hayes (ie. the person whose mailbox is phayes@...), rather
> than for a page/document

Ok, if you say so.

>   * Both of them implement HTTP verbs that proxy Pat into the Web, by
> allowing (through GETs, 303 redirections etc) representations of him to
> be exposed and accessed via the HTTP protocol

Yes. Or other actions via other methods such as the hypothetical WALK,
RUN, SLEEP extension etc...


>   * One of them reads an HTTP DELETE on the Pat URIs as a request to
> adjust the world such that www-a no longer shares any information about
> Pat via http://www-a.ihmc.us/users/phayes/PatHayesAbout (ie. "forget
> this resource mapping").

Yes.

>   * the other reads a DELETE on
> http://www-b.ihmc.us/users/phayes/PatHayesAbout as a request to adjust
> the world such that Pat is no longer in it. an altogether more serious,
> expensive and irreversible action.

Yes. That's a possible (even if highly unlikely) real-world sideeffect
of that DELETE. HTTP does not define anything about it's effect on
actual resource beyond the operations of HTTP on HTTP resources. As far
as HTTP is concerned the result (in HTTP) is the same if the operations
is sent to the resource defined above, or to a resource which just
emulates that HTTP resource in the view/level of HTTP without having any
relation what so ever to any physical Pat Hayes.

> Is there a fact-of-the-matter about whether website / webmaster www-A or
> www-B has the correct reading of HTTP? Or the two are perfectly free to
> diverge in their readings?

The two are perfectly free to diverge as far as HTTP is concerned, as
long as the result at the HTTP level is consistent.

> If I am considering sending an HTTP DELETE
> message to www-a and/or www-b, what information should I take into
> account, while trying to determine how my messages will be understood?
> Is there any way to find out?

There is no way within HTTP to find out what sideeffects an HTTP
operation may have. Some operations like GET is defined in such way that
they SHOULD NOT have sideeffects, but it's not a guarantee (only a
SHOULD, not a MUST, which means even a GET MAY have sideeffects on some
servers).

> If all HTTP verbs (including extensions) are always with regard to the
> information-wrapping things, even if the URI is taken to name a "thing
> in the non-digital world", this is important to know and to agree.

Imho this is clearly spelled out in the HTTP specification by it's
definition of the verb "resource".

> If
> it's up to the Web server, that's important to know. If nobody knows and
> it's all a bit vague still, that's also important to know. I don't think
> we collectively have a clear account of these issues yet.

Everything which happens on the web server beyond what happens on the
HTTP message level is defined by the web server. HTTP does NOT touch how
web servers define resources or how the web server is to carry out
actions on those beyond the HTTP message syntax enabling these to be
represented in HTTP messages.

> > If the defined semantics of the URIs says the server should respond
> > differently then they in the world as defined by HTTP refer to different
> > resources, but possibly very closely related such.
>
> So HTTP always interposes a wrapper / proxy entity-thing-object (sheesh,
> we're running out of neutral words :) ...


>
> ie. even if we all agree that
> http://www-a.ihmc.us:8080/users/phayes/PatHayesAbout
> http://www-a.ihmc.us:80/users/phayes/PatHayesAbout
> ...are two names for the self-same thing (namely Pat)

And I would argue they are not. These are names for some HTTP interface
to Pat, but those URIs or what they identify in them selves are NOT Pat.
The thing they identify may well be 1-1 related to Pat, but that's an
implementation detail of no concern to HTTP.

>  they are in
> HTTP-speak inevitably going to be different (http:)"resources"? That's
> my reading of your last post, at least.

HTTP or URI specifications does not enforce one or the other. It's
implementation defined if those are in fact just two URIs to the same
resource on the server, or if they in fact are two completely different
resource.

HTTP does not define, restrict or say anything else about sideeffects on
another URI than the currently accessed URI, with the sole exception
that HTTP does include support to indicate tha ONE other URI on the same
server may have changed as result of certain operations.

> (irrespective even of whether the same Apache webserver exposes
> either/both of these, or different servers, or whatever - that's all
> internal and not directly relevant)

Correct.

> (following through my example)
>
> So, still in the world where we all "agree" that both
> http://www-a.ihmc.us:8080/users/phayes/PatHayesAbout AND
> http://www-a.ihmc.us:80/users/phayes/PatHayesAbout "are Pat"...
>
> 1. we have two different URIs
> 2. we have one wordly thing ("a URI resource?") that they name/identify;
> a human person in this case.
> 3. we have two other kinds of thing (HTTP resources) that proxy/wrap
> that person into the Web; each such "wrapping" is implemented by some
> "HTTP server" thing that speaks HTTP to the digital world, and typically
> has some private link to the single underlying thing named.
> 4. HTTP Verbs such as DELETE are understood in the context of one of
> these (possibly many) bindings, rather than "in the abstract": the
> server isn't getting a message saying "DELETE Pat Hayes" it is getting a
> message saying "DELETE the HTTP resource /phayes/PatHayesAbout"
> 5. It isn't clear how much DELETing the server is expected to do; in OO
> or SQL-backed sites, a DELETE might also cause the bound thing to be
> removed, ie. information removed from some external backend system.

As far as HTTP is concerned that's an implementation detail.

> 6. Whether the HTTP client who sent can be considered to have
> *requested* for anything more than the resource-to-thing mapping to be
> DELETEd isn't clear.

Indeed.

But whatever defined (in human terms) the meaning of that URI is
responsible for publishing this information as suitable to the required
parties in a way that users would have a reasonable chance of
understanding what their actions will result in. If not publishing that
URI would be very irresponsible if it has significant and irrevocable
sideeffects on anything.

> At this point I picture someone stood up in court of law, flapping a
> printout of the HTTP/1.1 spec, saying "but but ... you DELETEd my
> *car*... Sure, we agreed the HTTP resource identified my car, but all I
> wanted to do was remove that *mapping* when I sent an HTTP DELETE to
> /car/32".
>
> Do HTTP/1.1 experts have a role in adjudicating in such disputes?

See above.

> How much deleting is http-justifiable?

Not the business of HTTP to define. That's defined by the meaning of the
accessed URI and it's implementation.

> HTTP DELETE is a destructive act, we can agree that I hope. To request
> or to honour an HTTP DELETE request is to do something potentially
> damaging (or potentially life-saving, even). If we don't know quite
> clearly what an "HTTP DELETE" message is asking, how can anyone ever
> risk sending one? Especially to complex Web services, that connect to
> backend databases, sensors and to a rich world of ecommerce, users etc.

Sending DELETE usually requires a sufficient level of authorization,
which implies a bit of education on what DELETE really deletes in this
web application.

> Yet these messages are regularly sent and handled. I can only assume
> they are typically interpreted conservatively, or by a tighter
> client/server implicit understanding than is mandated by HTTP alone.

They are sent regularly as it's a very simple operation, with it's
effects easily defined on a per-resource basis, combined with the fact
that the user(agents) who are authorized to send these DELETE operations
also know the service they are deleting quite well.

> > In fact it intentionally does not care about any such concerns and leaves that to
> > the application of HTTP to any such entities. Anyone is free to define
> > HTTP applications for such entities, by defining HTTP resources mapping
> > to such entities as they please. HTTP only defines how one may interface
> > with those once defined in terms of HTTP resources. What relations those
> > HTTP resources have to any real-world entities is defined by that
> > application, not by HTTP.
>
> Can the nature of those mapping be hinted at or otherwise revealed
> *through* HTTP?

No.

Dosing so would require HTTP to dive into all possible meanings of URIs
which it does not intend to even touch. As already highlighted by Pat
any such definitions by HTTP would just restrict and confuse what kind
of resources HTTP may be applied to and in what ways HTTP may be applied
on those.

> So - just as any server that changes the *underlying* resource in
> response to an HTTP GET is exceeding it's http-requested mandate, any
> server that removes the *underlying*  real world (rather than
> http-wrapping) resource on an HTTP DELETE is also exceeding what was asked?

HTTP does not care how far a DELETE operation actually deletes the URI
identified resource. All it cares about is that it's deleted from that
specific URI. What happens beyond that is outside the scope of HTTP and
implementation defined.

The case of GET having sideeffects is slightly different. In this case
HTTP for very good reasons recommends that GET operations should not
have any sideeffects beyond the retreival of the requested resource, but
it's not something HTTP can or will enforce.

> * do we agree that HTTP servers who change the underlying database
> record after a GET are doing something that wasn't asked of them?

Yes, if that change has any significant meaning. I.e. updating a "view
count" is entirely fine, but erasing or singificantly modifying the data
is not recommended.

> * do we agree that HTTP servers who change the underlying database
> record after a DELETE are doing something that wasn't asked of them?

No. The server is entirely free to execute the DELETE in any way it sees
fit as far as HTTP is concerned. Possible actions

- Flag the row in the SQL table as no longer published via HTTP
- Move that to another table of "deleted" car entries, possibly
published via another URI.
- Remove the relevant row(s) from the SQL database
- Remove the server entity that knows /car/001 is the first row in the
cars table but keeping the SQL database intact, but most likely keeping
the one that knows /car/002 as removing that one as well would be odd
even if permitted. The implementation may well map the DELETE operations
to the common /car/ server resource if the number is implemented as an
argument, but this is not really the intended meaning.

The HTTP specifications limits itself to say that after a successful
DELETE /car/001 then /var/001 can no longer be used to refer to that
car, at least not until some other operation (HTTP or via other means)
adds it back.

> To be explicit ... The Car example here is supposed to emphasise that we
> run into these same inclarities, even when the concern is with purely
> digital stuff. An HTTP server wrapped around a database server, for
> example. Do we consider the records in the SQL server to be intimate
> pieces of the "http resources" (and hence they live and die by the same
> HTTP verbs), or are they somehow merely mapped/linked.

That's up to the implementation to define. But generally one intends
that a DELETE removes/deactivates the requested information and only
that.

> I can imagine sysadmins and Web developers who quite reasonably answer
> such questions differently, and structure their data integrity policies
> accordingly. This matter of understanding how deep a DELETE request
> should go isn't one which only arises when we are talking about cars and
> people... but also when dealing with backend car SQL records or people
> directly entries.

And HTTP leaves that to be defined by whatever defines the semantics and
operations of the URI in question, intentionally not touching this.
Everything that happens beyond the HTTP endpoint in the server is
implementation defined and outside of HTTP specifications.

The URI specification also has quite a lot to say on this topic, but as
noted is somewhat more general than the HTTP specifications. The HTTP
specifications apart from the wire protocol also defines the http:// URL
scheme which is a limited subset of URI.

Regards
Henrik

[Xiaoshu Wang-3]

[As Mark has adamantly requested, the HTTPbis working group list is
removed, although I do believe it is relevant.]

What I see from this discussion is a sense of chasing the illusive
absolute (truth) meaning.  If this is what you want to achieve, then I
guess you can fight to death yet without reaching any concrete conclusion.

Meaning is subjective, hence it is contextual because it requires an
owner or ontology to be clarified.   Meaning or semantics answer to such
kind of question: "what is X?" or "what does X mean?" These are the same
questions but the former is usually answered with an ontology while the
latter with an individual.

To answer: "X means Y" is ambiguous and always debatable. But, it is
undebatable if the answer is: "X means Y to o", where o is a particular
owner of the answer.  To give it a context -- the owner -- stops the
unnecessary debate.  It is what it is to "o", like it or not.

But to answer "X means Y to o1" or "X means Y' to o2" does not serve the
purpose to share meaning.  This is where the role of an ontology because
we can simply say "X means Y according to O", where O is an ontology.  
Again, you do not have to agree with O.  But to give it a context -- the
ontology in this case -- stops the unnecessary argument.

Now, let us come back to the topic of HTTP.  HTTP protocol is concerned
with helping the URI owner to produce representation of a given
resource. Thus,

200 means: Here is a representation of your request resource, as far as
I (URI owner) know.
303: Well, There is a representation of your requested, as far as I (URI
owner) know.
xxx: blah, blah, as far as I (the URI owner) know.

For client:

GET means: please get me the representation of the resource that you
(URI owner) think so.
DELETE: please delete me the representation of the resource that you
(URI owner) think so.

In a nutshell, HTTP implements the question/answer of: "what do you (the
URI owner) think of it (resource)?" And there is this context -- the URI
owner -- stops any kind of endless argument for its absolute meaning.

HTTP does not deal with ontological kind of question of "What is it
(resource)?"  The Web does.  The AWWW (but not the URI spec) are
supposed to answer this kind of question.

Take this context, URI owner, into this consideration and you will find
you will agree more than you disagree.  Henrik's mapping is the mapping
of an owner.  This is exactly the samething that Pat/Dan's wording of
"proxy/wrapper" etc.  Discuss semantics with a context, really.  
Otherwise, you will be chasing the impossible -- the absolute truth.

Xiaoshu