login/register

Snip!t from collection of Alan Dix

see all channels for Alan Dix

Snip
summary

As everyone here knows, the TAG has spent a great deal o... the httpRange-14 issue, as described at http://www.w3.org/2001/tag/issues.html#httpRange-14 I am... that we came up with a reasonable compromise solution at... f2f meeting at MIT. <TAG type="R

[httpRange-14] Resolved from Roy T. Fielding on 2005-06-19 (www-tag@w3.org from June 2005)
http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html

Categories

/Channels/techie/semantic web

[ go to category ]

For Snip

loading snip actions ...

For Page

loading url actions ...

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

HTML

As everyone here knows, the TAG has spent a great deal of time discussing the httpRange-14 issue, as described at <a href="http://www.w3.org/2001/tag/issues.html#httpRange-14">http://www.w3.org/2001/tag/issues.html#httpRange-14</a> I am happy to report that we came up with a reasonable compromise solution at the recent TAG f2f meeting at MIT. &lt;TAG type="RESOLVED"&gt; 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. &lt;/TAG&gt; 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).