<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>The &quot;geo:&quot; URI scheme</title>
	<atom:link href="https://geouri.org/feed/" rel="self" type="application/rss+xml" />
	<link>https://geouri.org</link>
	<description>a Uniform Resource Identifier for geographic locations</description>
	<lastBuildDate>Wed, 18 Jul 2012 06:45:42 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>https://wordpress.org/?v=4.7.23</generator>
	<item>
		<title>Midori web browser supports &#8220;geo:&#8221; URIs</title>
		<link>https://geouri.org/2012/07/16/midori-web-browser-supports-geo-uris/</link>
		<comments>https://geouri.org/2012/07/16/midori-web-browser-supports-geo-uris/#respond</comments>
		<pubDate>Mon, 16 Jul 2012 08:54:26 +0000</pubDate>
		<dc:creator><![CDATA[alex]]></dc:creator>
				<category><![CDATA[Applications]]></category>
<category>applications</category>
		<guid isPermaLink="false">http://geouri.org/?p=78</guid>
		<description><![CDATA[The lightweight &#8220;Midori&#8221; web browser supports &#8220;geo:&#8221; URIs natively since version 0.3.6. Here&#8217;s the respective release announcement (from May 2011, only discovered now): http://mail.xfce.org/pipermail/xfce/2011-May/028718.html The browser extracts latitude and longitude from a geo: URI entered or clicked on, and redirects the user to the respective location on OpenStreetMap. Very cool.]]></description>
				<content:encoded><![CDATA[<p>The lightweight <a href="http://twotoasts.de/index.php/midori/">&#8220;Midori&#8221; web browser</a> supports &#8220;geo:&#8221; URIs natively since version 0.3.6. Here&#8217;s the respective release announcement (from May 2011, only discovered now):</p>
<p><a href="http://mail.xfce.org/pipermail/xfce/2011-May/028718.html">http://mail.xfce.org/pipermail/xfce/2011-May/028718.html</a></p>
<p>The browser extracts latitude and longitude from a geo: URI entered or clicked on, and redirects the user to the respective location on <a href="http://www.openstreetmap.org">OpenStreetMap</a>.</p>
<p>Very cool.</p>
]]></content:encoded>
			<wfw:commentRss>https://geouri.org/2012/07/16/midori-web-browser-supports-geo-uris/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>GeoSMS &#8211; &#8220;geo:&#8221; URIs in mobile short messages</title>
		<link>https://geouri.org/2010/10/06/geosms-geo-uris-in-mobile-short-messages/</link>
		<comments>https://geouri.org/2010/10/06/geosms-geo-uris-in-mobile-short-messages/#comments</comments>
		<pubDate>Wed, 06 Oct 2010 19:38:20 +0000</pubDate>
		<dc:creator><![CDATA[alex]]></dc:creator>
				<category><![CDATA[Applications]]></category>

		<guid isPermaLink="false">http://geouri.org/?p=68</guid>
		<description><![CDATA[An initiative called &#8220;GeoSMS&#8221; proposes the use of &#8220;geo:&#8221; URIs in text messages (mobile short messages &#8211; SMS). This was actually a use case that i discussed with several IETF fellows during the development of the geo: URI specification &#8211; i&#8217;m happy that someone took the effort to write a formal specification. The proposal got [&#8230;]]]></description>
				<content:encoded><![CDATA[<p>An initiative called &#8220;<a title="GeoSMS - &quot;geo:&quot; URI in short messages" href="http://geosms.wordpress.com/">GeoSMS</a>&#8221; proposes the use of &#8220;geo:&#8221; URIs in text messages (mobile short messages &#8211; SMS). This was actually a use case that i discussed with several IETF fellows during the development of the geo: URI specification &#8211; i&#8217;m happy that someone took the effort to write a formal specification.</p>
<p>The proposal got an amazing amount of press coverage, including articles onÂ  <a title="GeoURI / GeoSMS on New York Times" href="http://www.nytimes.com/external/readwriteweb/2010/10/01/01readwriteweb-researchers-develop-location-enabled-sms-st-43195.html">New York Times</a>, <a title="der Standard (german)" href="http://derstandard.at/1285200120961/Geodaten-in-SMS-verpackt">der Standard</a> (german), <a href="http://timesofindia.indiatimes.com/tech/personal-tech/computing/Now-geotag-SMS-to-help-friends-locate-you/articleshow/6664495.cms">Times of India</a>, <a href="http://www.intomobile.com/2010/10/04/geosms-standard/">intomobile</a> and various other news sites in the mobile and tech industry.</p>
<p>It&#8217;s nice to see how the design properties of the &#8220;geo:&#8221; URI (short, simple, human-readable) are the base for another simple and straightforward standard proposal. Let&#8217;s hope that mobile phone developers implement GeoSMS (and, hence &#8220;geo:&#8221; URIs) in their future products. The GeoSMS developers themselves have already created an Android application called &#8220;I am Here&#8221;. More details and the actual specification are available here:</p>
<p><a title="GeoSMS standard proposal" href="http://geosms.wordpress.com/">GeoSMS</a> &#8211; &#8220;geo:&#8221; URIs in text messages</p>
<p><a href="http://tools.ietf.org/rfc/rfc5870">RFC5870</a> &#8211; the &#8220;geo:&#8221; URI specification</p>
]]></content:encoded>
			<wfw:commentRss>https://geouri.org/2010/10/06/geosms-geo-uris-in-mobile-short-messages/feed/</wfw:commentRss>
		<slash:comments>5</slash:comments>
		</item>
		<item>
		<title>&#8220;geo:&#8221; and SIP Location Conveyance</title>
		<link>https://geouri.org/2010/08/06/geo-and-sip-location-conveyance/</link>
		<comments>https://geouri.org/2010/08/06/geo-and-sip-location-conveyance/#comments</comments>
		<pubDate>Fri, 06 Aug 2010 08:25:21 +0000</pubDate>
		<dc:creator><![CDATA[alex]]></dc:creator>
				<category><![CDATA[Applications]]></category>

		<guid isPermaLink="false">http://geouri.org/?p=61</guid>
		<description><![CDATA[&#8220;geo:&#8221; is getting more attention in other areas of the Internet Engineering Task Force. After the VCARDDAV working group has included &#8220;geo:&#8221; URIs in their revision of the vCard scheme, the SIPCORE working group is now discussing the use of &#8220;geo:&#8221; in their &#8220;Location Conveyance&#8221; draft. SIP is the IETF&#8217;s protocol for establishing Realtime Application [&#8230;]]]></description>
				<content:encoded><![CDATA[<p>&#8220;geo:&#8221; is getting more attention in other areas of the Internet Engineering Task Force. After the <a href="http://tools.ietf.org/wg/vcarddav">VCARDDAV </a>working group has <a href="http://geouri.org/2010/06/10/geo-and-vcards/">included &#8220;geo:&#8221; URIs</a> in their revision of the vCard scheme, the <a href="http://tools.ietf.org/wg/sipcore">SIPCORE </a>working group is now discussing the use of &#8220;geo:&#8221; in their <a href="http://tools.ietf.org/html/draft-ietf-sip-location-conveyance">&#8220;Location Conveyance&#8221;</a> draft.</p>
<p><strong>SIP </strong>is the IETF&#8217;s protocol for establishing Realtime Application Sessions, and is very commonly used for <strong>Voice over IP</strong>. It has gained massive popularity in recent years, and is not just be used in VoIP-Software, but also in Public Branch Exchanges from various vendors, open source products such as <a href="http://www.ipcom.at/en/telephony/asterisk/">Asterisk</a>, <a href="http://www.ipcom.at/en/telephony/kamailio_sip_proxy/">Kamailio</a> and a wide range of carrier products. SIP is <em>the</em> base for telephoney in the upcoming Next Generation networks such as LTE, and a major component of IMS systems. A good percentage of phone calls being routed between carriers as of today already uses SIP.</p>
<p>For those reasons, the IETF is looking into ways to <strong>embed location information</strong> into SIP messages. This is important for services such as Emergency Services, but can of course be used for any other realtime application that needs to transmit location information in its session setup. An example of that could be location conveyance between contacts in a social network, or applications for &#8220;checking in&#8221;, such as <a href="http://www.gowalla.com">Gowalla </a>and <a href="http://www.foursquare.com">Foursquare</a>.</p>
<p>The current version of the <a href="http://tools.ietf.org/html/draft-ietf-sip-location-conveyance">SIP Location Conveyance Specification</a> uses &#8220;Content ID&#8221; URIs (besides &#8220;sip&#8221;/&#8221;sips&#8221;/&#8221;pres&#8221;) to refer from the new &#8220;<strong>Geolocation:</strong>&#8221; header to a MIME body part, which then contains the location embedded in a <a href="http://tools.ietf.org/rfc/rfc4119">PIDF-LO</a> Presence/Location document. Such a geolocation header (and respective body part) would look like this:</p>
<pre style="padding-left: 30px;">
<pre>Geolocation: &lt;cid:target123@atlanta.example.com&gt;
     ;inserted-by="alice@atlanta.example.com"

   --boundary1

   &lt;?xml version="1.0" encoding="UTF-8"?&gt;
      &lt;presence xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
          xmlns:gml="http://www.opengis.net/gml"
          entity="pres:alice@atlanta.example.com"&gt;
        &lt;dm:device id="point2d"&gt;
         &lt;timestamp&gt;2007-12-02T14:00:00Z&lt;/timestamp&gt;
</pre>
<pre>
         &lt;status&gt;
          &lt;gp:geopriv&gt;
            &lt;gp:location-info&gt;
              &lt;gml:location&gt;
                &lt;gml:Point srsName="urn:ogc:def:crs:EPSG::4326"&gt;
                  &lt;gml:pos&gt;33.001111 -96.68142&lt;/gml:pos&gt;
                &lt;/gml:Point&gt;
               &lt;/gml:location&gt;
            &lt;/gp:location-info&gt;
            &lt;gp:usage-rules&gt;
              &lt;gp:retransmission-allowed&gt;no&lt;/gp:retransmission-allowed&gt;
              &lt;gp:retention-expiry&gt;2007-12-07T18:00:00Z&lt;/gp:retention-
                            expiry&gt;
            &lt;/gp:usage-rules&gt;
            &lt;gp:method&gt;DHCP&lt;/gp:method&gt;
            &lt;gp:provided-by&gt;www.example.com&lt;/gp:provided-by&gt;
          &lt;/gp:geopriv&gt;
         &lt;/status&gt;
        &lt;/dm:device&gt;
      &lt;/presence&gt;
   --boundary1--
</pre>
<p>PIDF-LO allows for great flexibility of location types, can contain civic addresses, and extensive privacy rules. However, conveyance of a simple &#8220;point&#8221; type location could also be achieved by using the &#8220;geo:&#8221; URI in the Geolocation header directly as follows:</p>
<pre style="padding-left: 60px;">Geolocation: &lt;geo:33.001111,-96.68142&gt;
</pre>
<p>Which, obviously, would be much more compact, probably easier to parse, and not in the need of a seperate MIME body part.</p>
<p>However, the &#8220;geo:&#8221; URI specifically lacks privacy rules, because an URI itself does not identify a Target, but rather reflects just a physical location in space. In SIP Location Conveyance as a &#8220;GEOPRIV Using Protocol&#8221;, privacy is required.</p>
<p>There is currently a <a href="http://www.ietf.org/mail-archive/web/sipcore/current/msg03091.html">discussion </a>going on the SIPCORE mailing list, and the <a href="http://www.ietf.org/mail-archive/web/sipcore/current/msg03099.html">proposal</a> is that a &#8220;geo:&#8221; URI (when used in an &#8220;Geolocation&#8221; SIP header) would come with implicit default rules (currently under discussion whether those default rules would be GEOPRIV&#8217;s general default rules, or defaults specific to the use of &#8220;geo:&#8221; in the context of the &#8220;Geolocation:&#8221; header).</p>
<p>We&#8217;ll keep watching the discussion.</p>
]]></content:encoded>
			<wfw:commentRss>https://geouri.org/2010/08/06/geo-and-sip-location-conveyance/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>&#8220;geo:&#8221; and vCards</title>
		<link>https://geouri.org/2010/06/10/geo-and-vcards/</link>
		<comments>https://geouri.org/2010/06/10/geo-and-vcards/#comments</comments>
		<pubDate>Thu, 10 Jun 2010 09:13:28 +0000</pubDate>
		<dc:creator><![CDATA[alex]]></dc:creator>
				<category><![CDATA[Applications]]></category>

		<guid isPermaLink="false">http://geouri.org/?p=42</guid>
		<description><![CDATA[vCard &#8211; the first spec to use &#8220;geo:&#8221;? The first specification that is using the &#8220;geo:&#8221; scheme seems to be the revision of the vCard format. vCards are &#8220;virtual business cards&#8221;, and contain a multitude of contact information about a person or an organization. vCard GEO property The geographic location of a person&#8217;s office is [&#8230;]]]></description>
				<content:encoded><![CDATA[<p><strong>vCard &#8211; the first spec to use &#8220;geo:&#8221;?</strong></p>
<p>The first specification that is using the &#8220;geo:&#8221; scheme seems to be the <a title="IETF vCard Revision Draft" href="http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev">revision of the vCard format</a>. vCards are &#8220;virtual business cards&#8221;, and contain a multitude of contact information about a person or an organization.</p>
<p><strong>vCard GEO property</strong></p>
<p>The geographic location of a person&#8217;s office is of course one of those properties &#8211; even the original specification of vCard (<a title="RFC 2426 - vCard" href="http://tools.ietf.org/html/rfc2426">RFC 2426</a>) contained an &#8220;GEO&#8221; property (defined in <a title="GEO property of vCard" href="http://tools.ietf.org/html/rfc2426#section-3.4.2">Section 3.4.2</a>). That property has a range of shortcomings:</p>
<ul>
<li>There&#8217;s no way to specify altitude</li>
<li>the Coordinate Reference System is not defined (see <a title="Wrong datum - Why you should care.." href="http://www.gichd.org/fileadmin/pdf/IMSMA/fact-sheets/GICHDFactSheet3-Datums-WhyYouShouldCare-July07.pdf">here</a> [PDF] why you should care)</li>
<li>Recommends to always use six decimal places (roughly one meter) rather than allowing for uncertainty values</li>
</ul>
<p><strong>New revision of vCard includes &#8220;geo:&#8221; URI</strong></p>
<p>The current revision of the vCard specification (currently worked on in the IETF&#8217;s <a href="http://datatracker.ietf.org/wg/vcarddav/charter/">VCARDDAV working group</a>) has changed the format of the &#8220;GEO&#8221; property. The <a title="revised vCard GEO property definition" href="http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-6.5.2">new definition</a> requires a URI rather than the lat/lon tupel as value, and notes in an example that the &#8220;geo:&#8221; URI scheme is &#8220;particularly well-suited&#8221;, although other URI schemes are allowed too. A example vCard using the &#8220;geo:&#8221; URI looks like this (edited for brevity):</p>
<blockquote>
<pre>BEGIN:VCARD
VERSION:4.0
FN:Simon Perreault
...
<strong>GEO;TYPE=work:geo:46.772673,-71.282945</strong>
...
CLASS:PUBLIC
END:VCARD
</pre>
</blockquote>
<p>As outlined above, the structure of vCards allows to supply parameters for properties &#8211; in the example above, the GEO property is specified for the &#8220;work&#8221; location of the contact.</p>
<p><strong>vCard applications become geo: aware</strong></p>
<p>The integration of the URI scheme into the very popular vCard format means that very likely future revisions of vCard applications will be able to parse and use &#8220;geo:&#8221; URIs. Looking at the <a title="vCard applications" href="http://microformats.org/wiki/vcard-implementations">list of applications</a> that support vCards, it looks like a bright future for our newly-born URI scheme.</p>
]]></content:encoded>
			<wfw:commentRss>https://geouri.org/2010/06/10/geo-and-vcards/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>RFC 5870: &#8220;A Uniform Resource Identifier for Geographic Locations&#8221;</title>
		<link>https://geouri.org/2010/06/07/rfc-5870-geo-uri/</link>
		<comments>https://geouri.org/2010/06/07/rfc-5870-geo-uri/#comments</comments>
		<pubDate>Mon, 07 Jun 2010 07:24:34 +0000</pubDate>
		<dc:creator><![CDATA[alex]]></dc:creator>
				<category><![CDATA[Drafting]]></category>

		<guid isPermaLink="false">http://geouri.org/?p=29</guid>
		<description><![CDATA[It&#8217;s Done. RFC 5870 (&#8220;A Uniform Resource Identifier for Geographic Locations&#8221;) has finally been published by the Internet Engineering Task Force as &#8220;Proposed Standard&#8221;. The RFC contains the final, stable and approved IETF specification of the &#8220;geo&#8221; URI scheme &#8211; the 23 pages document is the result of 3 years of hard work, several presentations [&#8230;]]]></description>
				<content:encoded><![CDATA[<p><strong><em>It&#8217;s </em></strong><em><strong>Done.</strong><br />
</em></p>
<p><a title="RFC 5870 - the &quot;geo&quot; URI scheme" href="http://tools.ietf.org/html/rfc5870">RFC 5870</a> (&#8220;A Uniform Resource Identifier for Geographic Locations&#8221;) has finally been published by the Internet Engineering Task Force as &#8220;Proposed Standard&#8221;. The RFC contains the final, stable and approved IETF specification of the &#8220;geo&#8221; URI scheme &#8211; the 23 pages <a title="The &quot;geo&quot; URI" href="http://tools.ietf.org/html/rfc5870">document</a> is the result of 3 years of hard work, several presentations at IETF meetings, hundreds of email conversations about protocol details, discussing the proposal again and again, and &#8211; finally &#8211; interacting with not just one, but two sets of Area Directors in the IESG (Approval was perfectly timed with the end of the term of several Area Directors, so it had to be reviewed by the incoming IESG members as well).</p>
<p>Now that the &#8220;blueprint&#8221; part of the URI scheme is done, we&#8217;re looking forward to applications actually using the &#8220;geo&#8221; scheme (besides the <a title="&quot;geo&quot; URI applications" href="/applications/">ones we know of already</a>). The URI scheme will also very likely see adoption in other IETF documents. If you know of an application that you think should support the &#8220;geo&#8221; URI scheme &#8211; let us know.</p>
]]></content:encoded>
			<wfw:commentRss>https://geouri.org/2010/06/07/rfc-5870-geo-uri/feed/</wfw:commentRss>
		<slash:comments>5</slash:comments>
		</item>
		<item>
		<title>&#8220;geo:&#8221; Specification is Approved in the IETF</title>
		<link>https://geouri.org/2010/04/19/geo-specification-is-approved-in-the-ietf/</link>
		<comments>https://geouri.org/2010/04/19/geo-specification-is-approved-in-the-ietf/#comments</comments>
		<pubDate>Mon, 19 Apr 2010 20:17:22 +0000</pubDate>
		<dc:creator><![CDATA[alex]]></dc:creator>
				<category><![CDATA[Drafting]]></category>

		<guid isPermaLink="false">http://geouri.org/?p=16</guid>
		<description><![CDATA[Great news for the standardization of the &#8220;geo:&#8221; URI scheme: After three years of hard work, the Internet Draft describing the URI scheme was approved by the IESG on April 16th 2010. This means that the most important hurdle for &#8220;geo:&#8221; to become a (Proposed Standard) RFC has been taken. It will take another 3 [&#8230;]]]></description>
				<content:encoded><![CDATA[<p>Great news for the standardization of the &#8220;geo:&#8221; URI scheme: After three years of hard work, the <a title="A Uniform Resource Identifier for Geographic Locations ('geo' URI)" href="http://tools.ietf.org/html/draft-ietf-geopriv-geo-uri-07">Internet Draft describing the URI scheme</a> was approved by the IESG on April 16th 2010. This means that the most important hurdle for &#8220;geo:&#8221; to become a (Proposed Standard) <a title="RFC description on Wikipedia" href="http://en.wikipedia.org/wiki/Request_for_Comments">RFC</a> has been taken.</p>
<p>It will take another 3 &#8211; 4 months for the document to be edited and a final RFC number to be assigned. But with the approval of the document, the current specification is stable, and can be used as a draft reference for implementations</p>
<p>There are currently two implementations of the &#8220;geo:&#8221; URI scheme out:</p>
<ul>
<li>Andy Armstrong has written a <a title="URI::geo Perl Module" href="http://geouri.org/2009/04/28/perl-module-urigeo/" target="_self">&#8220;geo:&#8221; Perl Module</a> available through <a title="URI::geo on CPAN" href="http://search.cpan.org/~andya/URI-geo/">CPAN</a>.</li>
<li>The mobile Operating System &#8220;Android&#8221; contains support for the &#8220;geo:&#8221; URI out of the box (<a title="Android " href="http://developer.android.com/guide/appendix/g-app-intents.html">API Documentation</a>) &#8211; unfortunately it&#8217;s not fully compliant to the latest specs. However, this is particularly exciting because it&#8217;s out there in millions of devices.</li>
</ul>
<p>The specification is also already being used in other IETF work: For example, the updated <a title="vCard Specification Update" href="http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev">vCard Specification</a> recommends to use &#8220;geo:&#8221; URIs for the GEO property of vCards, and i&#8217;m sure we&#8217;ll be seeing &#8220;geo&#8221; URIs pop up in other specifications as well!</p>
]]></content:encoded>
			<wfw:commentRss>https://geouri.org/2010/04/19/geo-specification-is-approved-in-the-ietf/feed/</wfw:commentRss>
		<slash:comments>5</slash:comments>
		</item>
		<item>
		<title>Perl module URI::geo</title>
		<link>https://geouri.org/2009/04/28/perl-module-urigeo/</link>
		<comments>https://geouri.org/2009/04/28/perl-module-urigeo/#respond</comments>
		<pubDate>Tue, 28 Apr 2009 09:49:37 +0000</pubDate>
		<dc:creator><![CDATA[alex]]></dc:creator>
				<category><![CDATA[Applications]]></category>

		<guid isPermaLink="false">http://geouri.org/2009/04/28/perl-module-urigeo/</guid>
		<description><![CDATA[Andy Armstrong of hexten has created yet another implementation of the &#8220;geo&#8221; URI scheme &#8211; this time it&#8217;s CPAN module for all the Perl fans out there: URI::geo provides a class to create and parse &#8220;geo&#8221; URIs from within Perl scripts &#8211; a simple example to create a URI from latitude and longitude information looks [&#8230;]]]></description>
				<content:encoded><![CDATA[<p>Andy Armstrong of <a href="http://www.hexten.com/">hexten</a> has created yet another implementation of the &#8220;geo&#8221; URI scheme &#8211; this time it&#8217;s CPAN module for all the Perl fans out there: <a href="http://search.cpan.org/~andya/URI-geo/">URI::geo</a> provides a class to create and parse &#8220;geo&#8221; URIs from within Perl scripts &#8211; a simple example to create a URI from latitude and longitude information looks like this:</p>
<pre>use URI::geo;</pre>
<pre>my $guri = URI::geo->new( { lat => 55, lon => -1 } );</pre>
<p>The current module version 0.0.4 is available from CPAN <a href="http://search.cpan.org/CPAN/authors/id/A/AN/ANDYA/URI-geo-0.04.tar.gz">here</a>, API documentation can be found <a href="http://search.cpan.org/~andya/URI-geo/lib/URI/geo.pm">here</a>.</p>
<p>Andy, thanks for implementing and getting the module into CPAN!</p>
]]></content:encoded>
			<wfw:commentRss>https://geouri.org/2009/04/28/perl-module-urigeo/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Android implements &#8220;geo&#8221; URI, IETF accepts draft specification</title>
		<link>https://geouri.org/2009/04/02/android-implements-geo-uri-ietf-accepts-draft-specification/</link>
		<comments>https://geouri.org/2009/04/02/android-implements-geo-uri-ietf-accepts-draft-specification/#respond</comments>
		<pubDate>Thu, 02 Apr 2009 14:58:34 +0000</pubDate>
		<dc:creator><![CDATA[alex]]></dc:creator>
				<category><![CDATA[Applications]]></category>
		<category><![CDATA[Drafting]]></category>

		<guid isPermaLink="false">http://geouri.org/2009/04/02/android-implements-geo-uri-ietf-accepts-draft-specification/</guid>
		<description><![CDATA[A new version of the &#8220;geo&#8221; URI specification was discussed at the IETF&#8217;s 74th meeting in San Francisco. As more and more applications pop up around the internet, the GEOPRIV working group recognized that there is definitely a need for a simple, short, but yet standardized way to refer to a spatial location. Following the [&#8230;]]]></description>
				<content:encoded><![CDATA[<p>A new version of the <a title="draft-mayrhofer-geopriv-geo-uri" href="http://tools.ietf.org/html/draft-mayrhofer-geopriv-geo-uri-01">&#8220;geo&#8221; URI specification</a> was discussed at the IETF&#8217;s 74th meeting in San Francisco. As more and more applications pop up around the internet, the <a href="http://www.ietf.org/html.charters/geopriv-charter.html">GEOPRIV working group</a> recognized that there is definitely a need for a simple, short, but yet standardized way to refer to a spatial location.</p>
<p>Following the 20 minute <a href="http://www.ietf.org/proceedings/09mar/slides/geopriv-3.pdf">presentation</a> of the new draft version (which primarily incorporated some clarifications regarding WGS84, and the semantics of coordinates reflecting the poles), the working group was asked whether it would want to accept the &#8220;geo&#8221; URI draft as an official working group item.</p>
<p>The draft was accepted with overwhelming concensus, and will soon be renamed to reflect the working group adoption. That also means we&#8217;re a big step closer towards publication of the document as a draft standard RFC.<br />
In other news, an esteemed colleage of mine discovered that Google&#8217;s mobile operating system <a href="http://www.android.com/">&#8220;Android&#8221;</a> already supports the &#8220;geo&#8221; URI! So anybody who happens to use such a phone (or has installed the emulator) can already make use of web pages containing &#8220;geo&#8221; URIs &#8211; once they are clicked, the phone starts the mapping application, and pans to the location indicated in the URI.</p>
<p>This is the first wide-spread implementation we&#8217;re aware of &#8211; see the relevant <a href="http://developer.android.com/guide/appendix/g-app-intents.html">API documentation page</a>. We&#8217;re quite excited, and looking forward to more platforms containing early implementations of the URI scheme.</p>
]]></content:encoded>
			<wfw:commentRss>https://geouri.org/2009/04/02/android-implements-geo-uri-ietf-accepts-draft-specification/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Internet Draft updated to version 01</title>
		<link>https://geouri.org/2007/07/06/internet-draft-updated-to-version-01/</link>
		<comments>https://geouri.org/2007/07/06/internet-draft-updated-to-version-01/#respond</comments>
		<pubDate>Fri, 06 Jul 2007 08:38:56 +0000</pubDate>
		<dc:creator><![CDATA[alex]]></dc:creator>
				<category><![CDATA[Drafting]]></category>
<category>ietf</category><category>internet draft</category><category>standardization</category>
		<guid isPermaLink="false">http://geouri.org/2007/07/06/internet-draft-updated-to-version-01/</guid>
		<description><![CDATA[The Internet Draft specifying the &#8220;geo:&#8221; URI has been updated, the new version is already available from the IETF draft archives. The new version 01 (which is the second version after 00) removes the &#8220;query&#8221; part of the URI, as this was pretty much underspecified in the initial version, and has proven to be rather [&#8230;]]]></description>
				<content:encoded><![CDATA[<p>The <a href="http://www.ietf.org/internet-drafts/draft-mayrhofer-geo-uri-01.txt">Internet Draft specifying the &#8220;geo:&#8221; URI</a> has been updated, the new version is already available from the <a href="http://tools.ietf.org/html/draft-mayrhofer-geo-uri-01">IETF draft archives</a>.</p>
<p>The new version 01 (which is the second version after 00) removes the &#8220;query&#8221; part of the URI, as this was pretty much underspecified in the initial version, and has proven to be rather controversial. Since it does not actually identify the spatial location, but provides meta information (like location classification &#038; type, preferred map scale) we decided to remove it from the specification.</p>
<p>Please note that this is work in progress, which also means that any feedback is appreciated.</p>
]]></content:encoded>
			<wfw:commentRss>https://geouri.org/2007/07/06/internet-draft-updated-to-version-01/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Presentation at IETF 68, Prague</title>
		<link>https://geouri.org/2007/03/21/presentation-at-ietf-68-prague/</link>
		<comments>https://geouri.org/2007/03/21/presentation-at-ietf-68-prague/#respond</comments>
		<pubDate>Wed, 21 Mar 2007 14:53:19 +0000</pubDate>
		<dc:creator><![CDATA[alex]]></dc:creator>
				<category><![CDATA[Drafting]]></category>
<category>geo</category><category>geouri</category><category>ietf</category><category>ietf68</category><category>presentation</category>
		<guid isPermaLink="false">http://geouri.org/2007/03/21/presentation-at-ietf-68-prague/</guid>
		<description><![CDATA[The Internet Engineering Task Force is currently hosting it&#8217;s 68th meeting in the Hilton Hotel, Prague, Czech Republic. The geo: URI proposal is on the agenda of tomorrows session of the Geographic Location/Privacy working group: GEOPRIV WG meeting March 22, 2007, 9:00 &#8211; 11:30 IETF 68, Hilton Hotel Prague, Room &#8220;Congress I&#8221; According to the [&#8230;]]]></description>
				<content:encoded><![CDATA[<p><a href="http://geouri.org/wp-content/uploads/2007/03/geo-uri-ietf68.pdf"><img align="right" id="image11" alt="IETF68 slides" src="http://geouri.org/wp-content/uploads/2007/03/ietf-slides.png" /></a>The <a href="http://www.ietf.org/">Internet Engineering Task Force</a> is currently hosting it&#8217;s 68th meeting in the <a href="http://geouri.org/geo:50.09318,14.43892,203">Hilton Hotel, Prague, Czech Republic</a>.</p>
<p>The <a href="/2007/02/24/internet-draft-about-geo-uri-published/">geo: URI proposal</a> is on the agenda of tomorrows session of the <a href="http://www.ietf.org/html.charters/geopriv-charter.html">Geographic Location/Privacy working group</a>:</p>
<ul>
<li><strong>GEOPRIV WG meeting</strong></li>
<li>March 22, 2007, 9:00 &#8211; 11:30</li>
<li>IETF 68, Hilton Hotel Prague, Room &#8220;Congress I&#8221;</li>
</ul>
<p>According to the <a href="http://www3.ietf.org/proceedings/07mar/agenda/geopriv.txt">agenda</a>, the presentation of the &#8220;geo&#8221; URI scheme is scheduled for about <strong>10:55</strong>.</p>
<p>For remote participation, session audio will be available via the <a href="http://videolab.uoregon.edu/events/ietf/ietf68.html">IETF audio streaming effort</a> (Channel 1), a supplemental Jabber discussion room at <a href="http://geouri.org/xmpp:geopriv@jabber.ietf.org">geopriv@jabber.ietf.org</a> can be used as a backchannel for remote participants to ask questions and provide feedback.</p>
<p><a id="p12" href="http://geouri.org/wp-content/uploads/2007/03/geo-uri-ietf68.pdf">Slides of the presentation</a></p>
]]></content:encoded>
			<wfw:commentRss>https://geouri.org/2007/03/21/presentation-at-ietf-68-prague/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
