draft-ietf-ecrit-specifying-holes-00.txt   draft-ietf-ecrit-specifying-holes-01.txt 
ECRIT J. Winterbottom ECRIT J. Winterbottom
Internet-Draft M. Thomson Internet-Draft M. Thomson
Intended status: Best Current Andrew Corporation Intended status: BCP Andrew Corporation
Practice June 18, 2008 Expires: April 16, 2009 October 13, 2008
Expires: December 20, 2008
Specifying Holes in LoST Service Boundaries Specifying Holes in LoST Service Boundaries
draft-ietf-ecrit-specifying-holes-00.txt draft-ietf-ecrit-specifying-holes-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 34
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 20, 2008. This Internet-Draft will expire on April 16, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document describes how holes can be specified in service This document describes how holes can be specified in geodetic
boundaries. One means of implementing a solution is described. service boundaries. One means of implementing a search solution in a
service database, such as one might provide with a LoST server, is
described.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Specifying Holes . . . . . . . . . . . . . . . . . . . . . . . 5 3. Specifying Holes . . . . . . . . . . . . . . . . . . . . . . . 5
4. GML Polygons . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. GML Polygons . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Holes in GML Polygons . . . . . . . . . . . . . . . . . . . . 9 5. Holes in GML Polygons . . . . . . . . . . . . . . . . . . . . 9
6. Service Boundary Specification and Selection Algorithm . . . . 10 6. Service Boundary Specification and Selection Algorithm . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 18
1. Introduction 1. Introduction
The LoST protocol [I-D.ietf-ecrit-lost] describes a protocol that's The LoST protocol [RFC5222] describes a protocol that's primary
primary purpose is to map service and locations to destination purpose is to map service and locations to destination addresses.
addresses. LoST does this by provisioning boundary maps or areas LoST does this by provisioning boundary maps or areas against service
against service URNs. The boundary is a polygon made up of sets of URNs. The boundary is a polygon made up of sets of geodetic
geodetic coordinates specifying an enclosed area. In some coordinates specifying an enclosed area. In some circumstances an
circumstances an area enclosed by a polygon, also known as an area enclosed by a polygon, also known as an exterior polygon, may
exterior polygon, may contain exception areas, or holes, that for the contain exception areas, or holes, that for the same service must
same service must yield a different destination to that described by yield a different destination to that described by the larger area.
the larger area. This document describes how holes SHOULD be This document describes how holes SHOULD be specified in service
specified in service boundaries defined using a GML encoding for the boundaries defined using a GML encoding for the polygons and their
polygons and their internal elements (holes). GML polygons are based internal elements (holes). GML polygons are based on elements
on elements defined in [ISO-19107]. defined in [ISO-19107].
o-------------o o--------------o
/ \ / \
/ /\ \ / /\ \
/ + +-----+ \ / + +-----+ \
o | Hole \ o o | Hole \ o
| | 1 / | | | 1 / |
| +-------+ |<--- Primary Polygon | +-------+ |<--- Primary Polygon
| +-------+ | | +-------+ |
| / Hole | | | / Hole | |
o \ 2 | o o \ 2 | o
\ +-----+ + / \ +-----+ + /
\ \/ / \ \/ /
\ / \ /
o--------------o o--------------o
Figure 1: Holes in a Polygon
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Specifying Holes 3. Specifying Holes
Holes related to an exterior boundary polygon MUST adhere to the Holes related to an exterior boundary polygon MUST adhere to the
following rules: following rules:
Rule 1: Two holes MUST NOT have more than one point of Rule 1: Two holes MUST NOT have more than one point of
intersection. If two or more holes share a common set of intersection. If two or more holes share a common set of
boundaries then to the primary polygon these represent a boundaries then to the primary polygon these represent a
single hole in the service. The internal elements (holes) single hole in the service. The internal elements (holes)
should have common boundaries removed and a single hole should have common boundaries removed and a single hole
created irrespective of whether the excluded area is itself created irrespective of whether the excluded area is itself
made up of multiple service boundaries. made up of multiple service boundaries.
o-------------o o-------------o o--------------o o--------------o
/ \ / \ / \ / \
/ /\ \ / /\ \ / /\ \ / /\ \
/ + +-----+ \ / + +-----+ \ / + +-----+ \ / + +-----+ \
o | Hole \ o o | \ o o | Hole \ o o | \ o
| | 1 \ | | | One \ | | | 1 \ | | | One \ |
| +-+-------+ | =========> | +-+ Hole + | | +-+-------+ | =========> | +-+ Hole + |
| / Hole | | | / | | | / Hole | | | / | |
o \ 2 | o o \ | o o \ 2 | o o \ | o
\ +-----+ + / \ +-----+ + / \ +-----+ + / \ +-----+ + /
\ \/ / \ \/ / \ \/ / \ \/ /
\ / \ / \ / \ /
o--------------o o--------------o o--------------o o--------------o
Incorrect Correct Incorrect Correct
Incorrect Hole Specification with Boundary Sharing Figure 2: Incorrect Hole Specification with Boundary Sharing
Rule 2: A hole MUST NOT have more than one point of intersection Rule 2: A hole MUST NOT have more than one point of intersection
with the outer-boundary of the primary (exterior) polygon. with the outer-boundary of the primary (exterior) polygon.
If more than one point of intersection occurs the primary If more than one point of intersection occurs the primary
polygon is either doesn't have a hole, it has an inlet as polygon is either doesn't have a hole, it has an inlet as
in Figure 3, or the primary polygon SHOULD be expressed as in Figure 3, or the primary polygon SHOULD be expressed as
two polygons as in Figure 4. two polygons as in Figure 4.
+------- Inlet +------- Inlet
| |
v v
o--+-----+----o o--o o----o o---+-----+----o o---o o----o
/ |%%%%%| \ / | | \ / |%%%%%| \ / | | \
/ /%%%%%%| \ / / | \ / /%%%%%%| \ / / | \
/ +%%%%%%%| \ / o o \ / +%%%%%%%| \ / o o \
o |%%%%%%%%\ o o | \ o o |%%%%%%%%\ o o | \ o
| |%%%%%%%%%\ | | | \ | | |%%%%%%%%%\ | | | \ |
| +-+%%%%%%%%+ | ========> | o-o o | | +-+%%%%%%%%+ | ========> | o-o o |
| /%%%%%%%%| | | / | | | /%%%%%%%%| | | / | |
o \%%%%%%%%| o o \ | o o \%%%%%%%%| o o \ | o
\ +-----+ + / \ o-----o o / \ +-----+ + / \ o-----o o /
\ \/ / \ \/ / \ \/ / \ \/ /
skipping to change at page 8, line 11 skipping to change at page 8, line 11
geoshape specification [geoshape]. There is no restriction geoshape specification [geoshape]. There is no restriction
on the number of points that may be used to express the on the number of points that may be used to express the
perimeter of the hole. perimeter of the hole.
4. GML Polygons 4. GML Polygons
The GML encoding of a polygon defines a enclosed exterior boundary, The GML encoding of a polygon defines a enclosed exterior boundary,
with the first and last points of boundary being the same. Consider with the first and last points of boundary being the same. Consider
the example in Figure 5. the example in Figure 5.
B-------------C B--------------C
/ \ / \
/ \ / \
/ \ / \
A D A D
\ / \ /
\ / \ /
\ / \ /
F--------------E F--------------E
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326"> <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
skipping to change at page 9, line 11 skipping to change at page 9, line 11
NOTE that polygon vertices in Figure 5 are expressed using <pos> NOTE that polygon vertices in Figure 5 are expressed using <pos>
elements for clarity. The vertices can also be expressed using a elements for clarity. The vertices can also be expressed using a
<posList> element. <posList> element.
5. Holes in GML Polygons 5. Holes in GML Polygons
A hole is specified in the polygon by defining an interior boundary. A hole is specified in the polygon by defining an interior boundary.
The points defining the internal boundary define the area represented The points defining the internal boundary define the area represented
by the hole in the primary (exterior) polygon. The shaded area in by the hole in the primary (exterior) polygon. The shaded area in
Figure 6 is represented by the 4 points of the interior boundary Figure 6 is represented by the 4 points of the interior boundary
specified in Figure 7. specified by (w,z,y,x).
B-------------C B-------------C
/ \ / \
/ w-------------x \ / w-------------x \
/ |/////////////| \ / |/////////////| \
A |/////////////| D A |/////////////| D
\ |/////////////| / \ |/////////////| /
\ z-------------y / \ z-------------y /
\ / \ /
F-------------E F-------------E
Figure 6: Hexagon with Hole
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326"> <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
<gml:exterior> <gml:exterior>
<gml:LinearRing> <gml:LinearRing>
<gml:pos>43.311 -73.422</gml:pos> <!--A--> <gml:pos>43.311 -73.422</gml:pos> <!--A-->
<gml:pos>43.111 -73.322</gml:pos> <!--F--> <gml:pos>43.111 -73.322</gml:pos> <!--F-->
<gml:pos>43.111 -73.222</gml:pos> <!--E--> <gml:pos>43.111 -73.222</gml:pos> <!--E-->
<gml:pos>43.311 -73.122</gml:pos> <!--D--> <gml:pos>43.311 -73.122</gml:pos> <!--D-->
<gml:pos>43.511 -73.222</gml:pos> <!--C--> <gml:pos>43.511 -73.222</gml:pos> <!--C-->
<gml:pos>43.511 -73.322</gml:pos> <!--B--> <gml:pos>43.511 -73.322</gml:pos> <!--B-->
<gml:pos>43.311 -73.422</gml:pos> <!--A--> <gml:pos>43.311 -73.422</gml:pos> <!--A-->
skipping to change at page 9, line 48 skipping to change at page 9, line 46
<gml:LinearRing> <gml:LinearRing>
<gml:pos>43.411 -73.322</gml:pos> <!--w--> <gml:pos>43.411 -73.322</gml:pos> <!--w-->
<gml:pos>43.211 -73.322</gml:pos> <!--z--> <gml:pos>43.211 -73.322</gml:pos> <!--z-->
<gml:pos>43.211 -73.222</gml:pos> <!--y--> <gml:pos>43.211 -73.222</gml:pos> <!--y-->
<gml:pos>43.411 -73.222</gml:pos> <!--x--> <gml:pos>43.411 -73.222</gml:pos> <!--x-->
<gml:pos>43.411 -73.322</gml:pos> <!--w--> <gml:pos>43.411 -73.322</gml:pos> <!--w-->
</gml:LinearRing> </gml:LinearRing>
</gml:interior> </gml:interior>
</gml:Polygon> </gml:Polygon>
Figure 7: GML for Hexagon with Hole Figure 6: Hexagon with Hole
6. Service Boundary Specification and Selection Algorithm 6. Service Boundary Specification and Selection Algorithm
A service boundary is represented by a polygon that may have many A service boundary is represented by a polygon that may have many
vertices. The enclosed area of the polygon represents the area in vertices. The enclosed area of the polygon represents the area in
which a service, expressed as a service URN, maps to a single URI. which a service, expressed as a service URN, maps to a single URI.
[I-D.schulzrinne-ecrit-lost-sync] describes how LoST servers may
synchronize with one another and provides examples of possible
boundary exchanges and data formats. At the time of writing there is
no standard format for service provisioning data into a LoST server,
the format described in [I-D.schulzrinne-ecrit-lost-sync] is used for
the example in this section.
Figure 6 shall be used to illustrate two service boundaries. The Figure 6 shall be used to illustrate two service boundaries. The
first service boundary A->F shall be referred to as area-A, and the first service boundary A->F shall be referred to as area-A, and the
second service boundary w->z shall be referred to as area-w. Further second service boundary w->z shall be referred to as area-w. Further
more area-A is directly represented by the GML encoding provided in more area-A is directly represented by the GML encoding provided in
Figure 7. Area-w is represented as a hole in area-A by the interior Figure 6. Area-w is represented as a hole in area-A by the interior
boundary. Since area-w is also a service boundary, a separate boundary. Since area-w is also a service boundary, a separate
polygon describing this area is also required and is shown in polygon describing this area is also required and is shown in
Figure 8. Figure 7.
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326"> <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
<gml:exterior> <gml:exterior>
<gml:LinearRing> <gml:LinearRing>
<gml:pos>43.411 -73.322</gml:pos> <!--w--> <gml:pos>43.411 -73.322</gml:pos> <!--w-->
<gml:pos>43.211 -73.322</gml:pos> <!--z--> <gml:pos>43.211 -73.322</gml:pos> <!--z-->
<gml:pos>43.211 -73.222</gml:pos> <!--y--> <gml:pos>43.211 -73.222</gml:pos> <!--y-->
<gml:pos>43.411 -73.222</gml:pos> <!--x--> <gml:pos>43.411 -73.222</gml:pos> <!--x-->
<gml:pos>43.411 -73.322</gml:pos> <!--w--> <gml:pos>43.411 -73.322</gml:pos> <!--w-->
</gml:LinearRing> </gml:LinearRing>
</gml:exterior> </gml:exterior>
</gml:Polygon> </gml:Polygon>
Figure 8: GML for Area-w Figure 7: GML for Area-w
If this data were in a LoST server and was required in a neighbouring If this data were in a LoST server the data mappings may look similar
LoST server, the data transfer using the format in to the example in Figure 8. This is an example only and does not
[I-D.schulzrinne-ecrit-lost-sync] would look similar to Figure 9. represent actual LoST server provisioning or data transfer records.
The example XML will not complie.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<pushMappingsRequest xmlns="urn:ietf:params:xml:ns:lost1:sync"> <entry>
<mappings> <name> Outer Area Police Department </name>
<mapping sourceId="lost:area-A.nsw.au.example"
version="1" lastUpdated="2007-11-26T01:00:00Z"
timeToLive="2007-12-26T01:00:00Z">
<displayName xml:lang="en">
Outer Area Police Department
</displayName>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
<serviceBoundary profile="geodetic-2d"> <serviceBoundary profile="geodetic-2d">
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326"> <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
<gml:exterior> <gml:exterior>
<gml:LinearRing> <gml:LinearRing>
<gml:pos>43.311 -73.422</gml:pos> <gml:pos>43.311 -73.422</gml:pos>
<gml:pos>43.111 -73.322</gml:pos> <gml:pos>43.111 -73.322</gml:pos>
<gml:pos>43.111 -73.222</gml:pos> <gml:pos>43.111 -73.222</gml:pos>
<gml:pos>43.311 -73.122</gml:pos> <gml:pos>43.311 -73.122</gml:pos>
<gml:pos>43.511 -73.222</gml:pos> <gml:pos>43.511 -73.222</gml:pos>
<gml:pos>43.511 -73.322</gml:pos> <gml:pos>43.511 -73.322</gml:pos>
<gml:pos>43.311 -73.422</gml:pos> <gml:pos>43.311 -73.422</gml:pos>
</gml:LinearRing> </gml:LinearRing>
</gml:exterior> </gml:exterior>
<!-- this is the service boundary hole -->
<gml:interior> <gml:interior>
<gml:LinearRing> <gml:LinearRing>
<gml:pos>43.411 -73.322</gml:pos> <gml:pos>43.411 -73.322</gml:pos>
<gml:pos>43.211 -73.322</gml:pos> <gml:pos>43.211 -73.322</gml:pos>
<gml:pos>43.211 -73.222</gml:pos> <gml:pos>43.211 -73.222</gml:pos>
<gml:pos>43.411 -73.222</gml:pos> <gml:pos>43.411 -73.222</gml:pos>
<gml:pos>43.411 -73.322</gml:pos> <gml:pos>43.411 -73.322</gml:pos>
</gml:LinearRing> </gml:LinearRing>
</gml:interior> </gml:interior>
</gml:Polygon> </gml:Polygon>
</serviceBoundary> </serviceBoundary>
<uri>sip:area-A-pd@example.com</uri> <uri>sip:area-A-pd@example.com</uri>
<uri>xmpp:area-A-pd@example.com</uri> <uri>xmpp:area-A-pd@example.com</uri>
<serviceNumber>000</serviceNumber> <serviceNumber>000</serviceNumber>
</mapping> </entry>
<mapping sourceId="lost:area-w.nsw.au.example" <entry>
version="1" lastUpdated="2007-11-26T01:00:00Z" <name> Inner Area Police Department </name>
timeToLive="2007-12-26T01:00:00Z">
<displayName xml:lang="en">
Inner Area Police Department
</displayName>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
<serviceBoundary profile="geodetic-2d"> <serviceBoundary profile="geodetic-2d">
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326"> <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
<gml:exterior> <gml:exterior>
<gml:LinearRing> <gml:LinearRing>
<gml:pos>43.411 -73.322</gml:pos> <gml:pos>43.411 -73.322</gml:pos>
<gml:pos>43.211 -73.322</gml:pos> <gml:pos>43.211 -73.322</gml:pos>
<gml:pos>43.211 -73.222</gml:pos> <gml:pos>43.211 -73.222</gml:pos>
<gml:pos>43.411 -73.222</gml:pos> <gml:pos>43.411 -73.222</gml:pos>
<gml:pos>43.411 -73.322</gml:pos> <gml:pos>43.411 -73.322</gml:pos>
</gml:LinearRing> </gml:LinearRing>
</gml:exterior> </gml:exterior>
</gml:Polygon> </gml:Polygon>
</serviceBoundary> </serviceBoundary>
<uri>sip:area-w-pd@example.com</uri> <uri>sip:area-w-pd@example.com</uri>
<uri>xmpp:area-w-pd@example.com</uri> <uri>xmpp:area-w-pd@example.com</uri>
<serviceNumber>000</serviceNumber> <serviceNumber>000</serviceNumber>
</mapping> </entry>
</mappings>
</pushMappingsRequest>
Figure 9: Service Boundary Specifications Figure 8: Service Boundary Specifications
It is considered likely that LoST servers will need to provide It is considered likely that LoST servers will need to provide
responses sufficiently quickly to allow real-time queries to be responses sufficiently quickly to allow real-time queries to be
performed as part of an emergency call routing flow. It is for this performed as part of an emergency call routing flow. It is for this
reason that databases supporting native geospatial query techniques reason that databases supporting native geospatial query techniques
are desirable and that service boundary specifications that are are desirable and that service boundary specifications that are
easily mapped to internal data structures are preferred. The format easily mapped to internal data structures are preferred. The format
described in this memo makes support for this operation easy, while described in this memo makes support for this operation easy, while
allowing an arbitrary number of holes in a service boundary to be allowing an arbitrary number of holes in a service boundary to be
specified. specified.
skipping to change at page 13, line 7 skipping to change at page 13, line 7
In general no holes will exist for a service boundary, so this check In general no holes will exist for a service boundary, so this check
results in almost no overhead and the service mapping can be results in almost no overhead and the service mapping can be
returned. Where one or more holes are found to exist, the provided returned. Where one or more holes are found to exist, the provided
location is checked against each hole. If the location is found to location is checked against each hole. If the location is found to
exist in one of the specified holes then the primary polygon can be exist in one of the specified holes then the primary polygon can be
discarded, and searching of the service boundary database can discarded, and searching of the service boundary database can
continue. continue.
7. Security Considerations 7. Security Considerations
This document does not introduce any security issues This document does not introduce any security issues.
8. IANA Considerations 8. IANA Considerations
There are no specific IANA considerations for this document. There are no specific IANA considerations for this document.
9. Acknowledgements 9. Acknowledgements
Thanks to Carl Reed for input provided to the list some months back Thanks to Carl Reed for input provided to the list some months back
and for reviewing this document. Thanks also to Michael Haberler for and for reviewing this document. Thanks also to Michael Haberler for
suggesting that such a specification is required. suggesting that such a specification is required.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-ecrit-lost] [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation Tschofenig, "LoST: A Location-to-Service Translation
Protocol", draft-ietf-ecrit-lost-10 (work in progress), Protocol", RFC 5222, August 2008.
May 2008.
[I-D.schulzrinne-ecrit-lost-sync]
Schulzrinne, H., "Synchronizing Location-to-Service
Translation (LoST) Servers",
draft-schulzrinne-ecrit-lost-sync-01 (work in progress),
February 2008.
[geoshape] [geoshape]
Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape
Application Schema for use by the Internet Engineering Application Schema for use by the Internet Engineering
Task Force (IETF)", Candidate OpenGIS Implementation Task Force (IETF)", Candidate OpenGIS Implementation
Specification 06-142r1, Version: 1.0, April 2007. Specification 06-142r1, Version: 1.0, April 2007.
10.2. Informative References 10.2. Informative References
[I-D.ietf-ecrit-lost-sync]
Schulzrinne, H., "Synchronizing Location-to-Service
Translation (LoST) Servers", draft-ietf-ecrit-lost-sync-00
(work in progress), July 2008.
[ISO-19107] [ISO-19107]
ISO, "Geographic information - Spatial Schema", ISO ISO, "Geographic information - Spatial Schema", ISO
Standard 19107, First Edition, 5 2003. Standard 19107, First Edition, 5 2003.
Authors' Addresses Authors' Addresses
James Winterbottom James Winterbottom
Andrew Corporation Andrew Corporation
PO Box U40 PO Box U40
University of Wollongong, NSW 2500 University of Wollongong, NSW 2500
skipping to change at page 18, line 44 skipping to change at line 475
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 29 change blocks. 
74 lines changed or deleted 52 lines changed or added

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