draft-ietf-geopriv-geo-uri-05.txt   draft-ietf-geopriv-geo-uri-06.txt 
GEOPRIV -- Geographic A. Mayrhofer GEOPRIV -- Geographic A. Mayrhofer
Location/Privacy Working Group IPCom Location/Privacy Working Group IPCom
Internet-Draft C. Spanring Internet-Draft C. Spanring
Expires: September 7, 2010 March 06, 2010 Intended status: Standards Track April 09, 2010
Expires: October 11, 2010
A Uniform Resource Identifier for Geographic Locations ('geo' URI) A Uniform Resource Identifier for Geographic Locations ('geo' URI)
draft-ietf-geopriv-geo-uri-05 draft-ietf-geopriv-geo-uri-06
Abstract Abstract
This document specifies a Uniform Resource Identifier (URI) for This document specifies a Uniform Resource Identifier (URI) for
geographic locations using the 'geo' scheme name. A 'geo' URI geographic locations using the 'geo' scheme name. A 'geo' URI
identifies a physical location in a two- or three-dimensional identifies a physical location in a two- or three-dimensional
coordinate reference system in a compact, simple, human-readable, and coordinate reference system in a compact, simple, human-readable, and
protocol-independent way. The default coordinate reference system protocol-independent way. The default coordinate reference system
used is WGS-84. used is WGS-84.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on October 11, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 7, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
skipping to change at page 3, line 20 skipping to change at page 2, line 34
3. IANA Registration of 'geo' URI Scheme . . . . . . . . . . . . 6 3. IANA Registration of 'geo' URI Scheme . . . . . . . . . . . . 6
3.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 6 3.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 6
3.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 6 3.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 6
3.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 7 3.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 7
3.4.1. Coordinate Reference System Identification . . . . . . 7 3.4.1. Coordinate Reference System Identification . . . . . . 7
3.4.2. Component Description for WGS-84 . . . . . . . . . . . 8 3.4.2. Component Description for WGS-84 . . . . . . . . . . . 8
3.4.3. Location Uncertainty . . . . . . . . . . . . . . . . . 8 3.4.3. Location Uncertainty . . . . . . . . . . . . . . . . . 8
3.4.4. URI Comparison . . . . . . . . . . . . . . . . . . . . 9 3.4.4. URI Comparison . . . . . . . . . . . . . . . . . . . . 9
3.4.5. Interpretation of Undefined Altitude . . . . . . . . . 9 3.4.5. Interpretation of Undefined Altitude . . . . . . . . . 10
3.5. Encoding Considerations . . . . . . . . . . . . . . . . . 9 3.5. Encoding Considerations . . . . . . . . . . . . . . . . . 10
3.6. Applications/Protocols that use this URI Scheme . . . . . 10 3.6. Applications/Protocols that use this URI Scheme . . . . . 10
3.7. Interopability Considerations . . . . . . . . . . . . . . 10 3.7. Interopability Considerations . . . . . . . . . . . . . . 10
3.8. Security Considerations . . . . . . . . . . . . . . . . . 10 3.8. Security Considerations . . . . . . . . . . . . . . . . . 11
3.9. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.9. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.10. Author/Change controller . . . . . . . . . . . . . . . . . 11 3.10. Author/Change controller . . . . . . . . . . . . . . . . . 11
3.11. References . . . . . . . . . . . . . . . . . . . . . . . . 11 3.11. References . . . . . . . . . . . . . . . . . . . . . . . . 11
4. 'geo' URI Parameters Registry . . . . . . . . . . . . . . . . 11 4. 'geo' URI Parameters Registry . . . . . . . . . . . . . . . . 11
5. URI Operations . . . . . . . . . . . . . . . . . . . . . . . . 12 5. URI Operations . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Use Cases and Examples . . . . . . . . . . . . . . . . . . . . 12 6. Use Cases and Examples . . . . . . . . . . . . . . . . . . . . 13
6.1. Plain 'geo' URI Example . . . . . . . . . . . . . . . . . 12 6.1. Plain 'geo' URI Example . . . . . . . . . . . . . . . . . 13
6.2. Hyperlink . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Hyperlink . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3. 'geo' URI in 2-dimensional barcode . . . . . . . . . . . . 13 6.3. 'geo' URI in 2-dimensional barcode . . . . . . . . . . . . 14
6.4. Comparison Examples . . . . . . . . . . . . . . . . . . . 14
7. GML Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. GML Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. 2D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 14 7.1. 2D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 16
7.2. 3D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 14 7.2. 3D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 16
7.3. GML 'Circle' . . . . . . . . . . . . . . . . . . . . . . . 15 7.3. GML 'Circle' . . . . . . . . . . . . . . . . . . . . . . . 16
7.4. GML 'Sphere' . . . . . . . . . . . . . . . . . . . . . . . 15 7.4. GML 'Sphere' . . . . . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8.1. 'geo' URI Scheme . . . . . . . . . . . . . . . . . . . . . 16 8.1. 'geo' URI Scheme . . . . . . . . . . . . . . . . . . . . . 17
8.2. URI Parameter Registry . . . . . . . . . . . . . . . . . . 16 8.2. URI Parameter Registry . . . . . . . . . . . . . . . . . . 18
8.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 16 8.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 18
8.2.2. Registration Policy . . . . . . . . . . . . . . . . . 17 8.2.2. Registration Policy . . . . . . . . . . . . . . . . . 18
8.3. Sub-Registry for 'crs' Parameter . . . . . . . . . . . . . 17 8.3. Sub-Registry for 'crs' Parameter . . . . . . . . . . . . . 18
8.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 17 8.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 19
8.3.2. Registration Policy . . . . . . . . . . . . . . . . . 18 8.3.2. Registration Policy . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9.1. Invalid Locations . . . . . . . . . . . . . . . . . . . . 18 9.1. Invalid Locations . . . . . . . . . . . . . . . . . . . . 19
9.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 18 9.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
An increasing number of Internet protocols and data formats are An increasing number of Internet protocols and data formats are
extended by specifications for adding spatial (geographic) location. extended by specifications for adding spatial (geographic) location.
In most cases, latitude as well as longitude of simple points are In most cases, latitude as well as longitude of simple points are
added as new attributes to existing data structures. However, all added as new attributes to existing data structures. However, all
those methods are very specific to a certain data format or protocol, those methods are very specific to a certain data format or protocol,
and don't provide a protocol-independent, compact and generic way to and don't provide a protocol-independent, compact and generic way to
refer to a physical geographic location. refer to a physical geographic location.
skipping to change at page 10, line 8 skipping to change at page 9, line 8
are never the same thing. are never the same thing.
The single uncertainty value is applied to all dimensions given in The single uncertainty value is applied to all dimensions given in
the URI. the URI.
Note: The number of digits of the values in <coordinates> MUST NOT be Note: The number of digits of the values in <coordinates> MUST NOT be
interpreted as an indication to uncertainty. interpreted as an indication to uncertainty.
3.4.4. URI Comparison 3.4.4. URI Comparison
Two 'geo' URIs are equal when they use the same CRS, and <coord-a>, Two 'geo' URIs are equal only if they fulfill all of the following
<coord-b>, <coord-c> and 'u' value are mathematically identical general comparison rules:
(including absent <uval> meaning undefined 'u' value).
If other parameters are contained in the URIs, the comparison o Both URIs use the same CRS, which means that either both have the
operation MUST be extended as described in the specification of the 'crs' parameter omitted, or both have the same <crslabel> value,
respective parameter. Unknown parameters MUST NOT be ignored. or one has the 'crs' parameter omitted while the other URI
specifies the default CRS explicitely with a <crslabel> value of
"wgs84".
o Their <coord-a>, <coord-b>, <coord-c> and 'u' values are
mathematically identical (including absent <uval> meaning
undefined 'u' value).
o Their sets of other parameters are equal, with comparison
operations applied on each parameter as described in its
respective specification.
Two URIs use the same CRS if both have the 'crs' parameter omitted, Parameter order is not significant for URI comparison.
or both have the same <crslabel>, or one has the 'crs' parameter
omitted while the other URI specifies the default CRS explicitely Since new parameters may be registered over time, legacy
with a <crslabel> value of "wgs84". implementations of the 'geo' URI might encounter unknown parameters.
In such cases, the following rules apply:
o Two 'geo' URIs with unknown parameters are equivalent only if the
same set of unknown parameter names appears in each URI, and their
values are bitwise identical after percent-decoding.
o Otherwise, the comparison operation for the respective URIs is
undefined (since the legacy implementation is not be aware of the
comparison rules for those parameters).
Designers of future extension parameters should take this into
account when choosing the comparison rules for new parameters.
A URI with undefined (missing) <coord-c> (altitude) value MUST NOT be
considered equal to a URI containing a <coord-c>, even if the
remaining <coord-a>, <coord-b>, and their 'u' values are equivalent.
For the default CRS of WGS-84, the following comparison rules apply
additionally:
For the default CRS of WGS-84, the following definitions apply in
addition:
o Where <latitude> of a 'geo' URI is set to either 90 or -90 o Where <latitude> of a 'geo' URI is set to either 90 or -90
degrees, <longitude> MUST be ignored in comparison operations degrees, <longitude> MUST be ignored in comparison operations
("poles case"). ("poles case").
o A <longitude> of 180 degrees MUST be considered equal to o A <longitude> of 180 degrees MUST be considered equal to
<longitude> of -180 degrees for the purpose of URI comparison <longitude> of -180 degrees for the purpose of URI comparison
("date line" case). ("date line" case).
A URI with undefined (missing) <coord-c> (altitude) value MUST NOT be
considered equal to a URI containing a <coord-c>, even if the
remaining <coord-a>, <coord-b>, and their 'u' values are equivalent.
3.4.5. Interpretation of Undefined Altitude 3.4.5. Interpretation of Undefined Altitude
A consumer of a 'geo' URI in the WGS-84 CRS with undefined <altitude> A consumer of a 'geo' URI in the WGS-84 CRS with undefined <altitude>
MAY assume that the URI refers to the respective location on Earth's MAY assume that the URI refers to the respective location on Earth's
physical surface at the given latitude and longitude. physical surface at the given latitude and longitude.
However, as defined above, altitudes are relative to the WGS-84 However, as defined above, altitudes are relative to the WGS-84
reference geoid rather than Earth's surface. Hence, an <altitude> reference geoid rather than Earth's surface. Hence, an <altitude>
value of 0 MUST NOT be mistaken to refer to "ground elevation". value of 0 MUST NOT be mistaken to refer to "ground elevation".
skipping to change at page 13, line 46 skipping to change at page 13, line 14
6. Use Cases and Examples 6. Use Cases and Examples
6.1. Plain 'geo' URI Example 6.1. Plain 'geo' URI Example
The following 3-dimensional 'geo' URI example references to the The following 3-dimensional 'geo' URI example references to the
office location of one of the authors in Vienna, Austria: office location of one of the authors in Vienna, Austria:
geo:48.2010,16.3695,183 geo:48.2010,16.3695,183
Resolution of the URI returns the following information:
o The 'crs' parameter is not given in the URI, which means that the
URI uses the default CRS of WGS-84.
o The URI includes <coord-c>, is hence 3-dimensional, and therefore
uses 'urn:ogc:def:crs:EPSG::4979' as the WGS-84 CRS identifier.
o The <coord-a> value (latitude in WGS-84) is set to '48.2010'
decimal degrees.
o The <coord-b> value (longitude in WGS-84) is set to '16.3695'
decimal degrees.
o The <coord-c> value (altitude in WGS-84) is set to 183 meters.
o Uncertainty is undefined.
A user could type the data extracted from this URI into a electronic A user could type the data extracted from this URI into a electronic
navigation device, or even use it to locate the identified location navigation device, or even use it to locate the identified location
on a paper map. on a paper map.
6.2. Hyperlink 6.2. Hyperlink
'geo' URIs (like any other URI scheme) could also be embedded as 'geo' URIs (like any other URI scheme) could also be embedded as
hyperlinks in web pages. A Hyper Text Markup Language (HTML) snippet hyperlinks in web pages. A Hyper Text Markup Language (HTML) snippet
with such a hyperlink could look like: with such a hyperlink could look like:
<p>one of Vienna's popular sights is the <p>one of Vienna's popular sights is the
<a href='geo:48.198634,16.371648;crs=wgs84'>Karlskirche</a>. <a href='geo:48.198634,16.371648;crs=wgs84;u=40'>Karlskirche</a>.
A web browser could extract the coordinates from the HTML snippet and Resolution of the URI returns the following information:
o The 'crs' is given in the URI, and sets the CRS used in the URI to
WGS-84 explicitely.
o The URI does omit <coord-c>, is hence 2-dimensional, and therefore
uses 'urn:ogc:def:crs:EPSG::4326' as the WGS-84 CRS identifier.
o The <coord-a> value (latitude in WGS-84) is set to '48.198634'
decimal degrees.
o The <coord-b> value (longitude in WGS-84) is set to '16.371648'
decimal degrees.
o The <coord-c> (altitude) value is undefined, hence the client MAY
assume the identified location to be on Earth's physical surface.
o The 'u' parameter is included in the URI, setting uncertainty to
40 meters.
A web browser could use this information from the HTML snippet, and
offer the user various options (based on configuration, context), for offer the user various options (based on configuration, context), for
example: example:
o Display a small map thumbnail when the mouse pointer hovers over o Display a small map thumbnail when the mouse pointer hovers over
the link. the link.
o Switch to a mapping service of the user's choice once the link is o Switch to a mapping service of the user's choice once the link is
selected. selected.
o Locate nearby resources, for example by comparing the 'geo' URI o Locate nearby resources, for example by comparing the 'geo' URI
skipping to change at page 15, line 5 skipping to change at page 14, line 44
1. User identifies such a barcode on a flyer and uses the camera on 1. User identifies such a barcode on a flyer and uses the camera on
his mobile phone to photograph and decode the barcode. his mobile phone to photograph and decode the barcode.
2. The mobile phone dereferences the 'geo' URI, and offers the user 2. The mobile phone dereferences the 'geo' URI, and offers the user
to calculate a navigation route to the identified location. to calculate a navigation route to the identified location.
3. Using the builtin GPS receiver, the user follows the navgiation 3. Using the builtin GPS receiver, the user follows the navgiation
instructions to reach the location. instructions to reach the location.
6.4. Comparison Examples
This section provides examples of URI comparison. Note that the
unknown parameters 'foo' and 'bar' and unregistered 'crs' values in
this section are used for illustrative purposes only, and their
inclusion in the examples below does not constitute any formal
parameter definition or registration request.
o The two URIs <geo:90,-22.43;crs=WGS84> and <geo:90,46> are equal,
because both use the same CRS, and even though the longitude
values are different, both reflect a location on the north pole
(special "poles" rule for WGS-84 applies - longitude is to be
ignored). Note that the 'crs' parameter values are case
insensitive.
o The URIs <geo:22.300;-118.44> and <geo:22.3;-118.4400> are equal,
because their coordinate components are mathematically identical
o The set of <geo:66,30;u=6.500;FOo=this%2dthat> and <geo:
66.0,30;u=6.5;foo=this-that> are identical, because the value of
the unknown parameter 'foo' is bitwise identical after percent-
decoding, parameter names are case insensitive, and coordinates
and uncertainty are mathematically identical.
o The comparison operation on <geo:70,20;foo=1.00;bar=white> and
<geo:70,20;foo=1;bar=white> in a legacy implementation is
undefined, because the normalization rules for 'foo' are not
known, and hence the implementation cannot identify whether or not
'1.00' is identical to '1' for the 'foo' parameter.
o Comparing <geo:47,11;foo=blue;bar=white> and <geo:
47,11;bar=white;foo=blue> returns true, because parameter order is
insignificant in comparison operations
o The comparison operation on <geo:22,0;bar=Blue> and <geo:
22,0;BAR=blue> is undefined, because even though parameter names
are case insensitive, this is not neccessarily the case for the
values of the unknown 'foo' parameter.
7. GML Mappings 7. GML Mappings
The Geographic Markup Language (GML) by the Open Geospatial The Geographic Markup Language (GML) by the Open Geospatial
Consortium (OGC) is a set of XML schemas to represent geographical Consortium (OGC) is a set of XML schemas to represent geographical
features. Since GML is widely accepted, this document includes features. Since GML is widely accepted, this document includes
instructions on how to transform 'geo' URIs from and to GML instructions on how to transform 'geo' URIs from and to GML
fragments. The instructions in this section are not normative. fragments. The instructions in this section are not normative.
For the following sections, "%lat%", "%lon%", "%alt%" and "%unc%" are For the following sections, "%lat%", "%lon%", "%alt%" and "%unc%" are
placeholders for latitude, longitude, altitude and uncertainty placeholders for latitude, longitude, altitude and uncertainty
skipping to change at page 21, line 11 skipping to change at page 21, line 36
[WGS84] National Imagery and Mapping Agency, "Department of [WGS84] National Imagery and Mapping Agency, "Department of
Defense World Geodetic System 1984, Third Edition", Defense World Geodetic System 1984, Third Edition",
NIMA TR8350.2, January 2000. NIMA TR8350.2, January 2000.
Appendix A. Change Log Appendix A. Change Log
[Note to editors: This section is to be removed before publication - [Note to editors: This section is to be removed before publication -
XML source available on request] XML source available on request]
draft-ietf-geopriv-geo-uri-06
o Addressed remaining IESG evaluation comments:
o comparison rules for unknown parameters
o extended examples
draft-ietf-geopriv-geo-uri-05
o Addressed IESG evaluation comments (some)
draft-ietf-geopriv-geo-uri-04 draft-ietf-geopriv-geo-uri-04
o Added "crs" URI parameter registry o Added "crs" URI parameter registry
o Added example URI to Introduction o Added example URI to Introduction
o Changed quoting of parameters according to Alfred Hoenes' comments o Changed quoting of parameters according to Alfred Hoenes' comments
draft-ietf-geopriv-geo-uri-03 draft-ietf-geopriv-geo-uri-03
o Updated privacy considerations section as per Alissa's comments o Updated privacy considerations section as per Alissa's comments
o Added text on uncertainty applied to all given dimensions o Added text on uncertainty applied to all given dimensions
o various editorial changes o various editorial changes
o Changed ABNF to reflect order of parameters (CRS first, then U, o Changed ABNF to reflect order of parameters (CRS first, then U,
skipping to change at page 22, line 32 skipping to change at page 23, line 18
Authors' Addresses Authors' Addresses
Alexander Mayrhofer Alexander Mayrhofer
IPCom GmbH IPCom GmbH
Karlsplatz 1/2/9 Karlsplatz 1/2/9
Wien A-1010 Wien A-1010
Austria Austria
Phone: +43 1 5056416 34 Phone: +43 1 5056416 34
Email: alexander.mayrhofer@nic.at Email: alexander.mayrhofer@ipcom.at
URI: http://www.ipcom.at/ URI: http://www.ipcom.at/
Christian Spanring Christian Spanring
30 Hancock St 30 Hancock St
Somerville 02144 Somerville 02144
Phone: +1 617 863 0360 Phone: +1 617 863 0360
Email: christian@spanring.eu Email: christian@spanring.eu
URI: http://www.spanring.eu/ URI: http://www.spanring.eu/
 End of changes. 28 change blocks. 
61 lines changed or deleted 147 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/