Review of new HTTPbis text for 303 See Other

[Jonathan Rees-3]

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
representations. Perhaps when LRDD comes on line the need to use 303
to provide metadata will decrease, but I see no reason to restrict 303
to representationless resources. In addition, the TAG's httpRange-14
rule [1] does not restrict the resource in the 303 case in any way at
all, so saying that it does would introduce an incompatibility that
would have to be resolved.

It is easy to imagine other cases where one uses a 303 because one has
a description (e.g. an article abstract) of the resource but the
resource itself, while having perfectly good "representations", is
protected or offline.

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

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.

Even if you say that "what representations are adequate" and so on are
up to the URI owner (a term defined not by HTTP but rather by AWWW),
as opposed to the resource owner, you are making a very strong
architectural commitment that is certainly not in the scope of HTTP.

I advise that you simply remove the phrase " and thus entirely
determined by the resource owner(s)".

Best
Jonathan Rees

[1] http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html

[Julian Reschke]

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.

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

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

> ...

BR, Julian

[Jonathan Rees-3]

Comments inline below.

On Wed, Jul 1, 2009 at 12:56 AM, Julian Reschke<julian.reschke@...> 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
>

[Ashok Malhotra]

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


Jonathan Rees wrote:

> Comments inline below.
>
> On Wed, Jul 1, 2009 at 12:56 AM, Julian Reschke<julian.reschke@...> 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
>>
>>    
>
>  

[Yves Lafon]

On Tue, 7 Jul 2009, Jonathan Rees wrote:

> Comments inline below.
>
> On Wed, Jul 1, 2009 at 12:56 AM, Julian Reschke<julian.reschke@...> 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.

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?

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

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

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

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

         ~~Yves

[Julian Reschke]

Hi Jonathan,

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

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

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

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.

> 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

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.

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

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

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

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

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

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.

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

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

BR, Julian

[Roy T. Fielding]

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

[Julian Reschke]

Roy T. Fielding wrote:
> 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,

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

[Jonathan Rees-3]

On Wed, Jul 8, 2009 at 6:18 AM, Julian Reschke<julian.reschke@...> wrote:
> 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.

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

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.

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

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.

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

[Pat Hayes]

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

> Hi Jonathan,
>
> > ...
>>> 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.
>
> Indeed. (<http://www.w3.org/2001/tag/issues.html#httpRange-14>)
>
>> 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.
>
> 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.
>
>> 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
>
> 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.
>
>> 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.
>
> 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.

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)."
>
>> 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.
>
> ...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.
>
>
>>>> ...
>>>>
>>>> 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.
>
> 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.
>
>>>> 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).
>> ...
>
> Understood. How do others feel about HTTP's use of the term  
> "resource owner"?
>
> BR, Julian
>
>
>

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

[David Booth-6]

On Wed, 2009-07-08 at 12:18 +0200, Julian Reschke wrote:
[ . . . ]

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

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.

[Roy T. Fielding]

On Jul 8, 2009, at 1:37 PM, Pat Hayes wrote:
>> "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.

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

[Jonathan Rees-3]

On Wed, Jul 8, 2009 at 4:59 PM, Roy T. Fielding<fielding@...> wrote:
> 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

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

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

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

[Roy T. Fielding]

On Jul 8, 2009, at 2:30 PM, Jonathan Rees wrote:

> On Wed, Jul 8, 2009 at 4:59 PM, Roy T. Fielding<fielding@...>  
> wrote:
>> 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
>
> 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
>
> "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."
>
> 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.

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

[Jonathan Rees-3]

On Wed, Jul 8, 2009 at 6:03 PM, Roy T. Fielding<fielding@...> wrote:

> 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

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

[Julian Reschke]

Roy T. Fielding wrote:

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

Sounds good to me.

BR, Julian

[J Ross Nicoll-3]

Roy T. Fielding wrote:

>> 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.
>
> No, we have other redirect codes for that.

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

[Pat Hayes]

On Jul 9, 2009, at 5:03 AM, Jonathan Rees wrote:

> On Wed, Jul 8, 2009 at 6:03 PM, Roy T. Fielding<fielding@...>  
> wrote:
>
>> 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
>
> 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".)

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

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

[Xiaoshu Wang-3]

Pat Hayes wrote:

>
> On Jul 9, 2009, at 5:03 AM, Jonathan Rees wrote:
>
>> On Wed, Jul 8, 2009 at 6:03 PM, Roy T. Fielding<fielding@...>
>> wrote:
>>
>>> 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
>>
>> 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".)
>
> 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?

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

[Roy T. Fielding]

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

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