Re: non-HTTP URIs in HTTP requests

hello noah.

thanks a lot for your response.

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

i think this one is a little different because the scheme itself has an 
interaction protocol baked in. the resources are defined as those ones 
which can be interacted with by using telnet. this is similar to HTTP, 
which also combines identification and interaction. this probably goes 
back to the old days of URL vs. URN and the question of how much a URI 
scheme implies localization and/or interaction.

> The corresponding question for you is, I think, "what is the range of 
> resources that can properly be identified with the geo URI scheme?" 

this is easy to answer and the only thing that geo tries to do: it is 
the set of all locations (defined by WGS84 coordinates) on the surface 
of the earth.

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

i guess this is the httpRange-14 issue again. since the resources are 
non-information resources (in the fuzzy sense of httpRange-14, but then 
again there is no real definition of the term, so it is hard to tell), 
maybe only 303 would be required by httpRange-14. but then again, these 
are not HTTP resources, so httpRange-14 does not even apply (but again, 
httpRange-14 is a bit fuzzy whether it applies to HTTP resources only or 
to URI-identified resources in general). i don't think the duality 
introduced by httpRange-14 is very helpful or even well-defined, and 
thus i would argue that the representation and the interactions for 
resources such as geo resources depends on the use case and intended 
interactions, and thus there is no "inherent" set of representations or 
interactions that should be hardcoded into such a URI scheme.

what i am currently trying to do is to make sure that geo URIs can be 
used in HTTP conversations, and then it will be up to usage patterns or 
a separate spec to say how this is done in terms of methods and media 
types involved.

cheers,

dret.

Received on Thursday, 7 January 2010 20:44:09 UTC