Re: non-HTTP URIs in HTTP requests

Erik Wilde writes:

> what i am looking for is to keep that decision out of the scheme itself. 


It depends, not surprisingly, on what you mean by "keeping [it] out of the 
scheme itself". 

As others have commented, there's no specific prohibition or restriction 
on the use of non-http scheme URIs a the Request-URI for HTTP, at least as 
far as I know.  So, in that sense you get what you're asking for. 

However, it's common (though not in all cases essential) that the nature 
of resources identified is to some degree restricted by the specification 
for the scheme.  For example, RFC  4248 says [1]:

"The Telnet URL scheme is used to designate interactive services that may 
be accessed by the Telnet protocol [STD8]."

So, the telnet URI scheme cannot (by my reading) be used to designate blog 
entries, news reports, or other document-like resources.   I think this 
pretty much implies that it would be inappropriate to give back a status 
code 200 for an HTTP GET request to a telnet URI.

The corresponding question for you is, I think, "what is the range of 
resources that can properly be identified with the geo URI scheme?"  I 
doubt, for example, that using it to designate the front page of the New 
York Times would be appropriate.   So, in that sense, you are unlikely to 
achieve what you say you want:  decisions you make regarding the nature of 
geo-identified resources will indirectly constrain the HTTP operations and 
status codes that are appropriate for use with them.  At least, that's how 
I understand it.

Noah


[1] http://tools.ietf.org/html/rfc4248

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








Erik Wilde <dret@berkeley.edu>
01/07/2010 01:29 PM
 
        To:     noah_mendelsohn@us.ibm.com, "uri@w3.org" <uri@w3.org>
        cc:     Jan Algermissen <algermissen1971@mac.com>
        Subject:        Re: non-HTTP URIs in HTTP requests


hello noah.

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

you're right that an HTTP exchange about geo: URIs needs rules, but 
these can be (and i think should be) separate from the geo: URI scheme 
itself. and currently i am just trying to make sure that there's nothing 
in HTTP itself that keeps me from using HTTP as a protocol for non-HTTP 
resources.

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

what i am looking for is to keep that decision out of the scheme itself. 
for some scenarios, that representation (the map image or HTML embedding 
that image) may be useful and appropriate, for others that may not be 
the case. HTTP also does not make any assumptions about the 
representations available for resources, it only gives you a way to ask 
for one and get one if there is one. which is exactly why i want to use 
HTTP.

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

for some applications, map imagery may be appropriate, and google maps 
has proven that this representation (even though it's limited in its 
coverage of what a location "is") is hugely useful for a lot of people.

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

maybe the semweb world view is different, but that is something i want 
to stay away from, because it treats HTTP as axiomatic, which is a 
constraint i am not interested in. i think for practical purposes there 
are many possible representations of geolocation points, and while there 
may not be the one that is authoritative and/or exhaustive, there are 
many use cases in which it makes sense to build interactions around 
representations of geolocation points. my current goal is to figure out 
how to best use HTTP as the protocol for these interactions.

thanks and cheers,

dret.

Received on Thursday, 7 January 2010 20:24:28 UTC