Re: Issue-57

On 2011-06 -16, at 14:36, Xiaoshu Wang wrote:


. As I have argued a long time ago, httpRange-14 forces me to answer a metaphysical question that I cannot answer before I can put a thing on the web.

You have always been wrong about that.  You could argue that you have to have a perfect definition of "thing" before you put a thing on the web.  Or you could argue that you must have perfect definition of "pie" before you put a pie in an oven.  This is not the case.   Millions of people are putting documents on the web without worrying about an exact definition of document.
You can attack any spec by trying to argue about the meaning of any terms ad nauseam. But it is not constructive.  I have noticed that groups asked to write about x and which start by trying to define x often just lost in the weeds, as one can pick holes in any english definition.

Let me substitute the word 'pie' with URI. Hence, the question is: must anyone have a perfect understanding of a 'URI' before s/he put a URI on the Web? I don't think so. But , TAG thinks otherwise via httpRange-14.




What I would like to suggest is let's start the web architecture that would tolerate everyone. Let's make 200 code as it was before. That is: a 200 code says nothing except that a request has been successfully responded.

If the client can gather nothing from the 200 code at all, the there is not much point
in doing the operation.  In the web architecture, it is the 200 that allows the
client to in future point others too the web page using the same URI
and expect them to get the same document. (not any document about the same thing,
or any document by the same author or any document of the same length)
(You can nit-pick about the definitions, but it is not very constructive).

200 — without httpRange-14 -- means nothing? Per the HTTP protocol, 200 means that a request and been granted with success.

HTTP is a manual for doing network transportation. It is not a world dictionary for its identifier. I think what makes the Web scales so well is its principle of orthogonal specifications. Tabbing any semantics of a HTTP URI's-referent into it breaks this principle and I think it is a grave mistake.

We all have to remember this, no matter how much we try

"HTTP GET" is NOT the same as, and will never be, "get".



If TAG thinks that it is critical to make the distinction with regard to the nature of what the URI is used for, then invent some extra 2xx code as Tim suggested. For example, 209 = Information Resource (or Content of Document). 210 for non-information resource (or non content of a document).

You are thinking of this upside-down again.   It isn't the class of object -- it is the relationship with the response.  Do you mean:  209 = here is contents of x; 210 = here is data about  x ?

I am suggesting if people feel uncomfortable using HTTP-URI to refer to, say a Person, then respond 210. And for people who wants to be clear that she is using her HTTP-URI to refer to a 'document', whatever it is, respond 209. If people wants to make two URIs for them and thinks one of them should not have a direct response, s/he can use 303 to redirect. And  -- please -- in their documents make a statement about the relations between these two URIs. (That is: HTTP protocol tells you nothing about the semantics of a URI's referent).

For those who don't care or feel comfortable, just respond with 200 as it is.


Do you suggest the bulk of the pages on the existing web switch to 209 instead of 200?

No. I am suggesting that the existing web remains at 200 and let the web to evolve for those who cares much about those relations/distinction. If these relations are as important as you suggested, sure, 209 will be the dominant response code down the road. But will that hurt?

Xiaoshu Wang