draft-ietf-ecrit-lost-sync-10.txt   draft-ietf-ecrit-lost-sync-11.txt 
ECRIT H. Schulzrinne ECRIT H. Schulzrinne
Internet-Draft Columbia University Internet-Draft Columbia University
Intended status: Experimental H. Tschofenig Intended status: Experimental H. Tschofenig
Expires: September 30, 2011 Nokia Siemens Networks Expires: December 22, 2011 Nokia Siemens Networks
March 29, 2011 June 20, 2011
Synchronizing Location-to-Service Translation (LoST) Protocol based Synchronizing Location-to-Service Translation (LoST) Protocol based
Service Boundaries and Mapping Elements Service Boundaries and Mapping Elements
draft-ietf-ecrit-lost-sync-10.txt draft-ietf-ecrit-lost-sync-11.txt
Abstract Abstract
The Location-to-Service Translation (LoST) protocol is an XML-based The Location-to-Service Translation (LoST) protocol is an XML-based
protocol for mapping service identifiers and geodetic or civic protocol for mapping service identifiers and geodetic or civic
location information to service URIs and service boundaries. In location information to service URIs and service boundaries. In
particular, it can be used to determine the location-appropriate particular, it can be used to determine the location-appropriate
Public Safety Answering Point (PSAP) for emergency services. Public Safety Answering Point (PSAP) for emergency services.
The main data structure, the <mapping> element, used for The main data structure, the <mapping> element, used for
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on September 30, 2011. This Internet-Draft will expire on December 22, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 6, line 5 skipping to change at page 6, line 5
LoST Server 'East': This LoST server would contain all the mappings LoST Server 'East': This LoST server would contain all the mappings
to PSAPs covering one half of the country. to PSAPs covering one half of the country.
Additionally, the LoST server aggregates all the information it Additionally, the LoST server aggregates all the information it
has and provides an abstracted view towards the Forest Guide has and provides an abstracted view towards the Forest Guide
indicating that it is responsible for a certain area (for a given indicating that it is responsible for a certain area (for a given
service, and for a given location profile). Such a mapping would service, and for a given location profile). Such a mapping would
have the following structure: have the following structure:
<?xml version="1.0" encoding="UTF-8"?>
<mapping <mapping
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:gml="http://www.opengis.net/gml"
expires="2009-01-01T01:44:33Z" expires="2009-01-01T01:44:33Z"
lastUpdated="2009-12-01T01:00:00Z" lastUpdated="2009-12-01T01:00:00Z"
source="east-austria.lost-example.com" source="east-austria.lost-example.com"
sourceId="e8b05a41d8d1415b80f2cdbb96ccf109"> sourceId="e8b05a41d8d1415b80f2cdbb96ccf109">
<displayName xml:lang="en">LoST Server 'East' </displayName> <displayName xml:lang="en">LoST Server 'East' </displayName>
<service>urn:service:sos</service> <service>urn:service:sos</service>
<serviceBoundary profile="geodetic-2d"> <serviceBoundary profile="geodetic-2d">
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> <gml:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior> <gml:exterior>
<p2:LinearRing> <gml:LinearRing>
<p2:pos> ... </p2:pos> <gml:pos> ... </gml:pos>
..... list of coordinates for ..... list of coordinates for
boundary of LoST server 'East' boundary of LoST server 'East'
<p2:pos> ... </p2:pos> <gml:pos> ... </gml:pos>
</p2:LinearRing> </gml:LinearRing>
</p2:exterior> </gml:exterior>
</p2:Polygon> </gml:Polygon>
</serviceBoundary> </serviceBoundary>
<uri/> <uri/>
</mapping> </mapping>
Figure 2: Forest Guide Austria Mapping Example Figure 2: Forest Guide Austria Mapping Example
As it can be seen in this example there the <uri> element is left As it can be seen in this example there the <uri> element is left
empty and the 'source' attribute is used to indicate the identity empty and the 'source' attribute is used to indicate the identity
of the LoST server, namely "east-austria.lost-example.com". of the LoST server, namely "east-austria.lost-example.com".
skipping to change at page 7, line 5 skipping to change at page 7, line 5
LoST Server 'Vienna': This LoST server would contain all the LoST Server 'Vienna': This LoST server would contain all the
mappings to PSAPs in the area of Vienna. mappings to PSAPs in the area of Vienna.
Forest Guide Finland: In our example we assume that Finland would Forest Guide Finland: In our example we assume that Finland would
deploy a single ESRP for the entire country as their IP-based deploy a single ESRP for the entire country as their IP-based
emergency services solution. There is only a single LoST server emergency services solution. There is only a single LoST server
and it is co-located with the Forest Guide, as shown in Figure 1. and it is co-located with the Forest Guide, as shown in Figure 1.
The mapping data this FG would distribute via LoST sync is shown The mapping data this FG would distribute via LoST sync is shown
in Figure 3. in Figure 3.
<mapping <?xml version="1.0" encoding="UTF-8"?>
<mapping xmlns="urn:ietf:params:xml:ns:lost1"
expires="2007-01-01T01:44:33Z" expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z" lastUpdated="2006-11-01T01:00:00Z"
source="finland.lost-example.com" source="finland.lost-example.com"
sourceId="7e3f40b098c711dbb6060800200c9a66"> sourceId="7e3f40b098c711dbb6060800200c9a66">
<displayName xml:lang="en"> Finland ESRP </displayName> <displayName xml:lang="en"> Finland ESRP </displayName>
<service>urn:service:sos</service> <service>urn:service:sos</service>
<serviceBoundary profile="civic"> <serviceBoundary profile="civic">
<civicAddress <civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>FI</country> <country>FI</country>
</civicAddress> </civicAddress>
</serviceBoundary> </serviceBoundary>
<uri/> <uri/>
</mapping> </mapping>
Figure 3: Forest Guide Finland Mapping Example Figure 3: Forest Guide Finland Mapping Example
An example mapping stored at the co-located LoST server is shown An example mapping stored at the co-located LoST server is shown
in Figure 4. in Figure 4.
<mapping <?xml version="1.0" encoding="UTF-8"?>
<mapping xmlns="urn:ietf:params:xml:ns:lost1"
expires="2007-01-01T01:44:33Z" expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z" lastUpdated="2006-11-01T01:00:00Z"
source="finland.lost-example.com" source="finland.lost-example.com"
sourceId="7e3f40b098c711dbb6060800200c9a66"> sourceId="7e3f40b098c711dbb6060800200c9a66">
<displayName xml:lang="en"> Finland ESRP </displayName> <displayName xml:lang="en"> Finland ESRP </displayName>
<service>urn:service:sos</service> <service>urn:service:sos</service>
<serviceBoundary profile="civic"> <serviceBoundary profile="civic">
<civicAddress <civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>FI</country> <country>FI</country>
skipping to change at page 12, line 43 skipping to change at page 12, line 43
The response to the above request is shown in Figure 9. A more The response to the above request is shown in Figure 9. A more
recent mapping was available with the identification of recent mapping was available with the identification of
source="authoritative.bar.example" and source="authoritative.bar.example" and
sourceId="7e3f40b098c711dbb6060800200c9a66". Only one mapping that sourceId="7e3f40b098c711dbb6060800200c9a66". Only one mapping that
matched source="authoritative.foo.example" was found and returned. matched source="authoritative.foo.example" was found and returned.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<sync:getMappingsResponse <sync:getMappingsResponse
xmlns:sync="urn:ietf:params:xml:ns:lostsync1" xmlns:sync="urn:ietf:params:xml:ns:lostsync1"
xmlns="urn:ietf:params:xml:ns:lost1" xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml"> xmlns:gml="http://www.opengis.net/gml">
<mapping source="authoritative.bar.example" <mapping source="authoritative.bar.example"
sourceId="7e3f40b098c711dbb6060800200c9a66" sourceId="7e3f40b098c711dbb6060800200c9a66"
lastUpdated="2008-11-26T01:00:00Z" lastUpdated="2008-11-26T01:00:00Z"
expires="2009-12-26T01:00:00Z"> expires="2009-12-26T01:00:00Z">
<displayName xml:lang="en"> <displayName xml:lang="en">
Leonia Police Department Leonia Police Department
</displayName> </displayName>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
<serviceBoundary <serviceBoundary
skipping to change at page 13, line 30 skipping to change at page 13, line 30
<mapping expires="2009-01-01T01:44:33Z" <mapping expires="2009-01-01T01:44:33Z"
lastUpdated="2008-11-01T01:00:00Z" lastUpdated="2008-11-01T01:00:00Z"
source="authoritative.foo.example" source="authoritative.foo.example"
sourceId="7e3f40b098c711dbb606011111111111"> sourceId="7e3f40b098c711dbb606011111111111">
<displayName xml:lang="en"> <displayName xml:lang="en">
New York City Police Department New York City Police Department
</displayName> </displayName>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
<serviceBoundary profile="geodetic-2d"> <serviceBoundary profile="geodetic-2d">
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> <gml:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior> <gml:exterior>
<p2:LinearRing> <gml:LinearRing>
<p2:pos>37.775 -122.4194</p2:pos> <gml:pos>37.775 -122.4194</gml:pos>
<p2:pos>37.555 -122.4194</p2:pos> <gml:pos>37.555 -122.4194</gml:pos>
<p2:pos>37.555 -122.4264</p2:pos> <gml:pos>37.555 -122.4264</gml:pos>
<p2:pos>37.775 -122.4264</p2:pos> <gml:pos>37.775 -122.4264</gml:pos>
<p2:pos>37.775 -122.4194</p2:pos> <gml:pos>37.775 -122.4194</gml:pos>
</p2:LinearRing> </gml:LinearRing>
</p2:exterior> </gml:exterior>
</p2:Polygon> </gml:Polygon>
</serviceBoundary> </serviceBoundary>
<uri>sip:nypd@example.com</uri> <uri>sip:nypd@example.com</uri>
<uri>xmpp:nypd@example.com</uri> <uri>xmpp:nypd@example.com</uri>
<serviceNumber>911</serviceNumber> <serviceNumber>911</serviceNumber>
</mapping> </mapping>
</sync:getMappingsResponse> </sync:getMappingsResponse>
Figure 9: Example <getMappingsResponse> Message Figure 9: Example <getMappingsResponse> Message
skipping to change at page 15, line 48 skipping to change at page 15, line 48
01T01:00:00Z" 01T01:00:00Z"
These two mappings have to be added to the peer's mapping database. These two mappings have to be added to the peer's mapping database.
Additionally, the following mapping has to be deleted: Additionally, the following mapping has to be deleted:
o source="nj.us.example" sourceId="123" lastUpdated="2008-11- o source="nj.us.example" sourceId="123" lastUpdated="2008-11-
01T01:00:00Z" 01T01:00:00Z"
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<sync:pushMappingsRequest <sync:pushMappings
xmlns:sync="urn:ietf:params:xml:ns:lostsync1" xmlns:sync="urn:ietf:params:xml:ns:lostsync1"
xmlns="urn:ietf:params:xml:ns:lost1" xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml"> xmlns:gml="http://www.opengis.net/gml">
<mapping source="authoritative.example" <mapping source="authoritative.example"
sourceId="7e3f40b098c711dbb6060800200c9a66" sourceId="7e3f40b098c711dbb6060800200c9a66"
lastUpdated="2008-11-26T01:00:00Z" lastUpdated="2008-11-26T01:00:00Z"
expires="2009-12-26T01:00:00Z"> expires="2009-12-26T01:00:00Z">
<displayName xml:lang="en"> <displayName xml:lang="en">
Leonia Police Department Leonia Police Department
</displayName> </displayName>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
<serviceBoundary <serviceBoundary
skipping to change at page 16, line 37 skipping to change at page 16, line 37
<mapping expires="2009-01-01T01:44:33Z" <mapping expires="2009-01-01T01:44:33Z"
lastUpdated="2008-11-01T01:00:00Z" lastUpdated="2008-11-01T01:00:00Z"
source="authoritative.example" source="authoritative.example"
sourceId="7e3f40b098c711dbb606011111111111"> sourceId="7e3f40b098c711dbb606011111111111">
<displayName xml:lang="en"> <displayName xml:lang="en">
New York City Police Department New York City Police Department
</displayName> </displayName>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
<serviceBoundary profile="geodetic-2d"> <serviceBoundary profile="geodetic-2d">
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> <gml:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior> <gml:exterior>
<p2:LinearRing> <gml:LinearRing>
<p2:pos>37.775 -122.4194</p2:pos> <gml:pos>37.775 -122.4194</gml:pos>
<p2:pos>37.555 -122.4194</p2:pos> <gml:pos>37.555 -122.4194</gml:pos>
<p2:pos>37.555 -122.4264</p2:pos> <gml:pos>37.555 -122.4264</gml:pos>
<p2:pos>37.775 -122.4264</p2:pos> <gml:pos>37.775 -122.4264</gml:pos>
<p2:pos>37.775 -122.4194</p2:pos> <gml:pos>37.775 -122.4194</gml:pos>
</p2:LinearRing> </gml:LinearRing>
</p2:exterior> </gml:exterior>
</p2:Polygon> </gml:Polygon>
</serviceBoundary> </serviceBoundary>
<uri>sip:nypd@example.com</uri> <uri>sip:nypd@example.com</uri>
<uri>xmpp:nypd@example.com</uri> <uri>xmpp:nypd@example.com</uri>
<serviceNumber>911</serviceNumber> <serviceNumber>911</serviceNumber>
</mapping> </mapping>
<mapping source="nj.us.example" <mapping source="nj.us.example"
sourceId="123" sourceId="123"
lastUpdated="2008-11-01T01:00:00Z" lastUpdated="2008-11-01T01:00:00Z"
expires="2008-11-01T01:00:00Z"/> expires="2008-11-01T01:00:00Z"/>
</sync:pushMappingsRequest> </sync:pushMappings>
Figure 10: Example <pushMappingsRequest> Message Figure 10: Example <pushMappingsRequest> Message
In response, the peer performs the necessary operation and updates In response, the peer performs the necessary operation and updates
its mapping database. In particular, it will check whether the other its mapping database. In particular, it will check whether the other
peer is authorized to perform the update and whether the elements and peer is authorized to perform the update and whether the elements and
attributes contain values that it understands. In our example, a attributes contain values that it understands. In our example, a
positive response is returned as shown in Figure 11. positive response is returned as shown in Figure 11.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
skipping to change at page 27, line 5 skipping to change at page 26, line 13
END END
10. Acknowledgments 10. Acknowledgments
Robins George, Cullen Jennings, Karl Heinz Wolf, Richard Barnes, Robins George, Cullen Jennings, Karl Heinz Wolf, Richard Barnes,
Mayutan Arumaithurai, Alexander Mayrhofer, and Andrew Newton provided Mayutan Arumaithurai, Alexander Mayrhofer, and Andrew Newton provided
helpful input. Jari Urpalainen assisted with the Relax NG schema. helpful input. Jari Urpalainen assisted with the Relax NG schema.
We would also like to thank our PROTO shepherd Roger Marshall for his We would also like to thank our PROTO shepherd Roger Marshall for his
help with the document. help with the document.
We would like to particularly thank Andrew Newton for his timely and
valuable review of the XML-related content.
11. References 11. References
11.1. Normative References 11.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.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
 End of changes. 16 change blocks. 
40 lines changed or deleted 48 lines changed or added

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