RE: Dereferencing HTTP URIs (redux?)

Hello Pat,

> If this is more or less right, I think that this way of 
> *explaining* the decision might be helpful for many readers, 
> as it makes the decision seem less arbitrary.  It was for me, 
> at any rate.

Speaking only for myself I think that what you've written is "more or
less right"... yes. 

Thank you,

Stuart
--
> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] 
> On Behalf Of Pat Hayes
> Sent: 05 September 2007 19:49
> To: Williams, Stuart (HP Labs, Bristol)
> Cc: Mark Nottingham; W3C-TAG
> Subject: RE: Dereferencing HTTP URIs (redux?)
> 
> 
> >Mark:
> >>  1) Re-defining the semantics of a core element in a protocol
that's 
> >> been widely deployed for more than a decade will  surprise and 
> >> displease some people.
> >Stuart:
> >On the whole I'd like to feel that where we end up would be a 
> >legitimate use pattern for an existing facility.
> >
> 
> Although I have been a rather harsh critic of the range-14 
> decision in the past, 

:-) 

> please allow me to suggest a way to 
> describe it which makes it exactly into that, i.e. a 
> legitimate use pattern for an existing facility. (Perhaps 
> this will simply be a restatement of the TAG's own thoughts 
> when coming to this decision; if so, I apologize for the 
> repetition, but observe that it took me a long time to 
> reconstruct this chain of thought.)
> 
> The situation in which this arises is where a URI is thought 
> of by its owner - who is also, we will suppose, the agent who 
> has control over the http endpoint to which it resolves - as 
> denoting a non-information resource. What can this agent 
> possibly do, when handed an http GET for this URI? If it 
> simply returns some representation (in the REST sense) of a 
> resource, then this must be an information resource, so 
> cannot be the intended denotation. On the other hand, it 
> seems churlish and unhelpful, and possibly wrong, to return 
> an error code, as the URI does indeed denote something. 
> Putting myself in the place of such an agent, therefore, I 
> would wish to return some useful information about the 
> referent, but without implying that the resource which is the 
> source of this information is itself the referent of the URI 
> sent to me. On the other hand, this information source is 
> indeed a resource itself, so must have a URI of its own; and, 
> its being an information resource, this URI does indeed 
> denote it, so cannot be the URI which originated the request 
> which has put me into this quandary. Given all this, then, 
> the simplest and most useful thing I can do, it seems, is to 
> send back the information that I have as a response to the 
> request, but also to indicate that it comes not from the 
> resource denoted by the original URI, but from a different 
> resource with its own URI, to which in fact I will re-direct 
> the GET request precisely so that it can be successfully 
> responded to; thereby letting the requestor know that (1) the 
> URI they sent me denotes something, (2) it does not denote 
> this information resource, and (3) which URI does denote it. 
> This is about the best I can do under the circumstances.
> 
> Seen in this way, the 303 is not so much a 'signal' to the 
> requesting agent that the resource in question is, or might 
> be, a non-information resource - a signal which seems 
> arbitrary, ad-hoc and potentially confusing - but rather 
> simply as an acknowledgement of the fact that a 
> non-information resource cannot *possibly*, by virtue of its 
> very nature, return a direct response to a GET request. It is 
> the only rational move that a responding agent can make under 
> the circumstances, and still cleave to the global assumptions 
> that (1) a URI which retrieves a response from a resource 
> must also denote that resource, which must therefore be an 
> information resource, and (2) a URI which denotes anything at 
> all should not return an error HTTP code.
> 
> If this is more or less right, I think that this way of 
> *explaining* the decision might be helpful for many readers, 
> as it makes the decision seem less arbitrary.  It was for me, 
> at any rate.
> 
> Pat
> --
> ---------------------------------------------------------------------
> IHMC		(850)434 8903 or (650)494 3973   home
> 40 South Alcaniz St.	(850)202 4416   office
> Pensacola			(850)202 4440   fax
> FL 32502			(850)291 0667    cell
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes


--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks
RG12 1HN
Registered No: 690597 England

Received on Thursday, 6 September 2007 15:16:16 UTC