headers
Alexander Mayrhofer | 1 Mar 14:58
Favicon

early draft of a "geo:" URI scheme.

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.
(Continue reading)

Permalink | Reply |
headers
Frank Ellermann | 1 Mar 18:54

Re: early draft of a "geo:" URI scheme.

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
Permalink | Reply |
headers
Alexander Mayrhofer | 2 Mar 11:59
Favicon

Re: Re: early draft of a "geo:" URI scheme.

Hi,

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

Frank Ellermann 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 ?

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

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

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

> I like ideas in the direction of <http://geourl.org>, various map
(Continue reading)

Permalink | Reply |
headers
Bjoern Hoehrmann | 2 Mar 16:43

Re: Re: early draft of a "geo:" URI scheme.

* Alexander Mayrhofer wrote:
>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?)

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:bjoern <at> hoehrmann.de · 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/
Permalink | Reply |
headers
Frank Ellermann | 2 Mar 19:32

Re: early draft of a "geo:" URI scheme.

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
(Continue reading)

Permalink | Reply |
headers
Martin Duerst | 3 Mar 08:57

Re: early draft of a "geo:" URI scheme.

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
(Continue reading)

Permalink | Reply |
headers
Bjoern Hoehrmann | 5 Mar 04:49

Re: early draft of a "geo:" URI scheme.

* Martin Duerst wrote:
>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.

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:bjoern <at> hoehrmann.de · 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/
Permalink | Reply |

Gmane