Subject: Re: Review of new HTTPbis text for 303 See Other

From: Jonathan Rees <[email-masked]>
Date: Tue, 7 Jul 2009 16:44:33 -0400

Comments inline below.

On Wed, Jul 1, 2009 at 12:56 AM, Julian Reschke<[email-masked]> wrote:
> Jonathan Rees wrote:
>>
>> Quoting from
>> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-06#page-24
>> :
>>
>>   A 303 response to a GET request indicates that the requested resource
>>   does not have a representation of its own that can be transferred by
>>   the server over HTTP.  ...  Note that answers to
>>   the questions of what can be represented, what representations are
>>   adequate, and what might be a useful description are outside the
>>   scope of HTTP and thus entirely determined by the resource owner(s).
>>
>> 1. I think the first sentence makes too strong a commitment. Some
>> sites are using 303 for resources that *do* have perfectly good
>> representations that can be transferred by the server over HTTP; they
>> just don't want to do so because they consider the 303 redirect to a
>> description of the resource to be more valuable than providing
>
> Could you please provide an example for a resource like that? My
> understanding of the 303/information resource issue always was that if the
> resource can be represented with a bag of bits then it *is* an information
> resource.

The TAG resolution, FWIW, says that if the response is a 303, the
resource can be any kind of resource - information or non-information.
My application is creating a large number of stable URIs (PURLs, in
effect) for what could be considered information resources, AND adding
metadata in the process, with the metadata reachable via 303. (The
data would be found in some other way, not via 200.) This is because
the metadata is deemed more important than the data.

Now I have three ways out. One is for me to tell myself that "the
requested resource does not have a representation of its own that can
be transferred by the server over HTTP", which of course is untestable
and so I doubt anyone would call me on it. Another is to ignore your
303 advice, as it will only have SHOULD status and not MUST status.
Yes another is to use LRDD to provide access to the metadata, but LRDD
is not likely to be ready before HTTPbis, and it's not obvious (yet)
that it will serve my purposes.

I can reverse the question and ask *you*: Tell me what kind of
resource "does not have a representation of its own that can be
transferred by the server over HTTP"? And what is an example of a
representation that cannot be transferred over HTTP? You have entered
one of the nastiest and most pointless debates around, that of the
boundary between information resources and other resources, and I
don't recommend going there - it's an ontological quagmire that has no
place in HTTPbis.

Better to just say that GET/303 may be used any time the server does
not choose, for whatever reason, to respond with a representation, but
rather with the location of a description of the resource. This is
easy to specify and describe and is compatible with the TAG's previous
advice.

>> ...
>>
>> I recommend changing this to something weaselly like
>>
>>   A 303 response to a GET request *may indicate* that the requested
>> resource
>>   does not have a representation of its own that can be transferred by ...
>> ...
>
> Assuming we did want to change it, it would still to be phrased in a way
> that explains what 303 means, not what it "may" mean...

See above. I don't think much meaning has to be given beyond that you
get the location of a description. You can leave the 200/303 choice up
to the server, just as a choice between a 300 and a 200 is up to the
server. The server just decided.

>> 2. The last sentence is also incorrect - to say that these decisions
>> are up to the resource's owner is also too strong a commitment. For
>> example, if I create a URI meant to "identify" my neighbor's car, it
>> is not necessarily up to my neighbor to determine what a useful
>> description of it is.
>
> From HTTP's point of view, the owner of the URI is the owner of the
> resource. It just doesn't care about the case where you use an HTTP URI to
> identify somebody's car.

But you are the one who raises the question. If you mean resource
owner in some narrow technical sense, instead of resource owner in,
say, a legal sense (e.g. copyright), you need to be clear. It wasn't
clear to me, and I don't think it's only because I'm steeped in a
world view that makes a clear separation between URI and resource
(e.g. the possibility that many URIs with different URI owners might
all identify the same resource).

Best
Jonathan

>> ...
> BR, Julian

---

From: ashok malhotra <[email-masked]>
Date: Tue, 07 Jul 2009 14:17:32 -0700

Jonathan said ...

"Better to just say that GET/303 may be used any time the server does
not choose, for whatever reason, to respond with a representation, but
rather with the location of a description of the resource. This is
easy to specify and describe and is compatible with the TAG's previous
advice."

Well said!  +1

All the best, Ashok

---

From: Yves Lafon <[email-masked]>
Date: Wed, 8 Jul 2009 05:50:36 -0400 (EDT)

> the metadata is deemed more important than the data.

How about qualifying the 303 response (which is something I really don't 
like as a response to a GET, a new code would have been better) using a 
Link: header to specify that the targeted resource is intended to be 
metadata?

> easy to specify and describe and is compatible with the TAG's previous

rfc2616 makes no assumption that it is metadata (hence my proposal above 
to use Link: in this specific case).

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

---

From: Julian Reschke <[email-masked]>
Date: Wed, 08 Jul 2009 12:18:51 +0200

Hi Jonathan,

> resource can be any kind of resource - information or non-information.

Indeed. (<http://www.w3.org/2001/tag/issues.html#httpRange-14>)

> that it will serve my purposes.

Well, it's not "my" advice, but the text this working group previously 
came up with. (I think Roy proposed it).

My understanding is that if you apply GET to a resource for which you 
*do* have a representation, than you should respond with a 200 status, 
and return it.

> transferred by the server over HTTP"? And what is an example of a

Those that Web-Arch calls "non-information" resources. Keep in mind that 
this specific text has been put it to address httprange; it wasn't 
present in RFC2616.

> don't recommend going there - it's an ontological quagmire that has no

I didn't enter it. Actually, the spec tries to avoid it:

"A 303 response to a GET request indicates that the requested resource 
does not have a representation of its own that can be transferred by the 
server over HTTP. The Location URI indicates a resource that is 
descriptive of the requested resource such that the follow-on 
representation may be useful without implying that it adequately 
represents the previously requested resource. Note that answers to the 
questions of what can be represented, what representations are adequate, 
and what might be a useful description are outside the scope of HTTP and 
thus entirely determined by the resource owner(s)."

> easy to specify and describe and is compatible with the TAG's previous

...but it seems to be a change to what HTTP said before; from HTTP's 
point of view it's strange to talk about resources that do have 
representations, but do not return them upon GET.

> server. The server just decided.

I understand that; but the language defining the status codes needs to 
be phrased so that it's clear what it means, not what it "may" mean.

> all identify the same resource).

Understood. How do others feel about HTTP's use of the term "resource 
owner"?

BR, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 8 Jul 2009 09:33:06 -0700

On Jul 8, 2009, at 3:18 AM, Julian Reschke wrote:

> Understood. How do others feel about HTTP's use of the term  
> "resource owner"?

Just change it to "URI owner".  No big deal,

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Wed, 08 Jul 2009 19:08:49 +0200

> Just change it to "URI owner".  No big deal,

Sounds good to me.

I just checked, the term "owner" is only used in Part 2; once for the 
description of the 303, twice for 410 Gone (where it is talking about 
the server's owner).

Unless somebody objects soonish, I'll make that change.

BR, Julian

---

From: Jonathan Rees <[email-masked]>
Date: Wed, 8 Jul 2009 16:08:06 -0400

> Hi Jonathan,
[...]
> Well, it's not "my" advice, but the text this working group previously came
> up with. (I think Roy proposed it).

I'm sorry, I didn't mean to single you out. I meant (and mean) "you"
collectively meaning the people who are graciously performing the
service of revising RFC 2616.

Can you tell me where the discussion is archived? I looked for it and
didn't find anything.

> My understanding is that if you apply GET to a resource for which you *do*
> have a representation, than you should respond with a 200 status, and return
> it.

There is plenty of precedent for doing otherwise: the server
can perfectly well choose 203, 300, 301, 302, 307, 401, 403, 409, 413,
414, 503... at its own discretion, even when it *does* possess a valid
representation.  303 is no different.

> this specific text has been put it to address httprange; it wasn't present
> in RFC2616.

OK, I knew it was new but was unaware of the motivation or process
leading to this particular text.

You (collectively) have failed to capture what the TAG's resolution
clearly says, which is that a 303 means it could be any kind of resource.

Enshrining the "information resource" idea in an RFC would be a
terrible idea, in my opinion, even if you change the way it's said to
"does not have a representation of its own". While I support the
reasoning that led to the httpRange-14 resolution, the definitions
provided for "information resource" are completely unsatisfactory -
and even if they were, they would be ontological, and would therefore
have no place in an RFC.  2616 should be about a protocol.  Let the
semantic web (or whatever) application layer take responsibility for
ontology.

According to the TAG's resolution, the difficulty of defining
"information resource" (or deciding whether something has a
representation) can be sidestepped just by returning 303 whenever
there is the slightest doubt.  If you restrict GET/303 to
non-information-resources, you remove this option, and will force
people to make subtle ontological distinctions (how many
representations can dance on the head of a pin) that they don't need
to make at present.

I don't mean to undermine the TAG's advice; I just want to establish a
separation of concerns, and point out that the advice is nuanced.  If
the purpose is to channel the advice, I advise you to pay careful
attention to what it actually says, since it is what people in the
linked data community have been programming to since 2005.

> "A 303 response to a GET request indicates that the requested resource does
> not have a representation of its own that can be transferred by the server
> over HTTP. [...]"

You enter the quagmire by requiring every protocol user to answer, for
every resource, the question of whether it "has a representation of
its own that can be transferred by the server over HTTP".  If yes,
the response has to be a 200; if no, it has to be a 303. This
question is both unanswerable and irrelevant to a protocol spec, and
forcing it on everyone will precipitate immeasurable agony.  Perhaps
some linked data application layer has some particular theory of which
resources have representations; that shouldn't be your concern.

> ...but it seems to be a change to what HTTP said before; from HTTP's point
> of view it's strange to talk about resources that do have representations,
> but do not return them upon GET.

Then don't talk about them.  Just say it is server discretion.  I
would be happy to work on wordsmithing with you if you agree in
principle to communicate something consistent with what the
httpRange-14 resolution says about 303, as opposed to the
current HTTPbis draft's distortion.

>> ... I don't think much meaning has to be given beyond that you
> I understand that; but the language defining the status codes needs to be
> phrased so that it's clear what it means, not what it "may" mean.

The server prefers to give you a description
of the resource rather than a representation because it thinks that's
the better choice.  Why is none of the RFC's business; it depends on
some application layer theory of resources, representations, and
descriptions that's out of scope.

By the way, I'm speaking strongly only to get the point across, not
out of anger. I'm glad you all have paid attention to codifying the
currently unauthorized GET/303 practice. I'm only looking for clarity
and consistency and to make sure that esoteric linked-data debates
stay inside W3C and don't spill over into IETF.

Best
Jonathan

-----

p.s. possible compromise: instead of

"the requested resource does not have a representation of its own that
can be transferred by the server over HTTP"

consider

"the server does not have a representation of the requested resource
that it can transfer over HTTP"

which makes no claims about the resource itself, only about the
server. This still doesn't match the httpRange-14 resolution exactly,
but it gives much broader scope to plausible deniability ("sorry, I
didn't have it"). Note that it subsumes the case where no one has a
representation because none exists, without going into the
uncomfortable details.

---

From: Pat Hayes <[email-masked]>
Date: Wed, 8 Jul 2009 15:37:16 -0500

On Jul 8, 2009, at 5:18 AM, Julian Reschke wrote:

> Well, it's not "my" advice, but the text this working group  
> previously came up with. (I think Roy proposed it).
>
> My understanding is that if you apply GET to a resource for which  
> you *do* have a representation, than you should respond with a 200  
> status, and return it.
>
> Those that Web-Arch calls "non-information" resources. Keep in mind  
> that this specific text has been put it to address httprange; it  
> wasn't present in RFC2616.
>
> "A 303 response to a GET request indicates that the requested  
> resource does not have a representation of its own that can be  
> transferred by the server over HTTP.

That just seems plain false. A 303 does not indicate that something  
does not exist. It simply indicates that the server, for reasons which  
may be entirely opaque and nobody is under any obligation to explain,  
has decided to redirect the query elsewhere. The http-range-14  
decision adds to this that, under these 303 circumstances, the  
original URI **may** be intended to denote something which has no  
representation appropriate to a 200 level response, but this is not  
actually implied by the 303 response itself, only permitted. The only  
actual constraint in all this is that if the URI elicits a 200 level  
response, then the payload of that response is a representation of the  
resource that the URI is understood to denote. And this does not  
mention 303 redirection.

Pat Hayes

> The Location URI indicates a resource that is descriptive of the  
> requested resource such that the follow-on representation may be  
> useful without implying that it adequately represents the previously  
> requested resource. Note that answers to the questions of what can  
> be represented, what representations are adequate, and what might be  
> a useful description are outside the scope of HTTP and thus entirely  
> determined by the resource owner(s)."
>
> I understand that; but the language defining the status codes needs  
> to be phrased so that it's clear what it means, not what it "may"  
> mean.
>

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

---

From: David Booth <[email-masked]>
Date: Wed, 08 Jul 2009 16:49:54 -0400

On Wed, 2009-07-08 at 12:18 +0200, Julian Reschke wrote:
[ . . . ]
> be phrased so that it's clear what it means, not what it "may" mean.

Then how about: "A 303 response to a GET request indicates either that
the requested resource does not have, or that the server chooses not to
send, a representation that can be transferred by HTTP . . . "

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

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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 8 Jul 2009 13:59:57 -0700

On Jul 8, 2009, at 1:37 PM, Pat Hayes wrote:
> does not exist. It simply indicates that the server, for reasons  
> which may be entirely opaque and nobody is under any obligation to  
> explain, has decided to redirect the query elsewhere.

No, we have other redirect codes for that.

> The http-range-14 decision adds to this that, under these 303  
> circumstances, the original URI **may** be intended to denote  
> something which has no representation appropriate to a 200 level  
> response, but this is not actually implied by the 303 response  
> itself, only permitted. The only actual constraint in all this is  
> that if the URI elicits a 200 level response, then the payload of  
> that response is a representation of the resource that the URI is  
> understood to denote. And this does not mention 303 redirection.

Please, folks, stop making up things about the HTTPrange-14 issue
which did not exist at the time it was resolved.  If there are problems
with the 303 definition (like "resource owner"), then they will be
fixed in the HTTP spec.  When the spec is approved, it will define
the protocol.  If people use the protocol incorrectly, that's their
problem.  The TAG decision was input to the process, not a sacred cow.

....Roy

---

From: Jonathan Rees <[email-masked]>
Date: Wed, 8 Jul 2009 17:30:15 -0400

> problem.  The TAG decision was input to the process, not a sacred cow.

I agree completely (although it would be nice if HTTPbis took into
account the way 303 responses are currently being used by the
community you thought you would serve by adding GET/303 to HTTPbis).
In my opinion this sentence

the server over HTTP."

makes up things about the decision - namely the idea that the server
would be in possession of information about the resource's
representations or lack thereof, and would use it in deciding what
responses to send. This change is consequential to current users of
GET/303 and I just don't understand why you want to do it.

Was your comment aimed only at Pat, or at me as well? What was your
opinion of my proposed compromise (the server doesn't have a
representation etc.)?

Jonathan

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 8 Jul 2009 15:03:55 -0700

> GET/303 and I just don't understand why you want to do it.

That's because you happen to be reading it differently than
what I was thinking when I wrote it.  The sentence is a bit
ambiguous if you don't pay attention to what the second "that"
means.  If it is reordered to say

  A 303 response to a GET request indicates that the server does
  not have a transferable representation of the requested resource
  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.

....Roy

---

From: David Morris <[email-masked]>
Date: Wed, 8 Jul 2009 15:49:35 -0700 (PDT)

> and is instead redirecting the client to some other resource

The "for further information" phrase feels squishy to me unless I've 
missed the definition of "further information". I'd be more comfortable 
with either removing the phrase or being more explicit about what "further 
information" is. Right now it seems like it could be an extended machine 
parsable explanation (i.e., executable code) of what to do OR a human 
readible html exception page OR just a resource whose representation is 
expected to be transferable. In my mind, too many ways to be different.

Dave Morris

---

From: Jonathan Rees <[email-masked]>
Date: Thu, 9 Jul 2009 06:03:42 -0400

> the purpose of using the status code on a GET.

Excellent! The rewording you give above would be fine with me - I
would be satisfied if HTTPbis said this, or something equivalent.
(because then the choice to yield a 303 can be attributed to the
server, and would not necessarily reflect on the nature of the
resource - "the server does not have" vs. "the resource does not
have".)

Best
Jonathan

---

From: Julian Reschke <[email-masked]>
Date: Thu, 09 Jul 2009 12:48:18 +0200

Sounds good to me.

BR, Julian

---

From: J Ross Nicoll <[email-masked]>
Date: Thu, 09 Jul 2009 14:17:17 +0100

Roy T. Fielding wrote:

>> has decided to redirect the query elsewhere.
> 

As I understand it, 301 (moved permanently), 302 (found) and 307 (not
modified) all indicate a different location for the resource, never for
an alternative to it. 304 is "Not modified", and 305/6 are
deprecated/reserved respectively. So, I don't think there is any other
redirect code for "Instead of the resource you requested, please see
this resource instead"...

---

From: Pat Hayes <[email-masked]>
Date: Thu, 9 Jul 2009 11:04:00 -0500

> resource - "the server does not have" vs. "the resource does not

Hmm, then I am puzzled. Does 303 redirection really imply that the  
server **does not have** a transferable representation? Surely 303  
redirection is used under other circumstances than this, circumstances  
which have nothing whatever to do with http-range-14 and were being  
used before the http-range-14 issue was even raised? No?

Pat

---

From: Xiaoshu Wang <[email-masked]>
Date: Thu, 09 Jul 2009 12:21:21 -0400

> used before the http-range-14 issue was even raised? No?
Why puzzled? It makes perfect sense.  A transportation protocol express 
the semantics of a server but not that of its resource.  At most, it 
express what the URI owner thinks about the resource denoted by the URI, 
but it is neither what the resource owner thinks nor what the resource is.

httpRange-14 is a bad design by forcing the latter semantics upon the 
URI owner. 

Xiaoshu

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 9 Jul 2009 10:01:29 -0700

On Jul 9, 2009, at 9:04 AM, Pat Hayes wrote:
> redirection is used under other circumstances than this,  
> circumstances which have nothing whatever to do with http-range-14  
> and were being used before the http-range-14 issue was even raised?  
> No?

No, at least not for GET requests.  303 (See Other) was originally
defined as "redirect with a different method" and not fully specified.
When HTTP was standardized, 303 became "see other" for the specific
purpose of redirecting a non-GET request to a GET of another resource.
Defining a specific purpose for 303 in response to a GET is what we
are doing right now.  There was no pre-existing usage of 303 in response
to a GET prior to the HTTPrange issue being decided.

....Roy

---

From: Pat Hayes <[email-masked]>
Date: Thu, 9 Jul 2009 12:13:24 -0500

On Jul 9, 2009, at 11:21 AM, Xiaoshu Wang wrote:

> Why puzzled? It makes perfect sense.  A transportation protocol  
> express the semantics of a server but not that of its resource.

That part I understand (and agree that the wording change is an  
improvement.) The part I am still worried about is the claim that a  
303 redirect necessarily means that the server *does not have* a  
representation. I think this is (a) wrong, in that such a  
representation may exist, but the server may choose not to deliver it  
for some reason on this occasion, and (b) needlessly strong, since  
nothing hinges on the existence or otherwise of this representation.  
The http-range-14 decision does not depend on this being the intended  
meaning of a 303 redirect: it requires only that a 200-level  
representation for the requesting URI is *not* delivered, even  
indirectly (as would be the case with a 301 or 307, for example). And  
since this is all that is required, it seems like good practice to not  
say anything more, on the grounds that whatever else is said will  
likely come back to bite you later.

For example, here is a possible scenario. I have an OWL ontology all  
about breeding horses, and it uses hash-coded URIrefs throughout to  
denote breeds of horse, like http://ex.thehorseplace.com/foo#arabian.  
I also want to use the bare URI http://ex.thehorseplace.com/baz to  
denote my company (not my website), so I need to do a 303 redirect  
when this URI comes along. All this is done by my one web server,  
however. So this entity which handles all this has access to a  
representation of itself, which it will 200-deliver when given the URI http://ex.thehorseplace.com/foo 
, but when given the URI http://ex.thehorseplace.com/baz it will  
ignore this representation and perform a 303 redirect to a document  
about my company. Now, I could say that there are two resources here,  
each with its own URI, but that wouldnt in fact reflect the reality of  
how my website is constructed. What there is, is one entity which has  
two URIs and which responds differently to them. In one case, it  
**has** a representation but **chooses** not to deliver it, in order  
to comply with http-range-14.

So, I would suggest changing the wording to something like:

A 303 response to a GET request indicates that the server will not  
deliver a transferable representation of ...

>  At most, it express what the URI owner thinks about the resource  
> denoted by the URI, but it is neither what the resource owner thinks  
> nor what the resource is.
>
> httpRange-14 is a bad design by forcing the latter semantics upon  
> the URI owner.

(Just to clarify for the record, I am not intending here to quarrel  
with http-range-14, only with the wording being used to express it.)

Pat

---

From: Xiaoshu Wang <[email-masked]>
Date: Thu, 09 Jul 2009 13:18:03 -0400

Pat Hayes wrote:
>>> and were being used before the http-range-14 issue was even raised? No?
> representation of itself, which it will 200-deliver when given the URI 
> http://ex.thehorseplace.com/foo, but when given the URI 
> http://ex.thehorseplace.com/baz it will ignore this representation and 
> perform a 303 redirect to a document about my company. Now, I could 
> say that there are two resources here, each with its own URI, but that 
> wouldnt in fact reflect the reality of how my website is constructed. 
> What there is, is one entity which has two URIs and which responds 
> differently to them. In one case, it **has** a representation but 
> **chooses** not to deliver it, in order to comply with http-range-14.
>
Yes, I think this wording is good.

Xiaoshu

---

From: Pat Hayes <[email-masked]>
Date: Thu, 9 Jul 2009 14:26:45 -0500

> to a GET prior to the HTTPrange issue being decided.

OK, thanks for the explanation. I had not realized that previous uses  
of 303 were restricted to non-GET requests. I guess this narrows the  
'meaning' of a 303 response even more tightly than I thought.

Pat

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 9 Jul 2009 16:16:06 -0700

On Jul 9, 2009, at 6:17 AM, J Ross Nicoll wrote:

>>> which

The only reason for a server to say "see this other resource
instead" to a GET request is that the person who configured
the server knows that this other resource is not the same as
the requested resource (i.e., not a 301/302/307) and yet wants
the client directed to that resource because it is more responsive
to the client's request than responding with a 404 or 410.

The only way a server can be responsive to the client's original
GET request (i.e., not broken or lying) is if the 303 response
points to a resource that describes the originally requested
resource.  Any other result would be pointlessly random, which
would be silly because 302 is already provided for pointlessly
random redirects.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 9 Jul 2009 16:22:09 -0700

On Jul 9, 2009, at 9:04 AM, Pat Hayes wrote:
> Hmm, then I am puzzled. Does 303 redirection really imply that
> the server **does not have** a transferable representation?

If the server has a transferable representation, it would
respond to the GET with the appropriate status code (200 or 304).

....Roy

---

From: Pat Hayes <[email-masked]>
Date: Thu, 9 Jul 2009 18:32:54 -0500

> respond to the GET with the appropriate status code (200 or 304).

Well, yes, IF it were driven solely by what one might call rational  
HTTP architectural principles. BUt surely the whole issue about  
httprange14 is that it introduces new principles which on their face  
have nothing to do with http architecture as such, but to do with  
denotation and naming. If the URI in the GET request is not intended  
to denote the resource to which the GET is directed, then that  
resource must issue a 303 redirection, and must not return a  
representation using a 200 status code. That has nothing to do with  
the existence or not of such a representation. Even if the  
representation exists and the server has access to it, it cannot  
return it with a 200 code when the URI is intended to denote some  
other thing, in particular a non-information resource of some kind.

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

Pat

---

From: Richard Cyganiak <[email-masked]>
Date: Sat, 11 Jul 2009 12:27:04 +0200

Pat,

On 10 Jul 2009, at 01:32, Pat Hayes wrote:
> denotation and naming.

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

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

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

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

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

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

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

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

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

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

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

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

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

> If we follow your rule, above, and also httprange14, then a server  
> can be placed in an impossible position. If it has a representation  
> of itself which  could be put into a 200-code response, and it  
> receives a GET request with a URI which it knows (somehow, perhaps  
> by some externally agreed convention) is being used to denote a non- 

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

Wrapping up:

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

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

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

Best,
Richard

---

From: Alan Ruttenberg <[email-masked]>
Date: Sat, 11 Jul 2009 18:47:54 -0400

On Thu, Jul 9, 2009 at 12:04 PM, Pat Hayes<[email-masked]> wrote:
>>>  not have a transferable representation

What does "transferable" add to representation?
Would it be possible for someone to give an example of an
*un*transferable representation?

Thanks,

-Alan

>>> of the requested resource
> Hmm, then I am puzzled. Does 303 redirection really imply that the server
> **does not have** a transferable representation? Surely 303 redirection is
> used under other circumstances than this, circumstances which have nothing
> whatever to do with http-range-14 and were being used before the
> http-range-14 issue was even raised? No?
>
> Pat
>
>>
>> Best
>> Jonathan
>>
>>
>

---

From: Alan Ruttenberg <[email-masked]>
Date: Sat, 11 Jul 2009 19:25:08 -0400

> answered by 200. If not, then 303, 404 or 410 would be fine choices.

This *should* is not warranted. As there is often no way to include
structured information *about* a resource in-band of the
representation (sense http/awww), or to include it in a way that is
predictable by the requester, is a perfectly reasonable choice to use
303 to interpose and therefore provide a way of supplying this "about"
information. In those cases where someone is confident enough that a
200 response would have been appropriate, that one can supply
information *about* the resource (in RDF, for instance) means that
there is an opportunity to indicate (with the potential for being much
more precise than http) where that "representation" can be fetched
from.

-Alan

---

From: Alan Ruttenberg <[email-masked]>
Date: Sat, 11 Jul 2009 19:28:16 -0400

> would be silly because 302 is already provided for pointlessly

"describes", "is about", "has topic" - there are a number of names for
the relation of the 303 response to the originally requested resource.
I agree with your assessment here and would welcome stronger language
in the specifications that make clear this expectation about 303
responses.

-Alan

---

From: Pat Hayes <[email-masked]>
Date: Sun, 12 Jul 2009 18:31:56 -0500

On Jul 11, 2009, at 5:27 AM, Richard Cyganiak wrote:

>> httprange14 is that it introduces new principles which on their  
>> face have nothing to do with http architecture as such, but to do  
>> with denotation and naming.
>
> Not as far as HTTP is concerned. HTTP is just a transfer protocol.  
> The HTTP world is really simple:
>
> resources.

OK, stop there and tell me what you mean here by "identifies".  
Because...

> As far as HTTP is concerned, it does not matter much what the  
> resource actually is -- a document, a file on a server, a person,  
> whatever.

... in the usual sense of 'identifies' that one might expect to be use  
in the context of a network transfer protocol, which is similar to the  
use one might expect when talking about programming language  
identifiers and what they identify, it most certainly does matter. In  
particular, it simply does not make sense to speak, using that normal  
terminology, of 'identifying' a person (or a galaxy or a sodium atom,  
etc.); in fact, it does not make sense to talk of identifying anything  
much beyond some kind of data structure or data object. So if HTML  
claims to be able to make sense of talking of 'identifying' people  
(for example), it must be in a wholly different space than all  
previous computationally based notational systems, and be using the  
word "identify" in a wholly different sense. And, to repeat, can you  
tell me what that sense is?

> representations. As far as HTTP is concerned, it is totally up to  
> the server owner to decide what's a representation of what. After  
> the server owner has made their decision, a resource either has a  
> representation or not.

Really? OK, I will take you at your word. I am a server owner, and I  
will decide that a certain resource, to wit, me, has a thing called a  
representation of me. This representation of me is in fact a portrait,  
painted using acrylic paints on a piece of masonite approximately 30  
cm square almost exactly a month ago: but let us not go into details,  
as you tell me that such details are none of HTTP's business. Still,  
the representation exists, and the resource has it. OK, let us proceed.

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

So, HTTP must reply to a GET on my URI with a 200. OK, what should it  
put as the payload of this 200 response, attached to the code  
information? HOw do I get acrylic-coated masonite into an http  
response? There is no representation which can be transmitted in bits.  
You did not mention this aspect in your above summary: was that an  
omission?

> resources and representations is.

As you can see, I took advantage of this freedom in my example.

> All these matters of denotation, information resources and so on are  
> introduced by higher layers of the architecture.

Wrong. Denotation is not introduced by a higher level, and even if it  
were, it would not be higher in an architectural sense. You, in this  
very message, in fact brought denotation into the picture, by telling  
me that a URI can "identify" a person. URIs are symbols strings, and  
the ONLY POSSIBLE SEMANTIC RELATIONSHIP between ANY symbol and a  
physical object, is denotation. Sorry to shout there a little, but the  
point needs to be made strongly. That is what "denotation" means: it  
is all that is left of "identifying" when you take away the actual  
network machinery, the computational byte-transferring. And you have  
to take this away when you start claiming to talk of relationships  
between names (of any kind) and non-computational entities such as  
people (or indeed of any kind), simply because computational byte- 
transfer talk is COMPLETELY IRRELEVANT to semantic relationships (such  
as "identification") between symbols (of any kind) and non- 
computational entities. The fact, if it is a fact, that this word is  
not in your technical vocabulary is entirely irrelevant. By claiming  
that your symbols "identify" non-computational entities such as people  
or books (or the weather in Oaxacala, to take another random  
example) , you are no longer playing in the network-architectural  
sandbox, precisely because these kind of things simply are not  
connected to networks in the same functional sense that things like  
web servers are. Either HTTP is a computational notion or it isn't. If  
it is, then it is indeed quite simple. And I would be delighted if the  
HTTP literature simply restricted itself to the computational world.  
But it does not, and never has: HTTP has ALWAYS had these claims to  
semantic grandeur: it has ALWAYS claimed to be not just about web  
sites and web servers and files and documents, but about the whole  
grand span of symbol usage to refer to absolutely anything in any  
possible universe. And if indeed that is what HTTP is claiming to be  
able to talk about, then it is about denotation, right out of the box.

> representations. But this is out of scope for the HTTP protocol.

See above. If indeed it is out of scope, so is any talk of URIs  
"identifying" people. You can't have it both ways. Either you are  
doing real semantics or you aren't. If you aren't, then don't make  
ridiculous claims about "identifying" things that have no possible  
connection to any physical network, or of "representations" that  
cannot be sent in a byte stream.

> The HTTP protocol kicks in AFTER the publisher has made up their  
> mind about what resources they have and wether they have  
> representations or not.

OK, please tell me how to use HTTP to send my piece of masonite  
attached to a 200 code. I've made up MY mind: over to you.

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

No, that is not the primary reason. Http-range-14 is not about  
resources, it is about URIs and what they denote. The dilemma is that  
people want 'normal' URIs to denote what it that HTTP thinks of them  
as identifying, the "information resource" (not that that matters).  
Which would be fine, except that there are some URIs which people want  
to denote something else. And still, actually for different ('linked  
data', Timblish) reasons, people want a GET on those URIs to finish  
up, one way or another, with useful information being returned. This  
is a problem. It would be ugly to have two 'kinds' of URI, and  
impossible to change the millions of 'normal' URIs in any way at all.  
The decision allows the few non-normal URIs to take part in a slightly  
irrational HTTP dance which allows everyone to say: look, since it  
didn't return a 200 code, its not 'normal', and HTTP says it doesn't  
identify anything at all; so the 'normal' assumptions about what it  
denotes are cancelled. And that cancellation is the entire content of  
the decision: it has no other purpose. The nature of the entity which  
handles the GET, and the presence or absence of 'representations' of  
it, are irrelevant.

> It beats me why anyone would want to do that

The reason is that there are, believe it or not, entities in the  
universe other than web servers; and people want to refer to them  
using URIs.

> ; but if we can make them happy with a minimal tweak to the language  
> of an existing status code, then why not. HTTP is for everyone.
>
>> If the URI in the GET request is not intended to denote the  
>> resource to which the GET is directed, then that resource must  
>> issue a 303 redirection, and must not return a representation using  
>> a 200 status code.
>
> between URIs and resources in HTTP is "identifies".

Which, if i means anything at all when used between a symbol and a non- 
computational entity, means 'denote' (or, if you prefer, 'refers to'  
or 'is a name for'; they are all equivalent usages.) And again, I  
challenge you (or anyone else) to tall me what "identifies" can  
possibly mean, in thee circumstances, other than this.

> If you care about other relations, you have to figure out how to  
> translate them into the "URI-identifies-resource-which-can-have- 
> representations" model of HTTP.

That model is either (1) already about denotation, or (2) utterly  
broken, or (3) meaningless as stated.

>> representation. Even if the representation exists and the server  
>> has access to it, it cannot return it with a 200 code when the URI  
>> is intended to denote some other thing, in particular a non- 
>> information resource of some kind.
>
> then that's great, and let me shake your hand brother, but this has  
> no effect on HTTP.

But thats the easy case. The hard case, for you, is when I use that  
very handy English word "representation" is one of its normal senses,  
not when I refuse to use it at all. There are many,  many kinds of  
representations of things, and only a miniscule proportion of them  
have anything even remotely to do with computers or network transfer  
protocols.

>> must. This is why I think the wording should make absilutely  
>> minimal assumptions about what exactly the 303 means.
>
> resource" obviously MUST entail "does not have representations in  
> the HTTP sense". In fact, that IS the definition of "non-information  
> resource", in my book.
>

Of course, but that is completely irrelevant to my point. The server,  
in my example, is not the non-information resource that the URI refers  
to; that is precisely why httprange14 requires it, the server, to emit  
a 303 code rather than a 200 code. It is merely the servant whose job  
it is to emit the appropriate code to make everything work properly.  
But it is AN information resource, and it may well have a  
representation (in the http sense) of itself. Its just a different  
resource than the one the URI denotes/refers to.

> what exactly the nature of the things identified by URIs is.

Oh, but it does. Because HTTP talks about information transfer between  
entities which can transfer information, but it talks of  
'identification' of ANY THINGS WHATSOEVER, whether they can or even  
possibly could transfer information. For example, a numeral identifies  
a number, and also is a representation of it. So HTTP should apply to  
this case as well, according to what you say here. I should be able to  
send a GET request to the number seventeen and expect to get sent back  
a 200-coded response with a suitable numeral in its body, say "17". I  
know that is ridiculous: but it FOLLOWS FROM WHAT YOU ARE SAYING;  
ergo, what you are saying is ridiculous.  So you ought to modify what  
you are saying, so that it makes more sense.

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

No, it is a poisonous combination of semantic (or maybe philosophical  
or semiotic) ignorance, and hubris. You want http to be universal, but  
you are claiming a kind of universality which goes way beyond anything  
to do with network architecture, and so you can't escape the  
consequences by appealing to network design principles.  Maybe you  
don't intend to be doing this, but it is being done by what you (and I  
should cast this in a kind of anonymous plural, as the excellent  
southern phrase y'all, as I don't intend this rant to be directed at  
you in particular) are actually saying.

Best wishes

Pat

---

From: Xiaoshu Wang <[email-masked]>
Date: Sun, 12 Jul 2009 20:58:33 -0400

Pat Hayes wrote:
>> 1. There are URIs. URIs are thought to identify things called resources.
>
> OK, stop there and tell me what you mean here by "identifies". Because...
>
>> be answered by 200. If not, then 303, 404 or 410 would be fine choices.
>
> people (or indeed of any kind), simply because computational 
> byte-transfer talk is COMPLETELY IRRELEVANT to semantic relationships 
> (such as "identification") between symbols (of any kind) and 
> non-computational entities. The fact, if it is a fact, that this word 
> is not in your technical vocabulary is entirely irrelevant. By 
> claiming that your symbols "identify" non-computational entities such 
> as people or books (or the weather in Oaxacala, to take another random 
>> The HTTP protocol kicks in AFTER the publisher has made up their mind 
>> about what resources they have and wether they have representations 
>> or not.
>
>> pretty much orthogonal to any discussion of the HTTP protocol. As 
>> long as the subcommunities subscribe to the basic 
>> "URI-identifies-resource-which-can-have-representations" model, HTTP 
>> can accomodate them.
>>
> Which, if i means anything at all when used between a symbol and a 
> non-computational entity, means 'denote' (or, if you prefer, 'refers 
> to' or 'is a name for'; they are all equivalent usages.) And again, I 
>> translate them into the 
>>> by some externally agreed convention) is being used to denote a 
>>> non-information resource; what should it do? HTTPrange14 requires it 
>>> to not deliver a 200-coded reply, but your criterion requires that 
>>> it must. This is why I think the wording should make absilutely 
>> is critically important if we want to use HTTP URIs as identifiers 
>> for things that exist outside of the Web. But the HTTP protocol 
>> itself is and should be agnostic with regard to your position in 
>> these debates. That's layering.
>

I like this -- "it is a poisonous combination of *philosophical* 
ignorance with hubris".  I have had this sentiment for quite a while.

But between Alan and Pat, I actually think that you two agree, as oppose 
to disagree.  The problem is, however, the dual sense of an HTTP-URI, 
which is used both as a name, (which is all about denotation) and a 
locator, (which is all about transportation).  I believe if you two 
reword your arguments by clarifying the exact use, you will find that 
there is not much that you two disagree philosophically.

TAG, take my suggestion -- make *one* pure URN for the Web. It doesn't 
have to be in the shape of the schemeless-one as I have proposed.  As 
long it is a pure name, in the sense that there is no predefined binding 
of a transportation protocol, it will do the job.

Let's not use the cost-excuse.  I just don't buy it.  First, I don't 
believe the cost is high because how can adding a new URI scheme any 
existing schemes.  Second, even if it is high, it will be worth it. So, 
we will not spend those endless discussion all caused by an ambiguous 
wording.

Xiaoshu

---

From: Richard Cyganiak <[email-masked]>
Date: Mon, 13 Jul 2009 17:24:43 +0200

Pat,

1. You are on the web architecture mailing list. It should have  
occurred to you that I use the word "representation" in the web  
architecture sense: a stream of bytes with a content type (and maybe  
additional metadata). Your examples about your painted self-portrait  
and the number 17 miss the point. It's like insisting on discussing  
human anatomy in a thread about object-oriented programming languages  
because not all "members" are instance-scoped variables.

2. I said: "As far as HTTP is concerned, it does not matter much what  
the resource actually is -- a document, a file on a server, a person,  
whatever." You heard: "A URI can identify a person." What I meant was:  
"For HTTP, it REALLY DOES NOT MATTER what the resource actually is."  
It is simply the thing that is thought to sit behind the HTTP  
interface and that the HTTP conversation is about. You can implement  
the HTTP protocol, both on the server and client side, while being  
totally agnostic about what can and cannot be identified by HTTP. All  
you need to know is that URIs identify something that can have  
publisher-chosen representations. Wether that something actually is a  
document, file on a server, or a person, is IRRELEVANT to discussions  
of the HTTP protocol.

Because you misunderstood my point on these two counts, you end up  
ranting against a POV that I do not hold.

I especially continue to maintain that any talk about denotation is  
out of place on the HTTP protocol level. There is no such thing as  
denotation in the universe of the Hypertext Transfer Protocol. Yes,  
people obviously use HTTP URIs to denote all sorts of things, and a  
lot can be said about how one should model resources and  
representations based on the things one wants to denote, and what one  
can or cannot infer about the denotation of a URI based on HTTP  
interactions, but none of this matters one bit for the actual  
operations of the protocol. The protocol is just about pushing  
representations around.

Best,
Richard

On 13 Jul 2009, at 01:31, Pat Hayes wrote:
>>> Well, yes, IF it were driven solely by what one might call  
>>> rational HTTP architectural principles. BUt surely the whole issue  
>>> about httprange14 is that it introduces new principles which on  
>>> their face have nothing to do with http architecture as such, but  
>>> to do with denotation and naming.
>>
> ... in the usual sense of 'identifies' that one might expect to be  
> use in the context of a network transfer protocol, which is similar  
> to the use one might expect when talking about programming language  
> identifiers and what they identify, it most certainly does matter.  
> In particular, it simply does not make sense to speak, using that  
> normal terminology, of 'identifying' a person (or a galaxy or a  
> sodium atom, etc.); in fact, it does not make sense to talk of  
> identifying anything much beyond some kind of data structure or data  
> object. So if HTML claims to be able to make sense of talking of  
> 'identifying' people (for example), it must be in a wholly different  
> space than all previous computationally based notational systems,  
> and be using the word "identify" in a wholly different sense. And,  
> to repeat, can you tell me what that sense is?
>
>>
> will decide that a certain resource, to wit, me, has a thing called  
> a representation of me. This representation of me is in fact a  
> portrait, painted using acrylic paints on a piece of masonite  
> approximately 30 cm square almost exactly a month ago: but let us  
> not go into details, as you tell me that such details are none of  
> HTTP's business. Still, the representation exists, and the resource  
> has it. OK, let us proceed.
>
>>
> So, HTTP must reply to a GET on my URI with a 200. OK, what should  
> it put as the payload of this 200 response, attached to the code  
> response? There is no representation which can be transmitted in  
> bits. You did not mention this aspect in your above summary: was  
> that an omission?
>
>>
>> I repeat: For the operation of the HTTP protocol, IT DOES NOT  
>> MATTER what exactly a resource is and what the exact relationship  
>> between resources and representations is.
>
>> All these matters of denotation, information resources and so on  
>> are introduced by higher layers of the architecture.
>
> Wrong. Denotation is not introduced by a higher level, and even if  
> it were, it would not be higher in an architectural sense. You, in  
> this very message, in fact brought denotation into the picture, by  
> telling me that a URI can "identify" a person. URIs are symbols  
> strings, and the ONLY POSSIBLE SEMANTIC RELATIONSHIP between ANY  
> symbol and a physical object, is denotation. Sorry to shout there a  
> little, but the point needs to be made strongly. That is what  
> "denotation" means: it is all that is left of "identifying" when you  
> take away the actual network machinery, the computational byte- 
> transferring. And you have to take this away when you start claiming  
> to talk of relationships between names (of any kind) and non- 
> computational entities such as people (or indeed of any kind),  
> simply because computational byte-transfer talk is COMPLETELY  
> IRRELEVANT to semantic relationships (such as "identification")  
> between symbols (of any kind) and non-computational entities. The  
> fact, if it is a fact, that this word is not in your technical  
> vocabulary is entirely irrelevant. By claiming that your symbols  
> "identify" non-computational entities such as people or books (or  
> the weather in Oaxacala, to take another random example) , you are  
> no longer playing in the network-architectural sandbox, precisely  
> because these kind of things simply are not connected to networks in  
> the same functional sense that things like web servers are. Either  
> HTTP is a computational notion or it isn't. If it is, then it is  
> indeed quite simple. And I would be delighted if the HTTP literature  
> simply restricted itself to the computational world. But it does  
> not, and never has: HTTP has ALWAYS had these claims to semantic  
> grandeur: it has ALWAYS claimed to be not just about web sites and  
> web servers and files and documents, but about the whole grand span  
> of symbol usage to refer to absolutely anything in any possible  
> universe. And if indeed that is what HTTP is claiming to be able to  
> talk about, then it is about denotation, right out of the box.
>
>>
>> model resources and representations. That's not a good thing, and  
>> it would be good for interoperability if everyone agreed. However,  
>> this is pretty much orthogonal to any discussion of the HTTP  
>> protocol. As long as the subcommunities subscribe to the basic "URI- 
>> identifies-resource-which-can-have-representations" model, HTTP can  
>> accomodate them.
>>
>> subcommunity had the funny idea that some resources SHOULD have  
>> URIs but NO representations and it should STILL be possible to get  
> resources, it is about URIs and what they denote. The dilemma is  
> that people want 'normal' URIs to denote what it that HTTP thinks of  
> them as identifying, the "information resource" (not that that  
> matters). Which would be fine, except that there are some URIs which  
> people want to denote something else. And still, actually for  
> different ('linked data', Timblish) reasons, people want a GET on  
> those URIs to finish up, one way or another, with useful information  
> being returned. This is a problem. It would be ugly to have two  
> 'kinds' of URI, and impossible to change the millions of 'normal'  
> URIs in any way at all. The decision allows the few non-normal URIs  
> to take part in a slightly irrational HTTP dance which allows  
> everyone to say: look, since it didn't return a 200 code, its not  
> 'normal', and HTTP says it doesn't identify anything at all; so the  
> 'normal' assumptions about what it denotes are cancelled. And that  
> cancellation is the entire content of the decision: it has no other  
> purpose. The nature of the entity which handles the GET, and the  
> presence or absence of 'representations' of it, are irrelevant.
>
>> ; but if we can make them happy with a minimal tweak to the  
>>> issue a 303 redirection, and must not return a representation  
>>> using a 200 status code.
>>
> to' or 'is a name for'; they are all equivalent usages.) And again,  
> I challenge you (or anyone else) to tall me what "identifies" can  
>> concerned. If you subscribe to a religion that says, "Thou shall  
>> not make a representation of me, for I am not an information  
>> resource", then that's great, and let me shake your hand brother,  
>> but this has no effect on HTTP.
>
> very handy English word "representation" is one of its normal  
> senses, not when I refuse to use it at all. There are many,  many  
> kinds of representations of things, and only a miniscule proportion  
> of them have anything even remotely to do with computers or network  
> transfer protocols.
>
>>
>>> can be placed in an impossible position. If it has a  
>>> representation of itself which  could be put into a 200-code  
>>> response, and it receives a GET request with a URI which it knows  
>>> (somehow, perhaps by some externally agreed convention) is being  
>>> used to denote a non-information resource; what should it do?  
>>> HTTPrange14 requires it to not deliver a 200-coded reply, but your  
>>> criterion requires that it must. This is why I think the wording  
>>> should make absilutely minimal assumptions about what exactly the  
>>> 303 means.
>>
>> the HTTP sense". In fact, that IS the definition of "non- 
>> information resource", in my book.
>>
>
> Of course, but that is completely irrelevant to my point. The  
> server, in my example, is not the non-information resource that the  
> URI refers to; that is precisely why httprange14 requires it, the  
> server, to emit a 303 code rather than a 200 code. It is merely the  
> servant whose job it is to emit the appropriate code to make  
> everything work properly. But it is AN information resource, and it  
> may well have a representation (in the http sense) of itself. Its  
> just a different resource than the one the URI denotes/refers to.
>
>> Wrapping up:
>>
> Oh, but it does. Because HTTP talks about information transfer  
> between entities which can transfer information, but it talks of  
> possibly could transfer information. For example, a numeral  
> identifies a number, and also is a representation of it. So HTTP  
> should apply to this case as well, according to what you say here. I  
> should be able to send a GET request to the number seventeen and  
> expect to get sent back a 200-coded response with a suitable numeral  
> in its body, say "17". I know that is ridiculous: but it FOLLOWS  
> FROM WHAT YOU ARE SAYING; ergo, what you are saying is ridiculous.   
> So you ought to modify what you are saying, so that it makes more  
> sense.
>
>>
> No, it is a poisonous combination of semantic (or maybe  
> philosophical or semiotic) ignorance, and hubris. You want http to  
> be universal, but you are claiming a kind of universality which goes  
> way beyond anything to do with network architecture, and so you  
> can't escape the consequences by appealing to network design  
> principles.  Maybe you don't intend to be doing this, but it is  
> being done by what you (and I should cast this in a kind of  
> anonymous plural, as the excellent southern phrase y'all, as I don't  
> intend this rant to be directed at you in particular) are actually  
> saying.
>
> Best wishes
>
> Pat
>
>>
>> Best,
>> Richard
>>
>>
>>
>>>
>>> Pat
>>>
>>>> ....Roy
>>>>
>>>>
>>>>
>>>

---

From: Richard Cyganiak <[email-masked]>
Date: Mon, 13 Jul 2009 17:32:02 +0200

> *un*transferable representation?

I think the word "transferable" just adds a bit of wiggle room that  
allows the server not to send the representation even if it has one.  
An example might be a client that is not authorized to view the  
resource, and the server 303-redirects it to a preview of the  
resource. Another example might be a representation that is too large  
for a mobile client on a slow connection. There might be many reasons  
why a server, even though it technically speaking has a  
representation, would prefer to redirect a client to some other  
resource instead.

(I didn't write Roy's text and am obviously just guessing.)

Richard

>> server

---

From: Pat Hayes <[email-masked]>
Date: Mon, 13 Jul 2009 12:33:25 -0500

On Jul 13, 2009, at 10:24 AM, Richard Cyganiak wrote:

> human anatomy in a thread about object-oriented programming  
> languages because not all "members" are instance-scoped variables.

That would be a fine response if you had not, in the same email,  
spoken of URI "identifying" people, and told me in block capitals that  
the nature of the resources and what counts as a representation, is  
entirely irrelevant to HTTP. To repeat: you can't have it both ways.  
If you are talking solely about architecture, then don't stray into  
non-architectural semantic issues. People (and books and Mexican  
weather) are not computational/architectural entities: they play no  
role whatever in network architecture.

>
> 2. I said: "As far as HTTP is concerned, it does not matter much  
> what the resource actually is -- a document, a file on a server, a  
> person, whatever." You heard: "A URI can identify a person." What I  
> meant was: "For HTTP, it REALLY DOES NOT MATTER what the resource  
> actually is." It is simply the thing that is thought to sit behind  
> the HTTP interface and that the HTTP conversation is about. You can  
> implement the HTTP protocol, both on the server and client side,  
> while being totally agnostic about what can and cannot be identified  
> by HTTP. All you need to know is that URIs identify something that  
> can have publisher-chosen representations. Wether that something  
> actually is a document, file on a server, or a person, is IRRELEVANT  
> to discussions of the HTTP protocol.

I'm sorry, I DO NOT ACCEPT THIS. I believe that YOU ARE WRONG. And  
here is why. This thing, that is thought to sit behind the HTTP  
interface, cannot be absolutely anything. It does have to have certain  
properties simply by virtue of BEING THE KIND OF THING THAT CAN SIT  
BEHIND ANY SUCH INTERFACE. That is, it has to be a computational or  
maybe network engine of some kind. It has to be capable of accepting  
and emitting byte streams, and so forth. People are not such entities,  
neither are books or galaxies or numbers or imaginary aardvarks. But  
you claim that HTTP can deal with URIs "identifying" such things.  
Which is nonsense; or at any rate, it is nonsense if "identifies" is  
understood in terms appropriate to network architecture. If, on the  
other hand, "identifies" is understood as  including the relationship  
between a symbolic name and a thing, which is often called denotation  
or reference or naming, then it certainly makes sense to say that a  
URI can "identify" a person or a book. But then, HTTP is already a  
semantic specification as well as an architectural one. It is about  
meaning and reference, not solely about network transfer. I really  
don't care which path you take at this fork in the road, but you can't  
go both ways. If HTTP is semantic, then it is about denotation right  
down to the metal. If it's not, then URI's can't "identify" people and  
books and galaxies in the same sense (presumably a sense related to  
network architecture in some way) that they "identify" web sites and  
digital documents. PLEASE get your story straight, one way or the  
other. (Again, that is a y'all.)

>
> Because you misunderstood my point

I do not think I did misunderstand it. Your POV has a background  
assumption which you seem to be (from these emails) unaware of, and  
which is false; indeed, ridiculous: to wit, that all things that can  
be referred to are things that can be thought of in terms appropriate  
to a computer network architecture. For example, the very idea of  
"layering" is a computational notion. There is no layering in the  
world outside computer science.

> on these two counts, you end up ranting against a POV that I do not  
> hold.
>
> representations based on the things one wants to denote, and what  
> one can or cannot infer about the denotation of a URI based on HTTP  
> operations of the protocol.

Seems to me that this may have been true before http-range-14, but it  
is not a stance that can possibly be maintained in the face of that  
decision. And your final sentence above is, surely you can yourself  
see, tendentious. If the HTTP 'layer' really were completely  
unconcerned with denotation, how could one *possibly* infer anything  
about what a URI denotes from *anything* about HTTP interactions?

> The protocol is just about pushing representations around.

Well, I would be delighted if this were true. But then the HTTP specs  
should not claim or even hint at the idea that URIs can "identify" non- 
computational things, or that such things can have "representations"  
in its specialized sense. (It would be very good manners, in fact, to  
clarify just what that highly specialized sense of "representation"  
is, and state explicitly that it is not intended to cover any wider  
sense of representation, for example the sense in which it it used in  
such phrases as "knowledge representation".) And you should be quite  
open and clear about the fact that this view of HTTP is not compatible  
with the http-range-14 decision.

Pat

PS. You never did tell me what you think "identifies" means, by the  
way. Apparently it means something, since you dismissed my  
interpretation of it as inappropriate. So there are some restrictions  
on the meaning of "identifies". Can you even sketch what they might be?

>>>> rational HTTP architectural principles. BUt surely the whole  
>>>> issue about httprange14 is that it introduces new principles  
>>>> which on their face have nothing to do with http architecture as  
>>>> such, but to do with denotation and naming.
>>>
>> identifying anything much beyond some kind of data structure or  
>> data object. So if HTML claims to be able to make sense of talking  
>> of 'identifying' people (for example), it must be in a wholly  
>> different space than all previous computationally based notational  
>> systems, and be using the word "identify" in a wholly different  
>> sense. And, to repeat, can you tell me what that sense is?
>>
>>>
>> Really? OK, I will take you at your word. I am a server owner, and  
>> I will decide that a certain resource, to wit, me, has a thing  
>> called a representation of me. This representation of me is in fact  
>> a portrait, painted using acrylic paints on a piece of masonite  
>>> 3. If a resource has a representation, then a GET to its URI  
>>> should be answered by 200. If not, then 303, 404 or 410 would be  
>>> fine choices.
>>
>> "denotation" means: it is all that is left of "identifying" when  
>> you take away the actual network machinery, the computational byte- 
>> transferring. And you have to take this away when you start  
>> claiming to talk of relationships between names (of any kind) and  
>> non-computational entities such as people (or indeed of any kind),  
>> because these kind of things simply are not connected to networks  
>> in the same functional sense that things like web servers are.  
>> Either HTTP is a computational notion or it isn't. If it is, then  
>> it is indeed quite simple. And I would be delighted if the HTTP  
>> literature simply restricted itself to the computational world. But  
>> it does not, and never has: HTTP has ALWAYS had these claims to  
>> possible universe. And if indeed that is what HTTP is claiming to  
>> be able to talk about, then it is about denotation, right out of  
>> the box.
>>
>>>
>>> Yes, it would be useful to provide guidance to publishers about  
>>> how best to model their information space as resources and  
>>> protocol. As long as the subcommunities subscribe to the basic  
>>> "URI-identifies-resource-which-can-have-representations" model,  
>>> HTTP can accomodate them.
>>>
>> that people want 'normal' URIs to denote what it that HTTP thinks  
>> of them as identifying, the "information resource" (not that that  
>> matters). Which would be fine, except that there are some URIs  
>> which people want to denote something else. And still, actually for  
>> those URIs to finish up, one way or another, with useful  
>> information being returned. This is a problem. It would be ugly to  
>> have two 'kinds' of URI, and impossible to change the millions of  
>> 'normal' URIs in any way at all. The decision allows the few non- 
>> normal URIs to take part in a slightly irrational HTTP dance which  
>> allows everyone to say: look, since it didn't return a 200 code,  
>> its not 'normal', and HTTP says it doesn't identify anything at  
>> all; so the 'normal' assumptions about what it denotes are  
>> cancelled. And that cancellation is the entire content of the  
>> decision: it has no other purpose. The nature of the entity which  
>> handles the GET, and the presence or absence of 'representations'  
>> of it, are irrelevant.
>>
>> non-computational entity, means 'denote' (or, if you prefer,  
>> 'refers to' or 'is a name for'; they are all equivalent usages.)  
>> And again, I challenge you (or anyone else) to tall me what  
>> "identifies" can possibly mean, in thee circumstances, other than  
>> this.
>>
>>>> has access to it, it cannot return it with a 200 code when the  
>>>> URI is intended to denote some other thing, in particular a non- 
>>>> If we follow your rule, above, and also httprange14, then a  
>>>> server can be placed in an impossible position. If it has a  
>>>> HTTPrange14 requires it to not deliver a 200-coded reply, but  
>>>> your criterion requires that it must. This is why I think the  
>>>> wording should make absilutely minimal assumptions about what  
>>>> exactly the 303 means.
>>>
>> should apply to this case as well, according to what you say here.  
>> I should be able to send a GET request to the number seventeen and  
>> expect to get sent back a 200-coded response with a suitable  
>> numeral in its body, say "17". I know that is ridiculous: but it  
>> FOLLOWS FROM WHAT YOU ARE SAYING; ergo, what you are saying is  
>> ridiculous.  So you ought to modify what you are saying, so that it  
>> makes more sense.
>>
>>>
>> be universal, but you are claiming a kind of universality which  
>> goes way beyond anything to do with network architecture, and so  
>> you can't escape the consequences by appealing to network design  
>> anonymous plural, as the excellent southern phrase y'all, as I  
>> don't intend this rant to be directed at you in particular) are  
>> actually saying.
>>
>> Best wishes
>>
>> Pat
>>
>>>
>>> Best,
>>> Richard
>>>
>>>
>>>
>>>>
>>>> Pat
>>>>
>>>>> ....Roy
>>>>>
>>>>>
>>>>>
>>>>

---

From: Pat Hayes <[email-masked]>
Date: Mon, 13 Jul 2009 12:36:58 -0500

On Jul 13, 2009, at 10:32 AM, Richard Cyganiak wrote:

> resource. Another example might be a representation that is too  
> large for a mobile client on a slow connection. There might be many  
> reasons why a server, even though it technically speaking has a  

Ah, that would indeed be just the wiggle room I would need to make  
sense of this, since it allows for the possibility of there being a  
200-appropriate representation even when a 303 is emitted. But the  
text really should make this intention clearer than it does, if indeed  
this is what it means to be saying. I took Roy's reply to my suggested  
rewording to be a firm rejection of this interpretation, but maybe I  
missed the wiggle.

Pat

---

From: Richard Cyganiak <[email-masked]>
Date: Tue, 14 Jul 2009 02:29:57 +0200

Pat,

You still didn't get my point. You ask:

"In the context of the HTTP protocol, what can be a resource? What can  
be the thing sitting behind the HTTP interface?"

I take YOUR preferred answer to be: "It can only be a computational  
resource."

It appears that you THINK that my answer is: "It can be anything."

But that is NOT my answer. My answer is: "I don't know, I don't care,  
and it's the wrong question to ask. It's just a resource, something  
that has representations. If you wish to discuss such matters, then  
this automatically moves you outside of the scope of the HTTP protocol."

Can HTTP URIs identify people? As far as the operation of HTTP  
protocol is concerned, I'm 100% agnostic. It is simply unnecessary to  
answer that question in order to reason about, implement, or specify  
the HTTP protocol.

More below.

On 13 Jul 2009, at 19:33, Pat Hayes wrote:
>> architecture sense: a stream of bytes with a content type (and  
>> maybe additional metadata). Your examples about your painted self- 
>> portrait and the number 17 miss the point. It's like insisting on  
>> discussing human anatomy in a thread about object-oriented  
>> programming languages because not all "members" are instance-scoped  
>> variables.
>
> spoken of URI "identifying" people,

I did not say that.

> and told me in block capitals that the nature of the resources and  
> what counts as a representation, is entirely irrelevant to HTTP. To  
> repeat: you can't have it both ways. If you are talking solely about  
> architecture, then don't stray into non-architectural semantic issues.

I'm talking solely about a transfer protocol.

> People (and books and Mexican weather) are not computational/ 
> architectural entities: they play no role whatever in network  
> architecture.

Right, and I did not claim otherwise.

>> actually is."

Here, read this again. Look, I have no opinion on the question wether  
a HTTP URI can identify a person!

>> interface and that the HTTP conversation is about. You can  
>> while being totally agnostic about what can and cannot be  
>> identified by HTTP. All you need to know is that URIs identify  
>> something that can have publisher-chosen representations. Wether  
>> that something actually is a document, file on a server, or a  
>> person, is IRRELEVANT to discussions of the HTTP protocol.
>
> interface, cannot be absolutely anything. It does have to have  
> certain properties simply by virtue of BEING THE KIND OF THING THAT  
> CAN SIT BEHIND ANY SUCH INTERFACE. That is, it has to be a  
> computational or maybe network engine of some kind.

That's not a necessary assumption. From prodding the interface, I  
cannot tell what's sitting behind it. I can just get representations  
of the thing, I cannot learn its nature. Hence why should I make  
assumptions about its nature?

> It has to be capable of accepting and emitting byte streams, and so  
> forth.

No. The byte streams are accepted/emitted by the web server, which is  
a separate component. The URI http://example.com:8080/foo.html tells  
me that there might be a server at example.com and I can maybe connect  
to port 8080 and make an HTTP request to hopefully get a  
representation of the thing identified by the URI, whatever it is. The  
web server is not the resource. The resource does not have to be a web  
server.

> People are not such entities, neither are books or galaxies or  
> numbers or imaginary aardvarks. But you claim that HTTP can deal  
> with URIs "identifying" such things.

No, I did not say that.

Although I'm sure that we can dream up contraptions that causally  
connect any of the above to a web server.

You want to legislate what kind of contraption is allowed behind the  
HTTP interface. I say: For specifying the HTTP protocol, let's not  
care, as long as a URI goes in and a representation comes out. We can  
gloss over the question what the resource actually *is*.

> other hand, "identifies" is understood as  including the  
> relationship between a symbolic name and a thing, which is often  
> called denotation or reference or naming, then it certainly makes  
> sense to say that a URI can "identify" a person or a book. But then,  
> HTTP is already a semantic specification as well as an architectural  
> one. It is about meaning and reference, not solely about network  
> transfer.

HTTP is NOT a semantic system. HTTP is NOT about denotation. In the  
context of HTTP, "identifies" simply means "names something that has  
representations." In the context of HTTP, "identifies" does not  
include denotation.

> I really don't care which path you take at this fork in the road,  
> but you can't go both ways. If HTTP is semantic, then it is about  
> denotation right down to the metal.

HTTP is not semantic.

> If it's not, then URI's can't "identify" people and books and  
> galaxies in the same sense (presumably a sense related to network  
> architecture in some way) that they "identify" web sites and digital  
> documents.

In the context of HTTP, URIs identify things that have representations.

> PLEASE get your story straight, one way or the other. (Again, that  
> is a y'all.)
>
>>
> I do not think I did misunderstand it.

Your writing suggests otherwise.

> Your POV has a background assumption which you seem to be (from  
> these emails) unaware of, and which is false; indeed, ridiculous: to  
> wit, that all things that can be referred to are things that can be  
> thought of in terms appropriate to a computer network architecture.

I do not hold that assumption. I hold the following assumptions:

1. The purpose of the Hypertext Transfer Protocol is to exchange  
representations over networks.

2. The Hypertext Transfer Protocol spec should treat HTTP URIs simply  
as identifiers inside a transfer protocol.

3. If people want to do weird shit with HTTP URIs, beyond exchanging  
representations over networks, that's great and more power to them.

4. The HTTP spec does not need to worry about regulating such weird  
shit.

5. Someone should clearly worry about such weird shit, but not in the  
HTTP spec.

> For example, the very idea of "layering" is a computational notion.  
> There is no layering in the world outside computer science.

Not getting your point. I'm talking about transfer protocols and  
knowledge representation. What does the world outside of computer  
science have to do with that?

> Seems to me that this may have been true before http-range-14, but  
> it is not a stance that can possibly be maintained in the face of  
> that decision.

I think you're insisting on an unhelpful reading of httpRange-14.  
Again, try wrapping your head around that layering idea:

There is one layer that tells you how you can push representations  
around the network. That's HTTP.

There is another layer that tells you how to best model the world as  
resources and representations. That's where RDF, denotation, Linked  
Data, information resources etc live. AWWW and other best practices  
documents say a lot about this layer.

httpRange-14 is about the second layer, not about the first. So I  
don't see how httpRange-14 has any effect on anything that concerns  
the first layer.

> And your final sentence above is, surely you can yourself see,  
> tendentious. If the HTTP 'layer' really were completely unconcerned  
> with denotation, how could one *possibly* infer anything about what  
> a URI denotes from *anything* about HTTP interactions?

The HTTP protocol allows you to infer things about the  
*representations* that a resource has. That's all, you cannot learn  
anything else about the resource just through HTTP. However, by  
inspecting those representations, you might learn something about the  
intended denotation of the URI. But that, again, is outside the scope  
of the HTTP protocol.

> Well, I would be delighted if this were true. But then the HTTP  
> specs should not claim or even hint at the idea that URIs can  
> "identify" non-computational things, or that such things can have  
> "representations" in its specialized sense.

I'm delighted to inform you that I'm pretty sure that the HTTP spec  
doesn't hint at the idea of URIs identifying non-computational things,  
anywhere.

> (It would be very good manners, in fact, to clarify just what that  
> highly specialized sense of "representation" is, and state  
> explicitly that it is not intended to cover any wider sense of  
> representation, for example the sense in which it it used in such  
> phrases as "knowledge representation".)

I think that AWWW, RFC 2616, and Roy's Chapter 5 are all very clear  
about this. I don't understand how you can read any of those and walk  
away thinking that an acrylic painting might be a representation.

> And you should be quite open and clear about the fact that this view  
> of HTTP is not compatible with the http-range-14 decision.

I don't see that incompatibility.

> way.
> Apparently it means something, since you dismissed my interpretation  
> of it as inappropriate. So there are some restrictions on the  
> meaning of "identifies". Can you even sketch what they might be?

As far as HTTP is concerned, "identifies" is the relationship between  
a URI and the resource whose representation you receive when you  
perform a GET on the URI. That's all.

(I'm just talking about HTTP here; RDF people often use "identifies"  
synonymous with "denotes", but such talk goes beyond and outside the  
scope of the HTTP protocol.)

Let's please try to somehow wrap up this discussion. Can you somehow  
live with the POV that one can specify and implement HTTP while  
avoiding the question what resources actually are? And that questions  
such as "What does a given URI denote? What is a valid representation  
of a given resource? Are there things that ought not to be denoted by  
URIs?" can be answered elsewhere than the HTTP spec?

Best,
Richard

>>>> Not as far as HTTP is concerned. HTTP is just a transfer  
>>>> protocol. The HTTP world is really simple:
>>>>
>>> use in the context of a network transfer protocol, which is  
>>> similar to the use one might expect when talking about programming  
>>> language identifiers and what they identify, it most certainly  
>>> does matter. In particular, it simply does not make sense to  
>>> speak, using that normal terminology, of 'identifying' a person  
>>> (or a galaxy or a sodium atom, etc.); in fact, it does not make  
>>> sense to talk of identifying anything much beyond some kind of  
>>> data structure or data object. So if HTML claims to be able to  
>>> make sense of talking of 'identifying' people (for example), it  
>>> must be in a wholly different space than all previous  
>>> computationally based notational systems, and be using the word  
>>> "identify" in a wholly different sense. And, to repeat, can you  
>>>> 2. Resources (whatever they are) are thought to have things  
>>>> called representations. As far as HTTP is concerned, it is  
>>>> totally up to the server owner to decide what's a representation  
>>>> of what. After the server owner has made their decision, a  
>>>> resource either has a representation or not.
>>>
>>> called a representation of me. This representation of me is in  
>>> fact a portrait, painted using acrylic paints on a piece of  
>>> masonite approximately 30 cm square almost exactly a month ago:  
>>> but let us not go into details, as you tell me that such details  
>>> are none of HTTP's business. Still, the representation exists, and  
>>> the resource has it. OK, let us proceed.
>>>
>>>>
>>> symbol and a physical object, is denotation. Sorry to shout there  
>>> a little, but the point needs to be made strongly. That is what  
>>> literature simply restricted itself to the computational world.  
>>> But it does not, and never has: HTTP has ALWAYS had these claims  
>>> to semantic grandeur: it has ALWAYS claimed to be not just about  
>>> web sites and web servers and files and documents, but about the  
>>> whole grand span of symbol usage to refer to absolutely anything  
>>> in any possible universe. And if indeed that is what HTTP is  
>>> claiming to be able to talk about, then it is about denotation,  
>>> right out of the box.
>>>
>>>>
>>>> it would be good for interoperability if everyone agreed.  
>>>> However, this is pretty much orthogonal to any discussion of the  
>>>> HTTP protocol. As long as the subcommunities subscribe to the  
>>>> basic "URI-identifies-resource-which-can-have-representations"  
>>>> model, HTTP can accomodate them.
>>>>
>>>> URIs but NO representations and it should STILL be possible to  
>>>> get information about them via HTTP.
>>>
>>> which people want to denote something else. And still, actually  
>>> for different ('linked data', Timblish) reasons, people want a GET  
>>> on those URIs to finish up, one way or another, with useful  
>>> But thats the easy case. The hard case, for you, is when I use  
>>> that very handy English word "representation" is one of its normal  
>>> kinds of representations of things, and only a miniscule  
>>> proportion of them have anything even remotely to do with  
>>> computers or network transfer protocols.
>>>
>>>>
>>>>> response, and it receives a GET request with a URI which it  
>>>>> knows (somehow, perhaps by some externally agreed convention) is  
>>>>> being used to denote a non-information resource; what should it  
>>>>> do? HTTPrange14 requires it to not deliver a 200-coded reply,  
>>>>> but your criterion requires that it must. This is why I think  
>>>>> the wording should make absilutely minimal assumptions about  
>>>>> what exactly the 303 means.
>>>>
>>> server, in my example, is not the non-information resource that  
>>> the URI refers to; that is precisely why httprange14 requires it,  
>>> the server, to emit a 303 code rather than a 200 code. It is  
>>> merely the servant whose job it is to emit the appropriate code to  
>>> make everything work properly. But it is AN information resource,  
>>> and it may well have a representation (in the http sense) of  
>>> itself. Its just a different resource than the one the URI denotes/ 
>>> refers to.
>>>
>>>> Wrapping up:
>>>>
>>>> For the function of the HTTP transfer protocol, it does not  
>>>> matter what exactly the nature of the things identified by URIs is.
>>>
>>> 'identification' of ANY THINGS WHATSOEVER, whether they can or  
>>> even possibly could transfer information. For example, a numeral  
>>> ridiculous.  So you ought to modify what you are saying, so that  
>>> it makes more sense.
>>>
>>>>
>>>> For the function of the HTTP transfer protocol, it does not  
>>>> matter wether the things you serve as representations on your  
>>>> server make particularly good representations of the resources.
>>>>
>>>> nature of the "identifies" and "has representation"  
>>>> relationships, and this is critically important if we want to use  
>>>> HTTP URIs as identifiers for things that exist outside of the  
>>>> Web. But the HTTP protocol itself is and should be agnostic with  
>>>> regard to your position in these debates. That's layering.
>>>

---

From: Alan Ruttenberg <[email-masked]>
Date: Tue, 14 Jul 2009 02:01:57 -0400

On Sat, Jul 11, 2009 at 6:27 AM, Richard Cyganiak<[email-masked]> wrote:
> Not as far as HTTP is concerned. HTTP is just a transfer protocol. The HTTP
> world is really simple:
>
> 1. There are URIs. URIs are thought to identify things called resources. As
> far as HTTP is concerned, it does not matter much what the resource actually
> is -- a document, a file on a server, a person, whatever.
>
> representations. As far as HTTP is concerned, it is totally up to the server
> owner to decide what's a representation of what. After the server owner has
> made their decision, a resource either has a representation or not.
>
> I repeat: For the operation of the HTTP protocol, IT DOES NOT MATTER what
> exactly a resource is and what the exact relationship between resources and
> representations is. All these matters of denotation, information resources
> and so on are introduced by higher layers of the architecture.

This is a nice simple story, but as far as I can tell it just isn't
correct. There are many places in HTTP which address issues of
semantics or otherwise go beyond transport.

e.g Content negotiation:

Most HTTP responses include an entity which contains information for
   interpretation by a human user. Naturally, it is desirable to supply
   the user with the "best available" entity corresponding to the
   request. Unfortunately for servers and caches, not all users have the
   same preferences for what is "best," and not all user agents are
   equally capable of rendering all entity types. For that reason, HTTP
   has provisions for several mechanisms for "content negotiation" --
   the process of selecting the best representation for a given response
   when there are multiple representations available.

      Note: This is not called "format negotiation" because the
      alternate representations may be of the same media type, but use
      different capabilities of that type, be in different languages,
      etc.

or:

 10.2.4   203 Non-Authoritative Information ........................59

or:

 10.4.3    402 Payment Required ....................................66

or:

14.11   Content-Encoding .........................................118
14.12   Content-Language .........................................118

or any of the caching stuff.

---

TCP is a transport protocol. HTTP is concerned with more than just
transport of opaque bit strings. In my view, your presentation of
HTTP's view of resources and representations as a kind of mathematical
abstraction doesn't do justice to the intellectual work that preceded
and led to the development of HTTP (H = Hypertext, for example).

It is certainly true that there are additional layerings that are
added by, e.g. AWWW and RDF, but to suggest that HTTP did not  bring
to the table anything more than shipping certain kinds of packets
called representations which are in grouped in buckets called
resources doesn't seem accurate.

It may very well be the case that whatever HTTP brings to the table in
these areas is underspecified, ambiguous, inconsistent,  and
unhelpful, and that a retrenchment to a view of HTTP along the lines
you suggest might be a useful advance towards a more coherent overall
infrastructure for a Semantic Web. Let's have that discussion, then,
rather than one over who's account of history is right. (my suspicion
is that the older folks will win that one ;-)

-Alan

---

From: Xiaoshu Wang <[email-masked]>
Date: Tue, 14 Jul 2009 10:01:16 -0400

Pat Hayes wrote:

<snip>
> about what a URI denotes from *anything* about HTTP interactions?
The assumption here is that httpRange-14 is the right direction.  But 
that is a big *if*. If anything, this debate only shows how *bad* that 
this whole idea of httpRange-14 and information resource thing is.
 
> should not claim or even hint at the idea that URIs can "identify" 
> non-computational things, or that such things can have 
> "representations" in its specialized sense. (It would be very good 
> manners, in fact, to clarify just what that highly specialized sense 
> of "representation" is, and state explicitly that it is not intended 
> to cover any wider sense of representation, for example the sense in 
> which it it used in such phrases as "knowledge representation".) And 
> you should be quite open and clear about the fact that this view of 
> HTTP is not compatible with the http-range-14 decision.
The HTTP protocol should be about pushing representation around.  And it 
shouldn't careless about if its URI denotes or identifies anything.  The 
latter is up to the one who implements that particular URI.   Let's not 
ignore the existence of such entities because it is those who expressed 
their denotation semantics.

Also, let's us not play linguistic tricks.  If the owner of 
"http://example.com/a.hamburger" makes it to denote a hamburger. Then 
HTTP-GET "http://example.com/a.hamburger" means "get me an 
awww:representation" of the hamburger. But it does NOT mean the "get" 
like in "get me that hamburger" as what we would say in front of a 
grill.  To think otherwise is to hallucinate.

httpRange-14 was at first designed to prevent people from episodes of 
this kind of hallucination.  But at the end, it ends up with its own one 
-- the hallucination of the information resource.

But let's get real.  Let's not temper the HTTP semantics with our own 
view on what the world or the Web ought to be.  Sure, you (or y'all) can 
have your wonderful world of "information resources".  It is none of my 
business.  But -- PLEASE, don't push it upon me. I am just not 
sophisticated enough to appreciate that delicate wonder. And most of 
all, I don't care.

Xiaoshu

---

From: Pat Hayes <[email-masked]>
Date: Tue, 14 Jul 2009 10:01:21 -0500

On Jul 14, 2009, at 9:01 AM, Xiaoshu Wang wrote:

> Pat Hayes wrote:
>
> <snip>
>>> on these two counts, you end up ranting against a POV that I do  
>>> not hold.
>>>
>>> I especially continue to maintain that any talk about denotation  
>>> is out of place on the HTTP protocol level. There is no such thing  
>>> as denotation in the universe of the Hypertext Transfer Protocol.  
>>> Yes, people obviously use HTTP URIs to denote all sorts of things,  
>>> and a lot can be said about how one should model resources and  
>>> one can or cannot infer about the denotation of a URI based on  
>>> HTTP interactions, but none of this matters one bit for the actual  
>> that decision. And your final sentence above is, surely you can  
>> yourself see, tendentious. If the HTTP 'layer' really were  
>> completely unconcerned with denotation, how could one *possibly*  
>> infer anything about what a URI denotes from *anything* about HTTP  
>> interactions?
> The assumption here is that httpRange-14 is the right direction.   
> But that is a big *if*. If anything, this debate only shows how  
> *bad* that this whole idea of httpRange-14 and information resource  
> thing is.

As I said in another post, I think http-range-14 is terrible, but all  
the alternatives are worse.

>> manners, in fact, to clarify just what that highly specialized  
>> sense of "representation" is, and state explicitly that it is not  
>> intended to cover any wider sense of representation, for example  
>> the sense in which it it used in such phrases as "knowledge  
>> representation".) And you should be quite open and clear about the  
>> fact that this view of HTTP is not compatible with the http- 
>> range-14 decision.
> The HTTP protocol should be about pushing representation around.   
> And it shouldn't careless about if its URI denotes or identifies  
> anything.  The latter is up to the one who implements that  
> particular URI.   Let's not ignore the existence of such entities  
> because it is those who expressed their denotation semantics.
>
> Also, let's us not play linguistic tricks.  If the owner of "http://example.com/a.hamburger 
> " makes it to denote a hamburger. Then HTTP-GET "http://example.com/a.hamburger 
> " means "get me an awww:representation" of the hamburger. But it  
> does NOT mean the "get" like in "get me that hamburger" as what we  
> would say in front of a grill.

Of course not. But it also does not mean, "get me an  
awww:representation" of the hamburger. Or at least, it had better not  
mean that, since hamburgers don't have awww:representations. Web pages  
about hamburgers can represent (not awww:represent) a hamburger, and  
they of course have awww:representations. But an awww:repreresentation  
of a representation of X is not an awww:representation of X.

> To think otherwise is to hallucinate.

Quite.

>
> httpRange-14 was at first designed to prevent people from episodes  
> of this kind of hallucination.  But at the end, it ends up with its  
> own one -- the hallucination of the information resource.

I don't like the terminology (and I don't think we need it, and  
especially do not need to be debating its exact meaning), but the  
general idea is clear enough: its the thing that HTTP returns the  
awww:representation of. That is certainly not a hallucination, because  
you just made HTTP contact with it.

Pat

>
> But let's get real.  Let's not temper the HTTP semantics with our  
> own view on what the world or the Web ought to be.  Sure, you (or  
> y'all) can have your wonderful world of "information resources".  It  
> is none of my business.  But -- PLEASE, don't push it upon me. I am  
> just not sophisticated enough to appreciate that delicate wonder.  
> And most of all, I don't care.
>
> Xiaoshu
>
>

---

From: Xiaoshu Wang <[email-masked]>
Date: Tue, 14 Jul 2009 11:20:42 -0400

Pat Hayes wrote:
>> that is a big *if*. If anything, this debate only shows how *bad* 
>> that this whole idea of httpRange-14 and information resource thing is.
>
Of course there is no better alternative because there is *not* a 
problem at the first place. The problem is created by pushing IR into 
the Web architecture.  But just like the web architecture should not 
deal with hamburgers, it should not deal with IR as well.

>> The HTTP protocol should be about pushing representation around.  And 
>> it shouldn't careless about if its URI denotes or identifies 
>> anything.  The latter is up to the one who implements that particular 
>> URI.   Let's not ignore the existence of such entities because it is 
>> those who expressed their denotation semantics.
>>
>> grill.
I mentioned that let us not ignore *the existence of an agent* -- the 
one who implements the URI.  I do not know if a hamburger *can or 
cannot* have an awww:representation because I am not a hamburger.  But I 
do know that *I can* give a hamburger an awww:representation.  You don't 
have to believe me, that is none of my business.  But to say that no one 
should believe me, you cross the line for being either ignorant (of 
being me) or arrogant (of being you).
>> this kind of hallucination.  But at the end, it ends up with its own 
>> one -- the hallucination of the information resource.
>
Then, it is fine with me.  You can call an HTTP server, FTP server, 
Mailto server or any kind of information server -- an "information 
resource".  That is denotation semantics of that word's use.  It is fine 
with me because we might just call it "xyz" -- for the sake of avoiding 
confusion.  But this denotation semantics should not affect how *I* 
implement *my* URI.  Most of all, it should not affect how *I* use the Web.

Xiaoshu

---

From: Pat Hayes <[email-masked]>
Date: Tue, 14 Jul 2009 11:59:33 -0500

On Jul 13, 2009, at 7:29 PM, Richard Cyganiak wrote:

> "In the context of the HTTP protocol, what can be a resource? What  
> can be the thing sitting behind the HTTP interface?"
>
> But that is NOT my answer. My answer is: "I don't know, I don't  
> care, and it's the wrong question to ask. It's just a resource,  
> something that has representations. If you wish to discuss such  
> matters, then this automatically moves you outside of the scope of  
> the HTTP protocol."

OK, then my response is, that is not an acceptable answer. It is  
either silly or tendentious. Because if this answer were true, then  
the HTTP protocol should apply to my picture-on-masonite example and a  
host of other examples to which it clearly does not and cannot apply.  
You rejected my example by an appeal to the fact that this was an  
architectural discussion. OK, then, http applies to computer  
architectural issues, but not to, say, newsprint or visual arts,  
right? So the nature of the "something" DOES matter.

<flame>
As for being the wrong question to ask, that really is bloody  
arrogance. We are discussing the wording of a technical specification.  
You want to use words in non-standard ways, ways which do not  
correspond to their normal English meanings, in the very heart of the  
spec, and when someone asks you want you intend them to mean, your  
answer is, that is the wrong question to ask?!!? Sorry, but screw you.  
That is EXACTLY the question to ask, and if can't answer it or refuse  
to answer it, you shouldn't be in the spec-writing business.
  </flame>

> protocol is concerned, I'm 100% agnostic. It is simply unnecessary  
> to answer that question in order to reason about, implement, or  
> specify the HTTP protocol.

Absolute nonsense. If URIs can identify people, then your  
implementation strategy will involve surgery. You are trying to have  
things both ways, and I'm not going to let you get away with this,  
because it is intellectually irresponsible. On the one hand, you want  
to claim the implementer's prerogative of staying in your layer and  
not having to even think about what other layers' interpretations are.  
Which I understand and respect, by the way, but only within the  
overall framework of doing computer science (broadly conceived).  
Outside that intellectual discipline, this 'layering' notion simply  
does not apply in the same way. But, on the other hand, you also want  
to claim that HTTP applies not only within a computational framework,  
but to absolutely anything at all that can call itself a "resource"  
which has "representations". And others have already firmly, publicly  
and repeatedly insisted that the term "resource" is not a technical  
word within computer science, but a word which means "absolutely  
anything at all". So, either you are not safely inside the network  
world of computer science here, or else you should repudiate these  
more grandiose claims that are being made about URIs (maybe not by  
you, but they are being made.)

>>> programming languages because not all "members" are instance- 
>>> scoped variables.
>>

"2. I said: "As far as HTTP is concerned, it does not matter much what  
the resource actually is -- a document, a file on a server, a person,  
whatever." "
That says, quite explicitly, that the HTTP protocol and the HTTP spec  
must apply to cases where the resource is a person. If it "does not  
matter" that the URI identifies a person, then the HTTP spec should  
apply to the case where the URI does in fact identify a person. If it  
"does not matter" what the nature of the representation is, then the  
spec should apply to the case where the representation is an acrylic  
painting on masonite. If, on the other hand, you want to rule out or  
not consider these cases, then it damn well DOES MATTER what the  
resource and the representation are. So please stop saying that it  
does not.

>> repeat: you can't have it both ways. If you are talking solely  
>> about architecture, then don't stray into non-architectural  
>> semantic issues.
>

But you did, by saying that "it does not matter" what the  
representation is. That is why I have been hitting you over the head  
with these ridiculous examples, because what they clearly show is that  
it DOES MATTER.

>>> person, whatever." You heard: "A URI can identify a person." What  
>>> I meant was: "For HTTP, it REALLY DOES NOT MATTER what the  
>>> resource actually is."
>
> Here, read this again. Look, I have no opinion on the question  
> wether a HTTP URI can identify a person!

That is not the issue. I am not wanting to rebuild your cognitive  
state. I am only concerned with the words used. To say that "it does  
not matter" what X is, when writing a spec about X, is to say "my spec  
applies to all X's, regardless of their nature."  That makes a VERY  
BIG CLAIM. It is not merely a statement of your unconcern, which BTW I  
understand perfectly, but with which I am not centrally concerned here.

> assumptions about its nature?

Because it has to be the KIND of thing that can be attached to an  
interface at all. People and books and numbers and galaxies don't have  
interfaces in this sense. Of all the things that can be identified by  
a URI, the proportion of them that can possibly be given such an  
interface is vanishingly small.

> No. The byte streams are accepted/emitted by the web server, which  
> is a separate component. The URI http://example.com:8080/foo.html  
> tells me that there might be a server at example.com and I can maybe  
> connect to port 8080 and make an HTTP request to hopefully get a  
> representation of the thing identified by the URI, whatever it is.  
> The web server is not the resource. The resource does not have to be  
> a web server.

True, and I realized when typing this that it wasnt strictly correct,  
but there are only so many minutes in the day. So let me just say, is  
interfaced to something capable, etc...

>> with URIs "identifying" such things.

I think you did. Certainly others say this, loud and clear, and you  
say that it does not matter what the identified things are. To me, it  
follows immediately that you are saying that HTTP applies to these  
cases also.

> connect any of the above to a web server.

Imaginary aardvarks? The number 17? How about Julius Caesar?

> HTTP interface.

No. I just want to recognize the obvious fact that there are things  
that URIs are used to "identify" which aren't ever going to be  
interfaced to any server, in any possible world. The universe is way,  
way bigger than the Internet will ever be.

> I say: For specifying the HTTP protocol, let's not care, as long as  
> a URI goes in and a representation comes out. We can gloss over the  
> question what the resource actually *is*.

You can't gloss over the fact that many resources cannot possibly be  
involved in any way in any kind of network transaction. But they can  
still be referred to.

>
>> Which is nonsense; or at any rate, it is nonsense if "identifies"  
>> is understood in terms appropriate to network architecture. If, on  
>> the other hand, "identifies" is understood as  including the  
>> sense to say that a URI can "identify" a person or a book. But  
>> then, HTTP is already a semantic specification as well as an  
>> architectural one. It is about meaning and reference, not solely  
>> about network transfer.
>

It does if URIs can "identify" people, etc.. Sorry, I don't care how  
big a font you use, you are just WRONG here. You can't have it both  
ways.

>> denotation right down to the metal.

OK, fine. BUt then it DOES  matter what things the URIs "identify",  
since without semantics,  nothing outside of a computer network can be  
"identified". So please, please stop saying that it doesn't, as this  
means you are making a huge, unsustainable claim about the scope of  
the spec.

>> architecture in some way) that they "identify" web sites and  
>> digital documents.
>
>> these emails) unaware of, and which is false; indeed, ridiculous:  
>> to wit, that all things that can be referred to are things that can  
>> be thought of in terms appropriate to a computer network  
>> architecture.
>

OK, though "representation" here has a narrow sense, but never mind.   
And...  um...  representations **of what**? Or put another way, what  
makes a byte stream into a "representation" (big word)? Or maybe, you  
don't care, right? So why not say, HTTP is to exchange **byte  
streams** over networks? That would cut out all lot of this  
philosophical chatter right at the root.

>
> 2. The Hypertext Transfer Protocol spec should treat HTTP URIs  
> simply as identifiers inside a transfer protocol.

OK, but (no rhetoric, an honest appeal for help) can you or anyone  
explain, briefly, what you understand "identifier" to mean when used  
in this transfer-protocol context? Without using any semantic terms  
like "refer to" or "means", I presume.

> representations over networks, that's great and more power to them.

Semantics isn't weird shit, but I take your point. You really do not  
want to be understood as saying anything at all about semantics. I  
don't think you have that option, however.

> 5. Someone should clearly worry about such weird shit, but not in  
> the HTTP spec.
>
> knowledge representation.

Whoa. YOu are NOT talking about knowledge representation here. Your  
sense of "representation" is much narrower than that.

> What does the world outside of computer science have to do with that?

Are you kidding? KR is almost entirely about knowledge of things  
outside computer science, and is centrally concerned with semantics.

> Again, try wrapping your head around that layering idea:

Believe me, I know about layering. But I also know that it only  
applies in very special circumstances.

> don't see how httpRange-14 has any effect on anything that concerns  

But is (httprange14) explicitly puts the two layers into close  
contact. It uses an HTTP code to send information about the SEMANTIC  
nature of the thing denoted by a URI. So these nice neat layers have  
gotten wholly jumbled here. I agree with you, having clean layering  
would be a great idea. But that was before http-range-14 came along.

> anything else about the resource just through HTTP.

HTTPrange14 explicitly denies this. You CAN learn about the resource  
from HTTP. A 200 code means that the resource is an 'information  
resource' identified by the  URI, in the same sense of 'identify' that  
HTTP uses. A 303 code cancels that inference. And this matters to HTTP  
because that is what the 303 code is FOR.

> However, by inspecting those representations, you might learn  
> something about the intended denotation of the URI. But that, again,  
> is outside the scope of the HTTP protocol.
>
> doesn't hint at the idea of URIs identifying non-computational  
> things, anywhere.

You did, in your email response. OK, I havnt checked the latest  
wording with a fine-tooth comb, my bad.

> about this.

Actually no, I have read them all very carefully, several times. None  
of them define their terms or even discuss their own technical  
vocabulary, they just use it as though its meanings were obvious. None  
of them seem to be written by people who have the faintest idea what  
words like "represent" actually mean, even in KR work. They all seem  
to make ridiculous conceptual errors, which I diagnose as due to my  
not following what they are intending to say.  It took me months of  
heavy thinking before I was even able to reconstruct a guess about  
what they were intending to say, and Im still not sure I have it  
right. I still cannot find a trace of meaning in the phrasef "having  
an identity", for example.

> I don't understand how you can read any of those and walk away  
> thinking that an acrylic painting might be a representation.

You misunderstand. My acrylic painting IS a representation. That is  
just a fact, and no pissant W3C specs are going to make it false. So  
when I read that word, "representation" in the documents you cite, i  
have to keep thinking: they don't mean "representation" in any normal  
sense... they don't mean it in the KR sense, which is semantic (took  
me a while to work that one out)... I wonder what sense they actually  
have in mind... lets make a guess... Damn, no, that can't be right  
because then what Roy says here wouldn't be correct... And so on and on.

>
>> And you should be quite open and clear about the fact that this  
>> view of HTTP is not compatible with the http-range-14 decision.
>

Well, if 303 meant "has no awww:representation" then that would be  
fine, but that's not what httprange14 says.

>> Apparently it means something, since you dismissed my  
>> interpretation of it as inappropriate. So there are some  
>> restrictions on the meaning of "identifies". Can you even sketch  
>> what they might be?
>
> As far as HTTP is concerned, "identifies" is the relationship  
> between a URI and the resource whose representation you receive when  
> you perform a GET on the URI. That's all.

Excellent. Thank you. So, httprange14 is the decision that when GET  
returns a 200 coded response (but not when it returns a 303), then the  
URI is understood to denote whatever it identifies. That's it: no need  
to talk about 'information resources' or any of that guff. And the  
existence or not of an awww:representation of the identified resource  
is irrelevant. And it keeps the layers reasonably layered, as long as  
you are able to use the d-word just once . So can we just say this?

> avoiding the question what resources actually are?

Not really. Because the world of URI references and "resources" has  
become the entire universe of things that can be referred to. It is  
not the world of things that can be interfaced to computer networks  
any more. So this is not any longer a purely network-architectural  
issue.

> And that questions such as "What does a given URI denote? What is a  
> valid representation of a given resource? Are there things that  
> ought not to be denoted by URIs?" can be answered elsewhere than the  
> HTTP spec?

Answered, yes, but not ignored by the HTTP spec. At the very least,  
the spec should explicitly wash its hands of questions like these,  
instead of saying "it doesn't matter because they are on a different  
layer".  Maybe they don't matter to HTTP, which is fine with me but  
drives a truck through httprange14;  but they are not in a different  
layer.

Best

Pat

>>>>>> which on their face have nothing to do with http architecture  
>>>>>> as such, but to do with denotation and naming.
>>>>>
>>>>> resource actually is -- a document, a file on a server, a  
>>>>> person, whatever.
>>>>
>>>> ... in the usual sense of 'identifies' that one might expect to  
>>>> be use in the context of a network transfer protocol, which is  
>>>> similar to the use one might expect when talking about  
>>>> programming language identifiers and what they identify, it most  
>>>> certainly does matter. In particular, it simply does not make  
>>>> sense to speak, using that normal terminology, of 'identifying' a  
>>>> person (or a galaxy or a sodium atom, etc.); in fact, it does not  
>>>> make sense to talk of identifying anything much beyond some kind  
>>>> of data structure or data object. So if HTML claims to be able to  
>>>> Really? OK, I will take you at your word. I am a server owner,  
>>>> and I will decide that a certain resource, to wit, me, has a  
>>>> thing called a representation of me. This representation of me is  
>>>> in fact a portrait, painted using acrylic paints on a piece of  
>>>> are none of HTTP's business. Still, the representation exists,  
>>>> and the resource has it. OK, let us proceed.
>>>>
>>>>>
>>>> So, HTTP must reply to a GET on my URI with a 200. OK, what  
>>>> should it put as the payload of this 200 response, attached to  
>>>> the code information? HOw do I get acrylic-coated masonite into  
>>>> an http response? There is no representation which can be  
>>>> transmitted in bits. You did not mention this aspect in your  
>>>> above summary: was that an omission?
>>>>
>>>>>
>>>>> MATTER what exactly a resource is and what the exact  
>>>>> relationship between resources and representations is.
>>>>
>>>> Wrong. Denotation is not introduced by a higher level, and even  
>>>> if it were, it would not be higher in an architectural sense.  
>>>> You, in this very message, in fact brought denotation into the  
>>>> picture, by telling me that a URI can "identify" a person. URIs  
>>>> are symbols strings, and the ONLY POSSIBLE SEMANTIC RELATIONSHIP  
>>>> between ANY symbol and a physical object, is denotation. Sorry to  
>>>> shout there a little, but the point needs to be made strongly.  
>>>> That is what "denotation" means: it is all that is left of  
>>>> "identifying" when you take away the actual network machinery,  
>>>> the computational byte-transferring. And you have to take this  
>>>> away when you start claiming to talk of relationships between  
>>>> names (of any kind) and non-computational entities such as people  
>>>> (or indeed of any kind), simply because computational byte- 
>>>> transfer talk is COMPLETELY IRRELEVANT to semantic relationships  
>>>> (such as "identification") between symbols (of any kind) and non- 
>>>> computational entities. The fact, if it is a fact, that this word  
>>>> claiming that your symbols "identify" non-computational entities  
>>>> such as people or books (or the weather in Oaxacala, to take  
>>>> another random example) , you are no longer playing in the  
>>>> network-architectural sandbox, precisely because these kind of  
>>>> things simply are not connected to networks in the same  
>>>> functional sense that things like web servers are. Either HTTP is  
>>>> a computational notion or it isn't. If it is, then it is indeed  
>>>> quite simple. And I would be delighted if the HTTP literature  
>>>> grandeur: it has ALWAYS claimed to be not just about web sites  
>>>> and web servers and files and documents, but about the whole  
>>>> doing real semantics or you aren't. If you aren't, then don't  
>>>> make ridiculous claims about "identifying" things that have no  
>>>> possible connection to any physical network, or of  
>>>> "representations" that cannot be sent in a byte stream.
>>>>
>>>>> model resources and representations. That's not a good thing,  
>>>>> and it would be good for interoperability if everyone agreed.  
>>>> for different ('linked data', Timblish) reasons, people want a  
>>>> GET on those URIs to finish up, one way or another, with useful  
>>>> information being returned. This is a problem. It would be ugly  
>>>> to have two 'kinds' of URI, and impossible to change the millions  
>>>> of 'normal' URIs in any way at all. The decision allows the few  
>>>> non-normal URIs to take part in a slightly irrational HTTP dance  
>>>> which allows everyone to say: look, since it didn't return a 200  
>>>> code, its not 'normal', and HTTP says it doesn't identify  
>>>> anything at all; so the 'normal' assumptions about what it  
>>>> denotes are cancelled. And that cancellation is the entire  
>>>> content of the decision: it has no other purpose. The nature of  
>>>> the entity which handles the GET, and the presence or absence of  
>>>> 'representations' of it, are irrelevant.
>>>>
>>>> Which, if i means anything at all when used between a symbol and  
>>>> a non-computational entity, means 'denote' (or, if you prefer,  
>>>>>> representation. Even if the representation exists and the  
>>>>>> server has access to it, it cannot return it with a 200 code  
>>>>>> when the URI is intended to denote some other thing, in  
>>>>>> particular a non-information resource of some kind.
>>>>>
>>>>> resource", then that's great, and let me shake your hand  
>>>>> brother, but this has no effect on HTTP.
>>>>
>>>> that very handy English word "representation" is one of its  
>>>> normal senses, not when I refuse to use it at all. There are  
>>>> many,  many kinds of representations of things, and only a  
>>>> miniscule proportion of them have anything even remotely to do  
>>>> with computers or network transfer protocols.
>>>>
>>>>>
>>>>>> knows (somehow, perhaps by some externally agreed convention)  
>>>>>> is being used to denote a non-information resource; what should  
>>>>>> it do? HTTPrange14 requires it to not deliver a 200-coded  
>>>>>> reply, but your criterion requires that it must. This is why I  
>>>>>> think the wording should make absilutely minimal assumptions  
>>>>>> about what exactly the 303 means.
>>>>>
>>>>> resource" obviously MUST entail "does not have representations  
>>>>> in the HTTP sense". In fact, that IS the definition of "non- 
>>>> merely the servant whose job it is to emit the appropriate code  
>>>> to make everything work properly. But it is AN information  
>>>> resource, and it may well have a representation (in the http  
>>>> sense) of itself. Its just a different resource than the one the  
>>>> URI denotes/refers to.
>>>>
>>>>> Wrapping up:
>>>>>
>>>> should apply to this case as well, according to what you say  
>>>> here. I should be able to send a GET request to the number  
>>>> seventeen and expect to get sent back a 200-coded response with a  
>>>> suitable numeral in its body, say "17". I know that is  
>>>> ridiculous: but it FOLLOWS FROM WHAT YOU ARE SAYING; ergo, what  
>>>> you are saying is ridiculous.  So you ought to modify what you  
>>>> are saying, so that it makes more sense.
>>>>
>>>>>
>>>>> relationships, and this is critically important if we want to  
>>>>> use HTTP URIs as identifiers for things that exist outside of  
>>>>> the Web. But the HTTP protocol itself is and should be agnostic  
>>>>> with regard to your position in these debates. That's layering.
>>>>
>>>> philosophical or semiotic) ignorance, and hubris. You want http  
>>>> to be universal, but you are claiming a kind of universality  
>>>> which goes way beyond anything to do with network architecture,  
>>>> and so you can't escape the consequences by appealing to network  
>>>> design principles.  Maybe you don't intend to be doing this, but  
>>>> it is being done by what you (and I should cast this in a kind of

---

From: Larry Masinter <[email-masked]>
Date: Tue, 14 Jul 2009 12:46:22 -0700

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:[email-masked] 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

---

From: Richard Cyganiak <[email-masked]>
Date: Wed, 15 Jul 2009 03:11:54 +0200

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

---

From: Xiaoshu Wang <[email-masked]>
Date: Tue, 14 Jul 2009 22:16:47 -0400

> httpRange-14 slowly "trickle down" into the specs.
If this is your purpose, I believe that you do need to mull it over 
before talking to Pat.   Pat was trying to give httpRange-14 some wiggle 
room  while you, who I have always thought to be a staunch supporters of 
httpRange-14, was trying to prevent.

This raises an even bigger issue because it seems to me that, how you 
have interpreted the principle of orthogonal specification seems quite 
different from Pat's (I guess).  What the principle of orthogonal 
specification supports is not a layering architecture but a scalable 
architecture.  In other words, the semantic of one specification must be 
independent of the other.  This is where httpRange-14 breaks because it 
tempers the semantics of *200* code, which, by httpRange-14, relies on 
the nature of resource.  303 is not critical because its semantics is 
for all purpose, hence always *politically* correct.

Darn, no wonder I was confused.  I honestly don't know what you two were 
fighting about. :-)

Xiaoshu

---

From: Julian Reschke <[email-masked]>
Date: Wed, 15 Jul 2009 11:38:25 +0200

> This conversation is filling my mailbox. Some general

Larry,

thanks a LOT for this reply.

My takeaway is that we (the HTTPbis WG) are willing to do minor word 
smithing to clarify things, but that's it.

In draft 07, we already replaced "resource owner" by "URI owner", as 
suggested by Roy.

In another mail 
(<http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0044.html>), 

> 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

---

From: "Ray Denenberg, Library of Congress" <[email-masked]>
Date: Wed, 15 Jul 2009 09:01:32 -0400

I for one would appreciate if as much of this discussion as possible remain 
ON-list.  I really don't care if peoples' mailboxes are filling up or people 
are offended by some off-color language or disagreeable arguments.  I've 
learned more about this issue from this thread than from reading all the 
"relevant" documents.

--Ray

----- Original Message ----- 
From: "Richard Cyganiak" <[email-masked]>
To: "Larry Masinter" <[email-masked]>
Cc: "'Pat Hayes'" <[email-masked]>; "'Roy T. Fielding'" <[email-masked]>; 
"'Jonathan Rees'" <[email-masked]>; "'Julian Reschke'" 
<[email-masked]>; "'HTTP Working Group'" <[email-masked]>; 
<[email-masked]>
Sent: Tuesday, July 14, 2009 9:11 PM
Subject: Re: Review of new HTTPbis text for 303 See Other

---

From: Pat Hayes <[email-masked]>
Date: Wed, 15 Jul 2009 09:24:06 -0500

On Jul 14, 2009, at 10:20 AM, Xiaoshu Wang wrote:

>>>>> is out of place on the HTTP protocol level. There is no such  
>>>>> thing as denotation in the universe of the Hypertext Transfer  
>>>>> Protocol. Yes, people obviously use HTTP URIs to denote all  
>>>>> sorts of things, and a lot can be said about how one should  
>>>>> model resources and representations based on the things one  
>>>>> wants to denote, and what one can or cannot infer about the  
>>>>> denotation of a URI based on HTTP interactions, but none of this  
>>>>> matters one bit for the actual operations of the protocol.
>>>>
>>>> Seems to me that this may have been true before http-range-14,  
>>>> but it is not a stance that can possibly be maintained in the  
>>>> face of that decision. And your final sentence above is, surely  
>>>> you can yourself see, tendentious. If the HTTP 'layer' really  
>>>> were completely unconcerned with denotation, how could one  
>>>> *possibly* infer anything about what a URI denotes from  
>>>> *anything* about HTTP interactions?
>>> *bad* that this whole idea of httpRange-14 and information  
>>> resource thing is.
>>
>> As I said in another post, I think http-range-14 is terrible, but  
>> all the alternatives are worse.
> problem at the first place. The problem is created by pushing IR  
> into the Web architecture.  But just like the web architecture  
> should not deal with hamburgers, it should not deal with IR as well.
>
>>>> "representations" in its specialized sense. (It would be very  
>>>> good manners, in fact, to clarify just what that highly  
>>>> specialized sense of "representation" is, and state explicitly  
>>>> that it is not intended to cover any wider sense of  
>>>> phrases as "knowledge representation".) And you should be quite  
>>>> open and clear about the fact that this view of HTTP is not  
>>>> compatible with the http-range-14 decision.
>> awww:representation" of the hamburger. Or at least, it had better  
>> not mean that, since hamburgers don't have awww:representations.  
>> Web pages about hamburgers can represent (not awww:represent) a  
>> hamburger, and they of course have awww:representations. But an  
>> awww:repreresentation of a representation of X is not an  
>> awww:representation of X.
> I mentioned that let us not ignore *the existence of an agent* --  
> the one who implements the URI.  I do not know if a hamburger *can  
> or cannot* have an awww:representation because I am not a  
> hamburger.  But I do know that *I can* give a hamburger an  
> awww:representation.  You don't have to believe me, that is none of  
> my business.

True, I don't have to, but I would like to know a little more about  
HOW you would create an awww:representation - or, which I believe to  
be synonymous, a representation in  the sense used in Roy's REST  
thesis - of a hamburger. I will take mine without tomatoes, well done  
and dressed with mayo and mustard.  So, to check our understanding,  
this must be a representation, encoded in a byte stream, which stands  
in the same relation to a hamburger that the html which I get back  
from, say, the Amazon website stands in to that web page.

Maybe we should take this offline if it is annoying others, but I  
actually think it might be quite informative about our various  
clashing intuitions here.

Pat

>  But to say that no one should believe me, you cross the line for  
> being either ignorant (of being me) or arrogant (of being you).
>>> of this kind of hallucination.  But at the end, it ends up with  
>>> its own one -- the hallucination of the information resource.
>>
>> awww:representation of. That is certainly not a hallucination,  
>> because you just made HTTP contact with it.
> resource".  That is denotation semantics of that word's use.  It is  
> fine with me because we might just call it "xyz" -- for the sake of  
> avoiding confusion.  But this denotation semantics should not affect  
> how *I* implement *my* URI.  Most of all, it should not affect how  
> *I* use the Web.
>
> Xiaoshu
>
>

---

From: David Booth <[email-masked]>
Date: Wed, 15 Jul 2009 10:53:59 -0400

[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

---

From: Pat Hayes <[email-masked]>
Date: Wed, 15 Jul 2009 10:32:53 -0500

> other terms you've used, please refrain.)

Sorry if it gave offense, all the above was meant ad dicto, not ad  
hominem. And Im a Brit, so "bloody" is a friendly form of emphasis.

> way; it is not intellectually dishonest to do so.

Well, let me react to that. (This is an aside from the main topic, but  
it helps explain motivation and attitude.) True, Richard may have  
accidentally become the spokesperson here for an entire culture, which  
I regret if true, and apologize to him for having to bear the brunt of  
my frustration.) But I do feel that there seems to be what I can only  
describe as a somewhat arrogant double standard throughout the W3C  
regarding these issues of technical usage. The W3C documents use a  
number of words in VERY peculiar ways, ways which (1) do not  
correspond even remotely to their normal usage and (2) do not conform  
to the historical usage of these words even in the 'technical'  
literature out of which the W3C usages have grown, and yet every  
attempt to ask for clarification of these usages is rebuffed,  
sometimes angrily or impolitely; and there is nothing even remotely  
like a glossary available. (Contrast, say, the ISO's almost anal  
approach to giving definitions of every usage.)  My favorite example  
is "resource", of course (which was first used in this context by  
Engelbart, who meant it in close to its normal English sense), but  
"representation" is another, and "identity" (fortunately no longer in  
wide use) yet another. Seems to me that when your own technical  
audience has to use your words prefixed with 'awww:' in order to  
distinguish these deviant meanings from those used in the rest of the  
world, that there may be a slight issue here.

> specification is being written.

I strongly disagree. It may be good practice to be deliberately  
agnostic about technical details, but it is never good practice to be  
deliberately obscure about the meanings of the words one is using. And  
you cannot reasonably hold two positions, along the lines of "I am  
deliberately not going to say what I mean because it does not matter"  
and "Your interpretation is wrong because that isn't what I meant".  
Which is exactly what Richard did in this email thread.

> that are outside of its scope.

Of course, but this IS in its scope. That is the whole point.

> It is common, reasonable,

I am not asking it to answer that question. That question is already  
answered: a URI *can* identify a person. Absolutely no doubt about  
that. What I am asking for is that the spec RECOGNIZE this and DEAL  
WITH IT. Richard told me that HTTP "does not care" what the URI  
identifies, or what counts as a representation of it. I took him at  
his word and gave him an immediate example of a resource and a  
representation of that resource, which according to what he had said,  
I was entirely able to do within the confines of the spec, since it  
DID NOT CARE about that stuff, and he rejected the example without  
comment on the grounds that it wasnt to do with computer architecture.  
Which was exactly my point. If HTTP does not care what a resource is,  
or what a representation of a resource is, then it should apply to  
examples like mine. Obviously, it does not: ergo, it DOES CARE what a  
URI identifies and what a representation is. Then the spec should say  
this, and say it clearly.

Its not enough to hide behind the defense that this is (obviously)  
just a technical spec in a technical area, and philosophy has nothing  
to do with that technical topic. That would be fine if URIs could not  
identify people and books, but they can. It might be OK if http codes  
didn't imply anything about what URIs denote, but (according to http- 
range-14) they do. I know y'all don't want to be in this semantic/ 
philosophical stew, you just want to be technologists. But the fact  
is, you are in it whether you like it or not. HTTPrange14 put you in  
it. I didn't make this stew, but I am going to go on yelling as long  
as y'all refuse to recognize that this stew exists and it is your job  
to handle it properly, or at least not poison it.  The reason why we  
can't just all assume , in a kind of collegial technophile way, that  
we are all just talking about networks, is that these very technical  
usages of words on which you yourself rely to explain the spec have  
*already* been extended to a wider usage which makes no sense when we  
are only talking about networks. URIs *can* "identify" people, and  
other "resources"  that cannot possibly have a (n awww:)  
"representation".

> to identify a person for the purpose of that system.

For the purpose of the entire Web. It isn't something that can be  
closeted inside a 'system'.

> Well, that's a question outside of the "mailto:"

Sure. Im not asking you or anyone else to solve age-old problems. But  
I am asking you to recognize, and say, that HTTP now has some  
interaction with semantics. Its not a very deep or complex  
interaction. IMO, it can be entirely contained in the observation that  
a 200-coded response indicates that the URI denotes (refers to) the  
resource that it identifies, and a 303 doesn't indicate that. That's  
all you need to say[[**see below for less**]]:  questions of what  
exactly is the nature of that identified resource, etc., are outside  
the scope, of course. But you are already assuming that 'the resource  
identified by the URI' makes sense, right? Because if that is  
problematic, then the whole of HTTP is problematic.

> the context of the HTTP spec.

Well, it does it that thing that matters has been tied to a technical  
device - a 303 code- that is specified in this spec.

> are exactly.

I have never said that it did. I have always consistently said that  
http-range-14 is about URIs, not about resources.

> For the purpose of resource identification, it should

I understand about the red flag. But URI issues aren't really just  
about the semantic web. They are about the whole Web, which is slowly  
becoming semanticized. URIs convey meanings in all sorts of ways, they  
aren't purely a transfer protocol addressing mechanism any more.

[[**]]If you recall, my interaction on this thread arose from wanting  
the HTTP spec to simply say that a 303 response can be thrown  
basically on the server's whim: it needs no "I have no appropriate 200  
response to send" justification for the 303. Put another way, the  
server is not *obliged* to return a 200 response even when it does  
have a representation available that it *could* respond with. This is  
purely within the HTTP 'layer', but it is necessary to allow servers  
to respond with 303s *for semantic reasons* which may (should?) have  
absolutely nothing to do with the existence of awww:representations.  
And that is all: I would shut up immediately if that wording were to  
be used. BUt right now, the wording does have this must-send-200-if- 
possible constraint in it, which is potentially operationally  
incompatible with the http-range-14 recommendation. Ironically, it is  
so precisely because of the orthogonality you want to preserve: the  
semantics of the URI need have nothing to do with the presence or  
absence of an awww:representation. It can be determined by other,  
loftier, matters to do with denotation, whatever that is. I think it  
would be helpful if the spec could just remark that the reason for  
this responding-code freedom is because 303 codes have these semantic  
uses, or that it is generally understood (informative ref httprange14)  
that 200 codes have semantic implications which might want to be  
avoided in some cases, or the like, but I also understand your  
reluctance to include anything in a spec that might come back to bite  
you.

> It *is* about how to use and implement the HTTP protocol.

I don't want it to be about what the resource is, but it does need to  
at least recognize that the resource might not have ANY possible  
connection with any computer ever made. It needs to at least show that  
it understands that not ALL resources are just on the other side of an  
http interface, even when they are identified by an http URI.

> other. Not all URIs are HTTP URIs. Please try to be more careful.

Point taken.

Pat

---

From: Pat Hayes <[email-masked]>
Date: Wed, 15 Jul 2009 10:56:50 -0500

On Jul 14, 2009, at 8:11 PM, Richard Cyganiak wrote:

> off-list. (Tomorrow, Pat -- I need to mull it over a bit.

OK, but see quick remark below.

> )
> think of. Including using HTTP URIs to denote people.

And my entire beef with it is that there is a case it misses, which is  
a URI denoting a person but which resolves to an http endpoint which  
has access to a 200-codable representation of itself (not of the  
person, but of it, the resource on the other side of the http  
interface.) And that IS a possibility, and I can even imagine some  
very nice uses for it.

> It's good to see httpRange-14 slowly "trickle down" into the specs.

Agreed.

Pat

---

From: Manfred Baedke <[email-masked]>
Date: Wed, 15 Jul 2009 18:01:04 +0200

Pat Hayes wrote:
> deliberately obscure about the meanings of the words one is using.
Yes, it is. Take any mathematical theory as an example showing how it 
works perfectly to be deliberately obscure about the meaning of atomic 
terms of a technical language.

Regards,
Manfred

-- 
Manfred Baedke

<green/>bytes GmbH
Hafenweg 16
D-48155 Münster
Germany
Amtsgericht Münster: HRB5782

---

From: Xiaoshu Wang <[email-masked]>
Date: Wed, 15 Jul 2009 12:15:54 -0400

Pat Hayes wrote:
>>>>>> Protocol. Yes, people obviously use HTTP URIs to denote all sorts 
>>>>>> of things, and a lot can be said about how one should model 
>>>>>> resources and representations based on the things one wants to 
>>>>>> denote, and what one can or cannot infer about the denotation of 
>>>>>> a URI based on HTTP interactions, but none of this matters one 
>>>>>> bit for the actual operations of the protocol.
>>>>>
>>>>> fact that this view of HTTP is not compatible with the 
>>>>> http-range-14 decision.
>>>> "http://example.com/a.hamburger" makes it to denote a hamburger. 
>>>> Then HTTP-GET "http://example.com/a.hamburger" means "get me an 
>>>> awww:representation" of the hamburger. But it does NOT mean the 
>>>> "get" like in "get me that hamburger" as what we would say in front 
>>>> of a grill.
>>>
>>> not mean that, since hamburgers don't have awww:representations. Web 
>>> pages about hamburgers can represent (not awww:represent) a 
>> cannot* have an awww:representation because I am not a hamburger.  
>> But I do know that *I can* give a hamburger an awww:representation.  
>> You don't have to believe me, that is none of my business.
>
[I will make this public as if our discussion were desired as Ray has 
expressed.]

To answer your HOW-to question, allow me to use my proposed scheme-less 
URI convention.

Assume that I own the domain name "xiaoshu.wang" and I designated the 
(scheme-less) URI:  "//xiaoshu.wang/a.hamburger" to denote the hamburger 
burning on the grill of my backyard on a sunny day. 

In our traditional web jargon, the URI -- "//xiaoshu.wang/a.hamburger" 
-- is an absolute URN, hence its semantics is only about denotation.

There are many ways that we can get a representation (in the most 
general philosophical sense) of "//xiaoshu.wang/a.hamburger".

We can *see* it, i.e., by turning our head and opening our eyes so light 
rays can bounce off the hamburger into our eyes.  Let's denote this 
particular kind of representation retrieval with a URI scheme -- see, as 
follows:

"see://xiaoshu.wang/a.hamburger"

In our web jargon, the above URI is a URL because it is bound with the 
transportation protocol "SEE".  By this URL, we can get back a 
representation, in the form of a bunch of photons delivered to our retina.

Similarly, we can

hear://xiaoshu.wang/a.hamburger (with air pressures as representations 
delivered to our eardrum)
get://xiaoshu.wang/a.hamburger (some heat, pressure, as representations 
delivered to our hand)
eat://xiaoshu.wang/a.hamburger (some fat, carbo, salt, as 
representations shuffled down to our throat)
....
http://xiaoshu.wang/a.hamburger (some document packed in bits as 
representations delivered to our laptop or desktop or your palmtop....)

So, what is the HOW that you want to know?  Is it "how do we see, hear, 
eat, and HTTP"?  Then, take a biology class or in the latter case, read 
the HTTP spec.  But here is the point: we don't need to know how we see 
in order to see (i.e., to perceive the photons) because our body just 
*can*.  By the same token, we don't need to know how the Web delivers an 
awww:representation in order to use the  awww:representation because the 
Web just *can*.

So, I do not think that is the reason for you to ask the know-HOW.  The 
reason that you want to ask the KNOW-how is that you want to feel 
confident in taking the content carried in a representation to be true 
(or false).  This is a valid concern.  But the only way to increase that 
confidence is to gather more information.  There is no other way 
around.  For instance, even if you see the hamburger, don't you still 
need some additional information to make sure what you see is not a 
reflection from a mirror or simply not a mirage?  Does knowing how human 
see helps you any more than not-knowing it? It is the same with 
IR/httpRange-14.  Even if we all complied, don't you still need to know 
if someone gets it right or wrong before committing to your truth?

For instance, if I take "http://xiaoshu.wang/a.hamburger" to denote a 
hamburger.  When you de-reference that URI, you get back a 200.  But 
after reading my awww:representation, you may say "No, you cannot do 
that because ....".  But the real cause is that our interpretation about 
HTTP could be different in the same way that our interpretation about 
hamburger, dog, or IR could be different.  But aren't we taking about a 
hamburger, what the heck does it has anything to do with dog, IR, or HTTP?

The cause of all these mess is either our confusion with messing up 
representation with resource, or, the duality of HTTP-URI as both a name 
and a locator.  If we separate "[http:]//xiaoshu.wang/a.hamburger" -- 
the URN -- from "http://xiaoshu.wang/a.hamburger" -- the URL, I don't 
think you will have much concerns.  Do you?

Xiaoshu

---

From: Pat Hayes <[email-masked]>
Date: Wed, 15 Jul 2009 11:22:58 -0500

On Jul 15, 2009, at 4:38 AM, Julian Reschke wrote:

> In another mail (<http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0044.html 
> >), Roy proposed another change:
>

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

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

---

From: Pat Hayes <[email-masked]>
Date: Wed, 15 Jul 2009 15:38:38 -0500

On Jul 15, 2009, at 11:15 AM, Xiaoshu Wang wrote:

>>>>>>> on these two counts, you end up ranting against a POV that I  
>>>>>>> do not hold.
>>>>>>>
>>>>>>> I especially continue to maintain that any talk about  
>>>>>>> denotation is out of place on the HTTP protocol level. There  
>>>>>>> is no such thing as denotation in the universe of the  
>>>>>>> Hypertext Transfer Protocol. Yes, people obviously use HTTP  
>>>>>>> URIs to denote all sorts of things, and a lot can be said  
>>>>>>> about how one should model resources and representations based  
>>>>>>> on the things one wants to denote, and what one can or cannot  
>>>>>>> infer about the denotation of a URI based on HTTP  
>>>>> The assumption here is that httpRange-14 is the right  
>>>>> direction.  But that is a big *if*. If anything, this debate  
>>>>> only shows how *bad* that this whole idea of httpRange-14 and  
>>>>> information resource thing is.
>>>>
>>>>>> "identify" non-computational things, or that such things can  
>>>>>> have "representations" in its specialized sense. (It would be  
>>>>>> very good manners, in fact, to clarify just what that highly  
>>>>>> representation, for example the sense in which it it used in  
>>>>>> such phrases as "knowledge representation".) And you should be  
>>>>>> quite open and clear about the fact that this view of HTTP is  
>>>>>> not compatible with the http-range-14 decision.
>>>>> The HTTP protocol should be about pushing representation  
>>>>> around.  And it shouldn't careless about if its URI denotes or  
>>>>> identifies anything.  The latter is up to the one who implements  
>>>>> that particular URI.   Let's not ignore the existence of such  
>>>>> entities because it is those who expressed their denotation  
>>>>> semantics.
>>>>>
>>>>> does NOT mean the "get" like in "get me that hamburger" as what  
>>>>> we would say in front of a grill.
>>>>
>>> awww:representation.  You don't have to believe me, that is none  
>>> of my business.
>>
>> HOW you would create an awww:representation - or, which I believe  
>> to be synonymous, a representation in  the sense used in Roy's REST  
>> thesis - of a hamburger. I will take mine without tomatoes, well  
>> done and dressed with mayo and mustard.  So, to check our  
>> understanding, this must be a representation, encoded in a byte  
>> stream, which stands in the same relation to a hamburger that the  
>> html which I get back from, say, the Amazon website stands in to  
>> that web page.
>>
> [I will make this public as if our discussion were desired as Ray  
> has expressed.]
>
> To answer your HOW-to question, allow me to use my proposed scheme- 
> less URI convention.
>
> Assume that I own the domain name "xiaoshu.wang" and I designated  
> the (scheme-less) URI:  "//xiaoshu.wang/a.hamburger" to denote the  
> hamburger burning on the grill of my backyard on a sunny day.
> In our traditional web jargon, the URI -- "//xiaoshu.wang/ 
> a.hamburger" -- is an absolute URN, hence its semantics is only  
> about denotation.

Hmmm... I guess I was presupposing that we were talking about HTTP  
URIs in this forum. But as I don't think it makes any real difference,  

> general philosophical sense) of "//xiaoshu.wang/a.hamburger".

Oh, no disagreement there. But I didn't ask about getting a  
representation in a broad sense, but in the very narrow sense used in  
awww debates, where it means the kind of 'representation' which Roy  
talks about in his thesis REST model, and which HTTP talks about when  
it refers to representations of resources. This much narrower sense  
refers to a byte stream which is a sufficiently detailed and precise  
representation as to allow a close-to-identical copy of the resource  
to be assembled by the recipient of the message. For example, this  
kind of representation of a page of a book might be a high-resolution  
image of the page, or it might be a PDF file which can be  
reconstructed into an accurate digital rendering of the original page.  
But a mere description in RDF, for example, would not meet these very  
tight requirements on awww:representations. Seems to me that to do  
this with hamburgers requires a matter transporter or telekinesis.

>
> We can *see* it, i.e., by turning our head and opening our eyes so  
> light rays can bounce off the hamburger into our eyes.  Let's denote  
> this particular kind of representation retrieval with a URI scheme  
> -- see, as follows:
>
> In our web jargon, the above URI is a URL because it is bound with  
> the transportation protocol "SEE".  By this URL, we can get back a  

But (1) we cannot send photons in a byte stream, and (2) I don't think  
that the light reflected back from a thing is a 'representation' of  
that thing in any useful sense. When we see things, our brains  
construct representations of them which constitute our visual  
awareness, but thats not done by the photons themselves and its not in  
any way isomorphic to the photons. Still, this is a philosophical  
quibble in  the context of this discussion, as you could run your  
point with a URI prefix of cognizes://

>
> Similarly, we can
>
> hear://xiaoshu.wang/a.hamburger (with air pressures as  
> representations delivered to our eardrum)
> get://xiaoshu.wang/a.hamburger (some heat, pressure, as  
> representations delivered to our hand)

They key is that its a DOCUMENT in this case, and the document  (not  
the hamburger) is the resource which is represented by the bits. And a  
representation of a representation of X is not a representation of X.  
Even denotation isn't transitive in this way: the Hollywood sign is  
called "Hollywood sign", and that phrase does not refer to Hollywood.

>
> So, what is the HOW that you want to know?  Is it "how do we see,  
> hear, eat, and HTTP"?  Then, take a biology class or in the latter  
> case, read the HTTP spec.  But here is the point: we don't need to  
> know how we see in order to see (i.e., to perceive the photons)  
> because our body just *can*.  By the same token, we don't need to  
> know how the Web delivers an awww:representation in order to use  
> the  awww:representation because the Web just *can*.

>
> So, I do not think that is the reason for you to ask the know-HOW.   
> The reason that you want to ask the KNOW-how is that you want to  
> feel confident in taking the content carried in a representation to  
> be true (or false).

Im not arguing here for boolean descriptive representations. Quite the  
contrary, in fact: I don't think that awww:representations can  
possibly be false (they can be *wrong*, but not *false*)

>  This is a valid concern.  But the only way to increase that  
> around.  For instance, even if you see the hamburger, don't you  
> still need some additional information to make sure what you see is  
> not a reflection from a mirror or simply not a mirage?  Does knowing  
> how human see helps you any more than not-knowing it? It is the same  
> with IR/httpRange-14.  Even if we all complied, don't you still need  
> to know if someone gets it right or wrong before committing to your  
> truth?

I am not going along this line of thought here. Im not concerned about  
certitude or confidence in knowing the representation is correct or  
complete. (I actually don't agree with you about the only way being to  
get more information, BTW, but that really is a philosophical debate  
unsuited to this forum.) My only point is that there is genuine, if  
narrow, sense of representation in which the payload of a 200-coded  
HTTP reply is one of them, but things like descriptions, pictures,  
smells and sights are not; and are such that things that cannot be  
stored digitally in Web servers and given a http interface cannot have  
these representations. This is the sense of awww:representation used  
in the REST literature and often by Timbl in his writings and which  
the HTTP specs are presuming, I believe. And in this narrow sense of  
'representation', I am still quite convinced that a hamburger cannot  
have one of them. It cannot be awww:represented in the sense that,  
say, a Word document or a JPG image can be.

>
> For instance, if I take "http://xiaoshu.wang/a.hamburger" to denote  
> a hamburger.  When you de-reference that URI, you get back a 200.   
> But after reading my awww:representation

Of what? Not of the hamburger, surely.

> , you may say "No, you cannot do that because ....".  But the real  
> cause is that our interpretation about HTTP could be different in  
> the same way that our interpretation about hamburger, dog, or IR  
> could be different.  But aren't we taking about a hamburger, what  
> the heck does it has anything to do with dog, IR, or HTTP?
>
> representation with resource, or, the duality of HTTP-URI as both a  
> name and a locator.  If we separate "[http:]//xiaoshu.wang/ 
> a.hamburger" -- the URN -- from "http://xiaoshu.wang/a.hamburger" --  
> the URL, I don't think you will have much concerns.  Do you?

Maybe not, but I fail to see how to make the URL/N distinction if they  
are indistinguishable textually. And I am still left wondering how to  
refer to a locatable thing like a Web page, if I have to use a URN to  
refer to it. Why not just use the name everyone else uses?

Pat

---

From: Xiaoshu Wang <[email-masked]>
Date: Wed, 15 Jul 2009 18:01:34 -0400

>> To answer your HOW-to question, allow me to use my proposed 
>> scheme-less URI convention.
>>
>> (scheme-less) URI:  "//xiaoshu.wang/a.hamburger" to denote the 
>> In our traditional web jargon, the URI -- 
>> "//xiaoshu.wang/a.hamburger" -- is an absolute URN, hence its 
>> semantics is only about denotation.
>

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.  There is only one thing that is certain.

There is a awww:representation.  In the web, it is usually carried in 
(or is ) a byte-stream.  You work with representation in the Web, which 
HTTP is part of.  Just like you work with photons in your daily life, 
which SEE is part of.  This is the only common ground.

>> this particular kind of representation retrieval with a URI scheme -- 
>> see, as follows:
>>
Thus, the protocol SEE is defined as a bunch of photons bombarded on my 
retina over a time period.   And the representation of SEE is defined as 
a collection of photons over my retina. This is *my* definition of SEE, 
just as how HTTP is defined by its HTTP protocol of saying if and how to 
fire off a bunch of bytes.  I am not talking about cognition.  I am 
talking about protocol.
> called "Hollywood sign", and that phrase does not refer to Hollywood.
Nope.  The "document" is what is delivered to you.  Applying HTTP to 
"//xiaoshu.wang/a.humburger" returns a document, not a hamburger.   I 
don't know what "http://xiaoshu.wang/a.humburger" (the URL but not the 
URN) denotes and I don't care.  Just like if you ask me what does "see a 
hamburger" denotes, I don't know and I don't care.  I got an visual 
image of (aka, SEE) a hamburger, that is all.

You can call whatever the referent of "http://xiaoshu.wang/a.humburger" 
a document or IR.  That is fine.  But the difference is.  An IR exists  
-- not because of some a priori character that HTTP can apply to.  But 
an IR exists as a posteriori -- only because an HTTP protocol is applied 
to. A digitized file sitting in your hard-drive is not an IR.  It 
becomes an IR only when you mapped your web server 's directory to it.  
Thus, it is *you* who made someone or something an information 
resource.  Not the thing itself.
>> know how the Web delivers an awww:representation in order to use the  
>> awww:representation because the Web just *can*.
>
>>
>> The reason that you want to ask the KNOW-how is that you want to feel 
>> confident in taking the content carried in a representation to be 
>> true (or false).
>
I will skip the truth part since it is not your concern.  (I thought it 
is because Stuart has this concern before.)

My point with the URL/URN is.  Then, if we have a URN/URL distinction.  
Then, we will say

The URN of "http://exmaple.com/a.hamburger" denotes the hamburger.
The URL of "http://example.com/a.hamburger" denotes an information 
resource, or whatever you want to call it.

Would you still have concern?  Would you still need to care if the URL 
200 or not?

This is in the same essence of TBL's suggestion to use hash-URI as names 
because the problem can only be solved through syntax because there 
isn't a priori nature for something to be IR. (But the hash-URI has its 
problem with existing use of slash URI and it still need to clarify its 
meaning when conneg is considered).

Xiaoshu

---

From: David Morris <[email-masked]>
Date: Wed, 15 Jul 2009 13:19:51 -0700 (PDT)

I repeat my objection to the inclusion of "for further information" and
ambiguous and I believe unspecified. I would be happy if the phrase is 
dropped or it could be expanded but I can't suggestion an explanation as I 
don't know what 'further information' would apply, what its syntax would 
be, etc.

On Wed, 15 Jul 2009, Julian Reschke wrote:

> My takeaway is that we (the HTTPbis WG) are willing to do minor word smithing 
> to clarify things, but that's it.
>
> 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
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 16 Jul 2009 13:11:00 +1000

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.

I'm generally tolerant of discussion that is related to HTTP even if  
it's not within our charter, but this thread is both voluminous and,  
in parts, quite distant from the focus of the WG.

Therefore, please desist from including the ietf-http-wg list unless a  
specific question needs to be discussed by the WG.

Thanks,

On 15/07/2009, at 11:01 PM, Ray Denenberg, Library of Congress wrote:

> I for one would appreciate if as much of this discussion as possible  
> remain ON-list.  I really don't care if peoples' mailboxes are  
> filling up or people are offended by some off-color language or  
> disagreeable arguments.  I've learned more about this issue from  
> this thread than from reading all the "relevant" documents.
>
> --Ray
>
> ----- Original Message ----- From: "Richard Cyganiak" <[email-masked] 
> >
> Cc: "'Pat Hayes'" <[email-masked]>; "'Roy T. Fielding'" <[email-masked] 
> >; "'Jonathan Rees'" <[email-masked]>; "'Julian Reschke'" <[email-masked] 
> >; "'HTTP Working Group'" <[email-masked]>; <[email-masked]>
>> 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.  

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

---

From: Pat Hayes <[email-masked]>
Date: Thu, 16 Jul 2009 06:42:25 -0500

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

> 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

---

From: David Booth <[email-masked]>
Date: Thu, 16 Jul 2009 09:39:29 -0400

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

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 17 Jul 2009 03:26:54 +0200

tor 2009-07-16 klockan 06:42 -0500 skrev Pat Hayes:

> 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

---

From: Pat Hayes <[email-masked]>
Date: Sat, 18 Jul 2009 12:55:04 -0500

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

> 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

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.

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

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

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

Pat

---

From: Henrik Nordstrom <[email-masked]>
Date: Sat, 18 Jul 2009 22:35:30 +0200

[resent from the correct address]

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

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

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

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

Fully agree.

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

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

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

> 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  

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

---

From: Larry Masinter <[email-masked]>
Date: Sun, 19 Jul 2009 07:28:17 -0700

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

---

From: Pat Hayes <[email-masked]>
Date: Mon, 20 Jul 2009 13:16:24 -0500

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

Pat

> the server implementers and webmasters/authors to define such

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.

> outside of HTTP specifications.

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

> the same URI, but that's a different topic.

I am also not talking about behaviors.

> of HTTP, ignoring the rest of the world.

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

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

>> so I am surprised to hear that the HTTP protocol intends any notion  

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

> 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

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.
> request for a specific URI, with no relevance to requests for other

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.

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

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

> and resource is more of a special case, and not related to any of what

It is related. In fact it is critical.

> representation to be used within HTTP (or as close to that you can  

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.

> 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

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

>        interface that can be used to interact with a resource via  

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.

>                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

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.

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

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

> 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

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

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 21 Jul 2009 03:37:25 +0200

> wall to some other, unspecified, "implementer". Its nothing to do with  

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. 

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

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

> any relationship between a URI and a resource, they are talking about  

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.

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

> 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  

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.

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

> different URIs which both identify the same resource, that changes the  

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.

> It is related. In fact it is critical.

To me when talking about HTTP it's not.

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

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

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

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.

> limits what a resource can be. You cannot interact with the number 27  

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.

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

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

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

> Does that mean, of the resource that the URI identifies? And does  

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.

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

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

> server containing) R.

In terms of HTTP R is the requested resource.

>  (Do you agree?) In this case, http-range-14  

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

> mind, where the "requested resource" in this case must be R itself.

Yes.

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

> 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  
> possibility, and is consistent with a 303 response?

Yes.

> Or would you say  

No.

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

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

---

From: Dan Brickley <[email-masked]>
Date: Tue, 21 Jul 2009 09:52:04 +0200

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

> 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 [email-masked]), 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.

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

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

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

> 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

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

> about. HTTP specifications end at the http endpoint and it's http mapped

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?

[...]

> 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

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 21 Jul 2009 18:14:31 +1000

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,

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 21 Jul 2009 15:57:20 +0200

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

> 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 

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.

> for Pat Hayes (ie. the person whose mailbox is [email-masked]), rather 

Ok, if you say so.

> be exposed and accessed via the HTTP protocol

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

Yes.

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

> 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 

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

> 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 

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.

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

> internal and not directly relevant)

Correct.

> removed, ie. information removed from some external backend system.

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

> *requested* for anything more than the resource-to-thing mapping to be 

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. 

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

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

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

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.

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

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

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

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

> people... but also when dealing with backend car SQL records or people 

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

---

From: Pat Hayes <[email-masked]>
Date: Fri, 31 Jul 2009 13:00:05 -0500

> general URI definition of resource.

It is not 'slightly' narrower. The general definition of 'resource'  
has it meaning absolutely anything, real or imaginary, concrete or  
abstract, that can be referred to and distinguished from other things  
(the last five words inserted to make sense of the 'identify'  
language). This is not a 'slightly' wider sense than the one that you  
apparently have in mind. It is a spectacularly, transfinitely, almost  
cosmically wider sense. It is as wide as human language knows how wide  
to make a distinction.
> the world is then the parts that the specification intends to cover  

BUt when your specification is about a language or a notation, and in  
part about what that notation means, and when in fact that notation is  
being used to mean things in a certain (wide) category, then such  
usage does fall within the scope of your specification, and you should  
deal with it, if only by stating explicitly that you are not going to  
consider it.  But to ignore it and pretend that it isn't there, by re- 
defining an existing terminology so as to avoid interfacing with other  
specifications, is both intellectually dishonest and socially  
irresponsible. Sorry, strong language, but I really do feel strongly  
about this, having had to face up to this issue myself when writing  
specifications.

> as used in english

Never mind the English meaning, which is now lost to history in these  
debates.

> or even the "resource" as defined by URI
> specifications.

But does it not strike you as inappropriate to simply ignore the  
normative definitions used in defining technical terms which you  
yourself use? What is the point of writing specifications if other  
specification writers are free to redefine the terminology which my  
specification defines normatively?

> resources are, only if they can be accessed and/or transmitted via  

I understand all this. But there are cases where the resource  
identified by the HTTP URI is, in fact, not one of these. That is -  
regardless of its true metaphysical nature, which I agree we will not  
delve into - whatever it really is - it is not something that can be  
accessed and/or transmitted. Such cases are REAL, they are out there  
in the actual world. If your spec refuses to acknowledge this, then it  
is simply an incomplete specification; and as such, it is less useful  
that it can and should be.

> Has it? Care to explain that again then, using the term meanings as

http-range-14 specifies an HTTP-defined action (the use of a 303  
redirect) be used under circumstances which arise when the URI in  
question identifies a thing which is not a resource according to the  
narrow sense of 'resource' which you are arguing HTTP should restrict  
itself to.
> Ok. My point here is that HTTP does not care about those semantics.

And my point is that it must, at least to the minimal extent required  
to state a normatively required action under circumstances which can  
only be described by referring to those semantics. (And also - though  
this is more controversial - I would argue that in fact, HTTP is  
already concerned with the semantics of URIs, even though it refuses  
to acknowledge this elementary fact.)

> All
> for executing that semantic mapping

This is a conceptual mistake. Semantic mappings are not executable.

> of URI to resource (in URI terms),

I hope not. I try to keep the resource/representation distinction  
clear. There are however two or more notions of what counts as a  
'representation': when in doubt, I use the now-standard circumlocution  
awww:representation to refer to the narrow sense used in REST and (I  
assume) HTTP.

> ) and their possible representations as defined by HTTP.
>

As I have tried to emphasize, this is not a 'slight variation', and in  
any case I doubt if there are going to be any more changes once we  
have established that a resource can be absolutely anything.

> than the general English "resource".

No, the English meaning is actually narrower than the URI  
specifications sense, which is highly idiosyncratic and of fairly  
recent coinage (see the Wikipedia entry of 'resource' for a good  
history.)

> text outside that context is non-sense.

PLease read what I wrote more carefully. To say that the server has  
available a transmittable representation of the requested resource,  
without referring to the URI that was used to request the resouirce,  
is not nonsensical in any way at all. It implies, as I read it, that  
this condition holds independently of the URI, so that if the same  
resource is requested by different URIs then this condition either  
holds for both of them or for neither of them. So it rules out the  
possible case where the condition holds for one URI request but not  
for the other URI request, with a different URI but the same resource.

....

> resource is as I already explained NOT as general as the URI resource.

No, the situation is far worse than this. According to your previous  
paragraph, we can have a situation where two URIs identify the same  
resource according to the URI spec, but must be understood by HTTP as  
corresponding to different resources. Just narrowing the sense of  
'resource' will not get you this horrible situation. This, if indeed  
you are right (nobody else has suggested this idea, so I hope you are  
wrong) makes the HTTP and URI specifications sharply **incompatible**  
with one another.

> sense as the two by definition can not be the same thing.

And yet, there are HTTP URIs which identify Julius Caesar, in the  
sense of "identify" used in the URI specs. And, moreover, Http- 
range-14 actually places some conditions on what HTTP must do with  
such a URI, **because** it identifies a resource of that 'off-Web'  
kind. So the behavior of HTTP depends, in part, and can only be  
accurately specified by mentioning, the situation where a URI  
identifies a "non-HTTP" resource. And this DOES make sense. In fact ,  
it is actually TRUE.
> the application of HTTP to any such entities.

And, to repeat, that view is untenable, precisely because semantics is  
not about computation. Your notions of layering simply do not apply  
when you are purporting to make decisions based upon meanings: which  
you are, whether you like it or not. HTTP-range-14 has made this  
choice for you. Don't argue with me, if you want to keep your nice  
tidy 'layering': go back and argue with whoever made the http-range-14  
ruling.

> Anyone is free to define
> resources do not exists in HTTP terms

They do exist, you are just refusing to look at them.

> and need to be mediated via some

Not any more. Thats why I'm making such a fuss about it. And BTW,  
these are not 'borderline' issues.

> about. HTTP specifications end at the http endpoint and it's http  

Hmm, so in these cases, the HTTP URI identifies **two** different  
resources? The URI one and the HTTP one? Is that what you are saying?  
I doubt if many people on the TAG would like this.

> http server endpoint or it's policy)

OK, I wasnt meaning to confuse this issue, just using 'transmittable'  
as a shorthand. Sorry.

> preferences of the client etc.

But they also differ, presumably, when the identified resource is  
Julius Caesar. Or do they? I really have no way to know.

> purely a technical definition.

And says nothing about the cases when HTTP URIs are used to refer to  
other kinds of resource. Which is an ostrich way of writing  
specifications.

> language, and the word "denote" is not really part of my limited  

Sorry. 'denotes' AKA 'refers to', 'identifies', 'is a name for', is  
used as a name for'. I will try to remember to say 'refers to' or  
'identifies'.

> what that resource denotes in the broader sense.

But you cannot ignore this completely when the URI does *in fact*  
identify something other than a network-accessible resource.

> * that HTTP does not care if they do

OK, but...

> different then they do in fact NOT refer to the same resource

That simply does not make sense. What you say here (seem to say here)  
is logical nonsense. Look, if two names refer to the same thing (call  
it a resource if you like) then there is only one thing that they both  
refer to. So to say that 'as far as X is concerned' they refer to  
different things, is simply meaningless. There aren't two things there  
to be referred to, in this case. So, sorry: they DO IN FACT refer to  
the same resource. If HTTP thinks otherwise, then HTTP is simply  
WRONG. There is no finer-grained identity than identity itself.

If you think I am technically mistaken on this topic, please refer me  
to some published work which makes semantic sense of the view of  
identity that you are basing this claim upon. (And as I have had this  
discussion many times before, if you are going to cite LISP at me:  
identity in LISP is EQ, not EQUAL.)

> They may

I have no idea what you mean by a facet of a resource. What 'facets'  
does Richard or J.C. have?

> network-accessible resource used for interfacing with Richard C.

First, there is no such resource: Richard C. isn't the kind of thing  
that you can 'interface' with over a network. (Well, maybe by email,  
but then we would be talking about his emailbox.)  Second, its not  
important what HTTP 'restricts' itself to: the fact remains that (in  
the case described) the URI does **in fact** identify Richard, not  
some network-accessible thingie that stands in some relationship to  
him. (That thingie might have its own URI, of course, which does  
identify it.) So if what you say here is correct, I presume that HTTP  
simply treats the URI as not having a corresponding http:resource at  
all. Right? Because it is a basic assumption of the whole Web  
architecture that the resource identified by a URI is unique. So if  
the URI identifies Richard, it can't also identify the thingie.

> In terms of HTTP R is the requested resource.

I thought you might say that. So what then is the relationship between  
a requested resource and the resource identified by a URI? Apparently  
they can be different, so we have at least two resources somehow  
connected with a URI. Are there any more?

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

No, it is not. It is simply a fact that there is no transmittable  
awww:representation of Richard. He isn't the kind of thing that has  
such representations.

But in any case, it appears that, on your account, the whole action of  
HTTP need have **absolutely nothing** to do with the resource that the  
URI identifies (in this case, Richard.) So tell me: here I am with a  
URI, and in order to find out more about what it identifies, I use it  
in an HTTP GET, and something happens. What, if anything, can I  
conclude about the resource that my URI identifies? AFAIK, the only  
possible answer is, on your account: nothing at all. Its all going to  
be mediated by the resource that the URI requests, and that need have  
nothing to do with what it identifies. Nor need the response codes  
have any connection with the resource identified by the URI: indeed,  
if the requested (not identified) resource has a 200-level-suitable  
awww:representation, then that is what the server must send me back,  
even though neither it not its source (that is, in the above example,  
neither the awww:representation of R not R itself) need have anything  
whatever to do with the identified resource (Richard). Right?

I agree this picture has a certain elegance and simplicity, but it  
makes complete nonsense of almost everything that has been said and  
written about URIs and resources for the past decade. It means that  
the picture of Web architecture promoted by the TAG is sharply and  
fatally different from that supported by HTTP.

Anyone else like to comment on this?

Pat