W3C home > Mailing lists > Public > www-tag@w3.org > June 2005

Re: [httpRange-14] Resolved

From: Tim Berners-Lee <timbl@w3.org>
Date: Sun, 19 Jun 2005 13:50:36 -0400
Message-Id: <F07089D8-3666-4343-B9D7-0C289021C352@w3.org>
Cc: W3C TAG <www-tag@w3.org>
To: Jan Algermissen <jalgermissen@topicmapping.com>


On Jun 19, 2005, at 4:30, Jan Algermissen wrote:

>
> TAG members,
>
> two immediate questions:
>
> Given the resolution below, it is not good practice and not in sync  
> with Web architecture
> to issue a URI for a dog and have the server deliver 2xx responses,  
> yes?

If you refer to the thing as a dog, and your sever says 200 to an  
HTTP get for it, one of you is wrong. It is an error.

> What about URIs with fragment identifiers? If a GET to http:// 
> www.example.org/list-of-my-stuff
> returns 2xx does that also imply that ttp://www.example.org/list-of- 
> my-stuff#my-dog is
> an information resource?

The fragment identifier makes it a completely different URI, of  
course.  The architecture already defined applied here: if you have a  
200 response then you have a representation of the information  
resource. Check the Internet Content Type.  The original URI  
identifies the same thing as the local identifier my-dog in the  
computer language (ICT) given.   See AWWW.

> Or asked in another way: is the server's response code to a URI  
> also considered the response code of any fragment identifier URIs  
> 'based' on this URI?

Absolutely not.

> Jan
>
>
>
> On Jun 19, 2005, at 6:25 AM, Roy T. Fielding wrote:
>
>
>>
>> As everyone here knows, the TAG has spent a great deal of time
>> discussing the httpRange-14 issue, as described at
>>
>>    http://www.w3.org/2001/tag/issues.html#httpRange-14
>>
>> I am happy to report that we came up with a reasonable
>> compromise solution at the recent TAG f2f meeting at MIT.
>>
>> <TAG type="RESOLVED">
>>
>> That we provide advice to the community that they may mint
>> "http" URIs for any resource provided that they follow this
>> simple rule for the sake of removing ambiguity:
>>
>>   a) If an "http" resource responds to a GET request with a
>>      2xx response, then the resource identified by that URI
>>      is an information resource;
>>
>>   b) If an "http" resource responds to a GET request with a
>>      303 (See Other) response, then the resource identified
>>      by that URI could be any resource;
>>
>>   c) If an "http" resource responds to a GET request with a
>>      4xx (error) response, then the nature of the resource
>>      is unknown.
>>
>> </TAG>
>>
>> I believe that this solution enables people to name arbitrary
>> resources using the "http" namespace without any dependence on
>> fragment vs non-fragment URIs, while at the same time providing
>> a mechanism whereby information can be supplied via the 303
>> redirect without leading to ambiguous interpretation of such
>> information as being a representation of the resource (rather,
>> the redirection points to a different resource in the same way
>> as an external link from one resource to the other).
>>
>>
>> Cheers,
>>
>> Roy T. Fielding                            <http://roy.gbiv.com/>
>> Chief Scientist, Day Software              <http://www.day.com/>
>>
>>
>>
>>
>
> ______________________________________________________________________ 
> ______________________
> Jan Algermissen, Consultant &  
> Programmer                             http://jalgermissen.com
> Tugboat Consulting, 'Applying Web technology to enterprise  
> IT'       http://www.tugboat.de
>
>
>
>
>
Received on Sunday, 19 June 2005 17:50:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:36 GMT