[Uri-review] Re: early draft of a "geo:" URI scheme.

[Frank Ellermann <nobody at xyzzy.claranet.de>]

Alexander Mayrhofer wrote:

> Your point is "data that is just simple data does not deserve a 
> URI scheme?" - well, the geo URI has semantics behind. It's not
> just two or three numbers, those numbers have a special meaning
> as they identify an actual physical location.

Sorry, my counterexamples with string:foo or number:4 "URIs" were
quick shots, and silly.  Of course I saw that you specified the
semantics for geo: URIs.

A better counterexample might be an mjd: scheme for the "Modified 
Julian Dates", e.g. mjd:768872.269630?show=gregorian&show=posix
resulting in 2106-02-07T06:28:16Z, and an overflow for the seconds
since 1970-01-01 when using only 32 bits.

"Modified Julian Dates" are a nice format for date calculations.
But is that enough for an URI scheme ?  

> (Note to myself: add "distance calculation" to the draft?)

Why not, in a "nautical" appendix.  You could also explain how to
convert minutes and seconds to the geo: format.  It probably won't
work if I state geo:53.5618,9.9652 as destination in a taxi...

Let alone with a disclaimer that I'm not sure about the order or 
missing minus signs.  

> URIs have quite a few advantages - they can be used in a myriad
> of protocols, they have a well known scheme, and they have a
> well known unified definition - their specification.

Depends, all I recall about the info: scheme is that I considered 
this as "scheme name squatting" and net abuse.  There are far too
many obscure schemes, although I personally like gopher: or dict:.

RFC 4395 chapter 2.1 is clear about this.  This might affect geo:,
it's possible to use http://service.example/?lat=x&long=y&do=stuff
instead of geo:x,y?do=stuff&server=service.example (or similar)

> There are a bunch of formats / schemes available for expressing
> geographic information in various protocols/data formats (vCard
> GEO property, geo.* META tags, geo microformat, DHCP LCI, DNS LOC,
> etc.) Some of them do not even specify what kind of reference
> system they use, which altitude datum is to be used, etc.. All of
> them are tied to a specific protocol/data format.

Yes, a BCP or PS recommending a single format would be nice.  We
have an RFC for (a no nonsense proper subset of) ISO timestamps, 
something in that direction about geo locations would be good.

We don't have a timestamp URI scheme, and I don't miss it so far.

> Also, geographic information is becoming more and more important

Yes.

> considering that more and more internet services make use of
> location information, i think a common scheme to identify and
> address locations in internet protocols would make sense.

Depends.  For something like isbn: I could (in theory, not with my
stoneage browser) configure that I want to go to amazon.de when I
click on it.  Or that I want to get an XML-snippet from [unknown]
for an xml2rfc reference for the given ISBN.

But I'm not exactly interested to change this isbn: configuration
depending on what I want today.  With geo: URIs there could be
numerous different services, probably depending on the query.  

> i tend to use the 80/20 rule here...

When folks say "80/20" wrt mail and spam they intend to drop legit 
mails, and the worst of them intend to deliver spam.  "80/20" is a
red flag for me.  They will ship [insert browser] configured to use
[insert sitefinder] for geo: URIs, and they will make it hard for
ordinary users to change this configuration.

Frank



_______________________________________________
Uri-review mailing list
Uri-review at ietf.org
https://www1.ietf.org/mailman/listinfo/uri-review