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

From: Alexander Mayrhofer <[email-masked]>
Date: Thu, 01 Mar 2007 15:01:41 +0100

Hi,

we have been working on a first draft of a "geo:" URI to identify geographic
locations (see draft announcement below). A supplemental website for the
development of the URI scheme is available at http://geouri.org/, and the
draft will be on the agenda of the IETF68 GEOPRIV session.

Comments & reviews about the document as well as the URI scheme itself are
of course strongly appreciated (please ignore the typos in the draft for now..)

thanks,

Alex Mayrhofer / Christian Spanring

---------
A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: A Uniform Resource Identifier for Geographic Locations ('geo' URI)
	Author(s)	: A. Mayrhofer, C. Spanring
	Filename	: draft-mayrhofer-geo-uri-00.txt
	Pages		: 13
	Date		: 2007-2-23
	
   This document specifies an Uniform Resource Identifier (URI) for
   geographic locations using the 'geo' scheme name.  A 'geo' URI
   provides latitude, longitude and optionally altitude of a location in
   a simple, human-readable form.  The 'geo' URI is not tied to a
   specific application or protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mayrhofer-geo-uri-00.txt

_______________________________________________
Uri-review mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/uri-review

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 01 Mar 2007 18:54:16 +0100

Alexander Mayrhofer wrote:
 
> we have been working on a first draft of a "geo:" URI to identify
> geographic locations

Hi, I don't quite get the idea of this scheme, what's the resource ?

Or in other words, what's wrong with "URIs" like string:foo or
number:4, where I could "query" the string length with a "string
length service", or the smallest divisor of the number, etc. ? 

I like ideas in the direction of <http://geourl.org>, various map
services, or DC locations.  It would be nice to have a "common" way
to express geo locations in Web documents.  But I'm not convinced
that an URI scheme is the way to go.

Apart from that fundamental issue I found no problems in your I-D.

Frank

---

From: Alexander Mayrhofer <[email-masked]>
Date: Fri, 02 Mar 2007 11:59:33 +0100

Hi,

Frank, thanks for taking the time to review this. comments inline.

> Hi, I don't quite get the idea of this scheme, what's the resource ?

The URI scheme identifies a geographic location - so the resource is a place
on (above/below) earth.

> length service", or the smallest divisor of the number, etc. ? 

Ok, i get your point. 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.

Consider calculating the spatial distance between two geo: URIs. That would
not work with, let's say - a "data:" URI, because the semantics are not
defined (Note to myself: add "distance calculation" to the draft?)

However, i read that we should work more on the semantics of the scheme,
because it does not seem to be clear in the first place. Point taken :)

> that an URI scheme is the way to go.

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

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.
Some of them are human readable.

A URI goes _beyond_ the use in a web page.

A URI could be used in a lot of protocols, would provide a common view on
what reference system is to be used, and could be "transformed" between
different applications easily.

It would also allow the user to decide what to do with the information,
based on the context (applications would have to make clear the semantics of
a context, of course..). Other URI schemes have different meanings in
different contexts too, like "http:" can address a web page, identify an XML
namespace, or provide an identity by itself (openid...).

Also, geographic information is becoming more and more important, and
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.

I am well aware that the intended "keep it simple" approach does not work
for certain very specific applications, but i tend to use the 80/20 rule here...

> Apart from that fundamental issue I found no problems in your I-D.

again, thanks for reviewing. I'm happy to discuss those issues in Prague, if
you're there, too.

Alex

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 02 Mar 2007 16:43:06 +0100

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

Say you make a application/geo type with the same syntax and semantics
as the proposed scheme. Then it seems you can just do that using e.g.

  data:application/geo,... <-> data:application/geo,...

Other than the additional level of indirection I can see no difference.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 02 Mar 2007 19:32:42 +0100

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

---

From: Martin Duerst <[email-masked]>
Date: Sat, 03 Mar 2007 16:57:07 +0900

Hello Alex,

Some comments:

The query part is heavily underspecified. A particular concern
is internationalization. You should say that any textual data
has to be encoded using UTF-8 and %-encoding, in order to work
well with IRIs (RFC 3987).

Also, you say that the query component is specified in secion
3.4 of RFC 3986, and later assume a key/value syntax, but RFC
3986 does not define such syntax. You have to either specify
it yourself (preferably using ';' as a separator rather than '&'),
or not use it.

In 4.7., Interopability Considerations, you say:
authors of 'geo' URIs SHOULD only use well known parameters
in the 'query' component, but you give no clues at all how
such 'well known' parameters will be defined.

The site at http://geouri.org/ (in the entry
Firefox extension handles “geo:” URI) provides some good arguments
for your proposal; it may make sense to include some of the points in
the draft (clearly separated from the normative provisions).
I suggest reducing Section 6.1 (typing bits and pieces from
an URI into an application is definitely NOT what URIs are
for) and expanding Section 6.2 a bit.

In the security section, I don't really see the point of
section 8.3., Malicious Locations. How would a browser
validate and protect a geo: URI? Would that mean that geo:
URIs sohuld only be used over https, not http? What's the
difference to any other kind of link that might be wrong?

In 4.4.2, I would word the second paragraph with MAY, rather
than MUST, because some applications may consider geo: URIs
equal for their purposes even e.g. if altitude doesn't match
(simply consider a map application).

It would also be nice if you could give some RDF/Semantic
Web example.

Regards,     Martin.

>http://www.ietf.org/internet-drafts/draft-mayrhofer-geo-uri-00.txt

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 05 Mar 2007 04:49:12 +0100

>it yourself (preferably using ';' as a separator rather than '&'),

A reference to the application/www-form-urlencoded format specification
<http://www.ietf.org/internet-drafts/draft-hoehrmann-urlencoded-00.txt>
would presumably resolve all three issues.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/