RE: URI registries and schemes

noah_mendelsohn@us.ibm.com wrote:
> > Can you impose on you to give me your best synopsis and/or a URL to 
> > the most representative email on the mailing list?  Thanks 
> in advance.
> 
> Sure.  The TAG tracked this issue under the name 
> httpRange-14.  We've switched issue tracking systems in the 
> meantime.  Our old system tracked the issue at [1], and our 
> new tracker-based system follows up at [2].  As recorded in 
> [1], the TAG agreed the following on 15 June 2005:
> ====
> The TAG provides 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:
> 
>     * If an "http" resource responds to a GET
>       request with a 2xx response, then the
>       resource identified by that URI is an
>       information resource;
>     * 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;
>     * If an "http" resource responds to a GET
>       request with a 4xx (error) response,
>       then the nature of the resource is
>       unknown.

Thanks, that helps.

Reading that however I get the feeling that they is a missing some options
for logical closure.  For example you have:

	1.) Is a document
	2.) Could be a document or a thing
	3.) Unknown 

But you don't have:

	4.) Is not a document (i.e. is a 'thing')

Can you check my logic?  Doesn't it seem we need such an option?  Roy's
comment on [1] would imply that URIs don't just point to docs:

	The reason we call it a URI that identifies a resource, rather
	than a UDI that identifies a document, is because we want a URI to
	reference things in the future -- to point to a source of future
	useful things.  That's what resource means.  It is therefore
	impossible to "retrieve" a resource, since the fact that it is
	available "over there" is an essential part of it being a resource;
	the resource remains over there, so the only thing that is
	retrieved is an instantaneous representation of the resource
	at the point in time at which it was generated by the origin.

That said, would it be crazy to suggest a new HTTP status code (say 208)
that means: Is a 'Thing'?  I don't know what intermediaries with do with 208
but to test what a browser would do I ran this PHP code and both FF2 and IE7
loaded it w/o complaint from Apache on localhost:

	<?php
	   header("HTTP/1.2 208 Is a Thing");
	?> 
	<html>
	<head><title>HTTP 208 Test</title></head>
	<body>
	<h1>HTTP 208 Test</h1>
	This is a test of my 'proposed' status code for HTTP of 208: Is a
'Thing'
	<body> 
	</html> 

Having such a defined code might actually make the idea of an location
identifer at an HTTP URL more palatable to Erik and/or people with similar
concerns as he, and it appears to be backward compatible...

Anyway, thanks for considering.

-- 
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org
http://atlanta-web.org 

P.S. I know this might be the wrong list, but we can always more to the
right list it if merits further discussion.

[1] http://lists.w3.org/Archives/Public/www-tag/2002Jul/0253

Received on Tuesday, 18 December 2007 19:27:28 UTC