Re: non-HTTP URIs in HTTP requests

Erik Wilde writes:

> geo: is not a protocol, it's a URI scheme. there is no protocol for geo: 

> URIs, the resources just exist (locations on earth), and the "protocol" 
> is part of the application ("go there", "show me pictures from there", 
> "find a route to there from where i currently am").

Right, but you're asking about using geo-scheme URIs as the Request-URI 
for an HTTP request, and HTTP >is< a protocol.  Your HTTP request will 
necessarily have a method -- assume for the moment that method is GET. The 
question is whether the GET method can be meaningfully implemented on your 
resource, or more to the point, which status codes are sensible in in 
responses.

For example, if your HTTP response has a 200 code, then the response 
implies that your geo resource has a "representation", which is by the way 
included in the response.   If you decide that you what your geo-scheme 
URIs identify are some sorts of documents (perhaps a map centered on the 
point designated), then it seems clear to me that a 200 response to a GET 
is appropriate, and you can send back the image of the map.  If (as I 
suspect) geo-scheme URIs identify points on the surface of the earth, as 
opposed to map documents, then I'd guess that a 200 is likely 
inappropriate, but a 303 "See other" might well be a way to point people 
to information about that point (maps, elevation, rainfall, whatever). I'm 
not convinced that a physical point on the earth "has a representation" in 
the HTTP/AWWSW sense.  See permathread on httpRange-14, etc.

In any case, you do have to look at the protocol side of things, and ask 
questions such as the ones posed above, I think.

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Thursday, 7 January 2010 17:13:28 UTC