draft-ietf-ecrit-lost-sync-14.txt   draft-ietf-ecrit-lost-sync-15.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: July 14, 2012 Nokia Siemens Networks Expires: July 14, 2012 Nokia Siemens Networks
January 11, 2012 January 11, 2012
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-14.txt draft-ietf-ecrit-lost-sync-15.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 4, line 36 skipping to change at page 4, line 36
other LoST servers. Forest guides peer with other forest guides; other LoST servers. Forest guides peer with other forest guides;
authoritative mapping servers peer with forest guides and other authoritative mapping servers peer with forest guides and other
authoritative servers, either in the same cluster or above or below authoritative servers, either in the same cluster or above or below
them in the tree. Authoritative mapping servers push coverage them in the tree. Authoritative mapping servers push coverage
regions "up" the tree, i.e., from child nodes to parent nodes. The regions "up" the tree, i.e., from child nodes to parent nodes. The
child informs the parent of the geospatial or civic region that it child informs the parent of the geospatial or civic region that it
covers for a specific service. covers for a specific service.
Consider a hypothetical deployent of LoST in two countries, we call Consider a hypothetical deployent of LoST in two countries, we call
them Austria and Finland. Austria, in our example, runs three them Austria and Finland. Austria, in our example, runs three
authoritative LoST servers labeled as 'East', 'West' and 'Vienna' authoritative mapping servers labeled as 'East', 'West' and 'Vienna'
whereby the former two cover the entire country expect for Vienna, whereby the former two cover the entire country expect for Vienna,
which is covered by a separate LoST server. There may be other which is covered by a separate LoST server. There may be other
caching LoST servers run by ISPs, universities, and VSPs but they are caching LoST servers run by ISPs, universities, and VSPs but they are
not relevant for this illustration. Finland, on the other hand, not relevant for this illustration. Finland, on the other hand,
decided to only deploy a single LoST server that also acts as a decided to only deploy a single LoST server that also acts as a
Forest Guide. For this simplistic illustration we assume that only Forest Guide. For this simplistic illustration we assume that only
one service is available, namely 'urn:service:sos' since otherwise one service is available, namely 'urn:service:sos' since otherwise
the number of stored mappings would have to be multiplied by the the number of stored mappings would have to be multiplied by the
number of used services. number of used services.
skipping to change at page 5, line 35 skipping to change at page 5, line 35
| Server | | LoST | | Server | | Server | | LoST | | Server |
| (East) | | Server | |(Vienna)| | (East) | | Server | |(Vienna)|
\\----// | (West) | \\----// \\----// | (West) | \\----//
\\----// \\----//
Figure 1: LoST Deployment Example Figure 1: LoST Deployment Example
The configuration of these nodes would therefore be as follows: The configuration of these nodes would therefore be as follows:
Forest Guide Austria: This forest guide would contain mappings for Forest Guide Austria: This forest guide would contain mappings for
the three authoritative LoST servers (East, West and Vienna) the three authoritative mapping servers (East, West and Vienna)
describing what area they are responsible for. Note that each describing what area they are responsible for. Note that each
mapping would contain a service URN and these mappings point to mapping would contain a service URN and these mappings point to
LoST servers rather than to PSAPs or ESRPs. LoST servers rather than to PSAPs or ESRPs.
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 could
have the following structure: have the following structure:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<mapping <mapping
xmlns="urn:ietf:params:xml:ns:lost1" xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:gml="http://www.opengis.net/gml" 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">
<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> ... </gml:pos> <gml:pos> ... </gml:pos>
..... list of coordinates for ..... list of coordinates for
boundary of LoST server 'East' boundary of LoST server 'East'
<gml:pos> ... </gml:pos> <gml:pos> ... </gml:pos>
</gml:LinearRing> </gml:LinearRing>
</gml:exterior> </gml:exterior>
</gml:Polygon> </gml:Polygon>
</serviceBoundary> </serviceBoundary>
<uri/> <uri/>
</mapping> </mapping>
Figure 2: Forest Guide Austria Mapping Example Figure 2: Forest Guide Austria Mapping XML Snippet
As it can be seen in this example there the <uri> element is left Note that the XML code snippet in Figure 2 serves illustrative
empty and the 'source' attribute is used to indicate the identity purposes only and does not validate. As it can be seen in this
of the LoST server, namely "east-austria.lost-example.com". example the <uri> element is absent and the 'source' attribute
identifies the LoST server, namely "east-austria.lost-
example.com".
The above-shown mapping is what is the LoST server "east- The above-shown mapping is what is the LoST server "east-
austria.lost-example.com" provides to the Austrian Forest Guide. austria.lost-example.com" provides to the Austrian Forest Guide.
LoST Server 'West': This LoST server would contain all the mappings LoST Server 'West': This LoST server would contain all the mappings
to PSAPs covering the other half of the country. to PSAPs covering the other half of the country.
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.
skipping to change at page 7, line 11 skipping to change at page 7, line 11
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.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<mapping xmlns="urn:ietf:params:xml:ns:lost1" <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>
skipping to change at page 7, line 33 skipping to change at page 7, line 33
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.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<mapping xmlns="urn:ietf:params:xml:ns:lost1" <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>sip:esrp@finland-example.com</uri> <uri>sip:esrp@finland-example.com</uri>
<uri>xmpp:esrp@finland-example.com</uri> <uri>xmpp:esrp@finland-example.com</uri>
<serviceNumber>112</serviceNumber> <serviceNumber>112</serviceNumber>
</mapping> </mapping>
Figure 4: Forest Guide Finland / Co-Located LoST Server Mapping Figure 4: Forest Guide Finland / Co-Located LoST Server Mapping
Example Example
The LoST sync mechanism described in this document could be run The LoST sync mechanism described in this document could be run
between the two Forest Guides. Thereby, the three mappings stored in between the two Forest Guides. Thereby, the three mappings stored in
the Austria FG are sent to the FG Finland and a single mapping in the the Austria FG are sent to the FG Finland and a single mapping in the
FG Finland is sent to the FG Austria. Additionally, the three FG Finland is sent to the FG Austria. Additionally, the three
Austrian LoST servers could utilize LoST sync to inform the Austrian Austrian LoST servers could utilize LoST sync to inform the Austrian
FG about their boundaries. These three authoritative LoST servers in FG about their boundaries. These three authoritative mapping servers
Austria would be responsible to maintain their own mapping in Austria would be responsible to maintain their own mapping
information. Since the amount of data being exchanged is small and information. Since the amount of data being exchanged is small and
the expected rate of change is low the nodes are configured to always the expected rate of change is low the nodes are configured to always
exchange all their mapping information whenever a change happens. exchange all their mapping information whenever a change happens.
This document defines two types of exchanges and those are best This document defines two types of exchanges and those are best
described by the exchange between two nodes as shown in Figure 5 and described by the exchange between two nodes as shown in Figure 5 and
Figure 6. The protocol exchange always runs between a LoST Sync Figure 6. The protocol exchange always runs between a LoST Sync
source and a LoST Sync destination. Node A in the examples of source and a LoST Sync destination. Node A in the examples of
Figure 5 and Figure 6 has mappings that Node B is going to retrieve. Figure 5 and Figure 6 has mappings that Node B is going to retrieve.
Node A acts as the source for the data and Node B is the destination. Node A acts as the source for the data and Node B is the destination.
skipping to change at page 8, line 44 skipping to change at page 8, line 44
| | | |
| <getMappingsResponse> | | <getMappingsResponse> |
|<-----------------------------| |<-----------------------------|
| | | |
| | | |
| | | |
Figure 5: Querying for Mappings with a <getMappingsRequest> Message Figure 5: Querying for Mappings with a <getMappingsRequest> Message
Note that in the exchange illustrated in Figure 5 Node B issuing the Note that in the exchange illustrated in Figure 5 Node B issuing the
first request and plays the role of the HTTP/HTTPS client (with HTTP first request and plays the role of the HTTPS client (with HTTP as
as selected transport) and Node A plays the role of the HTTP/HTTPS selected transport) and Node A plays the role of the HTTPS server.
server.
The <pushMappingsRequest> exchange allows a LoST Sync source to push The <pushMappingsRequest> exchange allows a LoST Sync source to push
mappings to LoST Sync destination. The assumption is being made that mappings to LoST Sync destination. The assumption is being made that
Node A and B have previously been configured in a way that they push Node A and B have previously been configured in a way that they push
mappings in such a fashion and that Node A maintains state about the mappings in such a fashion and that Node A maintains state about the
mappings have to be pushed to Node B. No subscribe mechanism is mappings have to be pushed to Node B. No subscribe mechanism is
defined in this document that would allow Node B to tell Node A about defined in this document that would allow Node B to tell Node A about
what mappings it is interested nor a mechanism for learning to which what mappings it is interested nor a mechanism for learning to which
entities mappings have to be pushed. entities mappings have to be pushed.
skipping to change at page 9, line 32 skipping to change at page 9, line 31
| | | |
| <pushMappingsResponse> | | <pushMappingsResponse> |
|<-----------------------------| |<-----------------------------|
| | | |
| | | |
| | | |
Figure 6: Pushing Mappings with a <pushMappingsRequest> Message Figure 6: Pushing Mappings with a <pushMappingsRequest> Message
Note that in the exchange illustrated in Figure 6 Node A issuing the Note that in the exchange illustrated in Figure 6 Node A issuing the
first request and plays the role of the HTTP/HTTPS client (with HTTP first request and plays the role of the HTTPS client (with HTTP as
as selected transport) and Node B plays the role of the HTTP/HTTPS selected transport) and Node B plays the role of the HTTPS server.
server.
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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document reuses terminology introduced by the mapping This document reuses terminology introduced by the mapping
architecture document [RFC5582]. architecture document [RFC5582], such as 'coverage region', 'forest
guide', 'mapping', 'authoritative mapping server', etc..
Throughout this document we use the term LoST Sync source and LoST Throughout this document we use the term LoST Sync source and LoST
Sync destination to denote the protocol end points of the exchange. Sync destination to denote the protocol end points of the exchange.
The protocol is referred as LoST Sync within the text. The protocol is referred as LoST Sync within the text.
3. Querying for Mappings with a <getMappingsRequest> / 3. Querying for Mappings with a <getMappingsRequest> /
<getMappingsResponse> Exchange <getMappingsResponse> Exchange
3.1. Behavior of the LoST Sync Destination 3.1. Behavior of the LoST Sync Destination
skipping to change at page 12, line 39 skipping to change at page 12, line 39
</getMappingsRequest> </getMappingsRequest>
Figure 8: Example <getMappingsRequest> Message Figure 8: Example <getMappingsRequest> Message
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:gml="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 profile="urn:ietf:params:lost:location-profile:basic-civic">
profile="urn:ietf:params:lost:location-profile:basic-civic"> <civicAddress
<civicAddress xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> <country>US</country>
<country>US</country> <A1>NJ</A1>
<A1>NJ</A1> <A3>Leonia</A3>
<A3>Leonia</A3> <PC>07605</PC>
<PC>07605</PC> </civicAddress>
</civicAddress> </serviceBoundary>
</serviceBoundary> <uri>sip:police@leonianj2.example.org</uri>
<uri>sip:police@leonianj2.example.org</uri> <serviceNumber>911</serviceNumber>
<serviceNumber>911</serviceNumber> </mapping>
</mapping>
<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"> <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>37.775 -122.4194</gml:pos>
<gml:pos>37.775 -122.4194</gml:pos> <gml:pos>37.555 -122.4194</gml:pos>
<gml:pos>37.555 -122.4194</gml:pos> <gml:pos>37.555 -122.4264</gml:pos>
<gml:pos>37.555 -122.4264</gml:pos> <gml:pos>37.775 -122.4264</gml:pos>
<gml:pos>37.775 -122.4264</gml:pos> <gml:pos>37.775 -122.4194</gml:pos>
<gml:pos>37.775 -122.4194</gml:pos> </gml:LinearRing>
</gml:LinearRing> </gml:exterior>
</gml:exterior> </gml: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
4. Pushing Mappings via <pushMappings> and <pushMappingsResponse> 4. Pushing Mappings via <pushMappings> and <pushMappingsResponse>
4.1. Behavior of the LoST Sync Source 4.1. Behavior of the LoST Sync Source
When a LoST Sync source obtains new information that is of interest When a LoST Sync source obtains new information that is of interest
to its peers, it may push the new mappings to its peers. to its peers, it may push the new mappings to its peers.
Configuration settings at both peers decide whether this Configuration settings at both peers decide whether this
skipping to change at page 16, line 8 skipping to change at page 16, line 8
sourceId="7e3f40b098c711dbb606011111111111" lastUpdated="2008-11- sourceId="7e3f40b098c711dbb606011111111111" lastUpdated="2008-11-
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:pushMappings <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:gml="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 profile="urn:ietf:params:lost:location-profile:basic-civic">
profile="urn:ietf:params:lost:location-profile:basic-civic"> <civicAddress
<civicAddress xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> <country>US</country>
<country>US</country> <A1>NJ</A1>
<A1>NJ</A1> <A3>Leonia</A3>
<A3>Leonia</A3> <PC>07605</PC>
<PC>07605</PC> </civicAddress>
</civicAddress> </serviceBoundary>
</serviceBoundary> <uri>sip:police@leonianj.example.org</uri>
<uri>sip:police@leonianj.example.org</uri> <serviceNumber>911</serviceNumber>
<serviceNumber>911</serviceNumber> </mapping>
</mapping>
<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"> <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>37.775 -122.4194</gml:pos>
<gml:pos>37.775 -122.4194</gml:pos> <gml:pos>37.555 -122.4194</gml:pos>
<gml:pos>37.555 -122.4194</gml:pos> <gml:pos>37.555 -122.4264</gml:pos>
<gml:pos>37.555 -122.4264</gml:pos> <gml:pos>37.775 -122.4264</gml:pos>
<gml:pos>37.775 -122.4264</gml:pos> <gml:pos>37.775 -122.4194</gml:pos>
<gml:pos>37.775 -122.4194</gml:pos> </gml:LinearRing>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</serviceBoundary>
<uri>sip:nypd@example.com</uri>
<uri>xmpp:nypd@example.com</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<mapping source="nj.us.example" </gml:exterior>
sourceId="123" </gml:Polygon>
lastUpdated="2008-11-01T01:00:00Z" </serviceBoundary>
expires="2008-11-01T01:00:00Z"/> <uri>sip:nypd@example.com</uri>
<uri>xmpp:nypd@example.com</uri>
<serviceNumber>911</serviceNumber>
</mapping>
</sync:pushMappings> <mapping source="nj.us.example"
sourceId="123"
lastUpdated="2008-11-01T01:00:00Z"
expires="2008-11-01T01:00:00Z"/>
</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 18, line 20 skipping to change at page 18, line 4
<sync:notDeleted <sync:notDeleted
message="Could not delete the indicated mapping." message="Could not delete the indicated mapping."
xml:lang="en"> xml:lang="en">
<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:notDeleted> </sync:notDeleted>
</errors> </errors>
Figure 12: Example <errors> Message Figure 12: Example <errors> Message
5. Transport 5. Transport
LoST Sync needs an underlying protocol transport mechanism to carry LoST Sync needs an underlying protocol transport mechanism to carry
requests and responses. This document defines an XML protocol over requests and responses. This document uses HTTPS as a transport to
HTTP and over HTTP-over-TLS. Client and server developers are exchange XML documents. No fallback to HTTP is provided.
reminded that full support of RFC 2616 HTTP facilities is expected.
If clients or servers re-implement HTTP, rather than using available
servers or client code as a base, careful attention must be paid to
full interoperability. Other transport mechanisms are left to future
documents. The selection of the transport mechanism will in most
cases be determined through manual configuration although the usage
of the U-NAPTR application defined in the LoST specification is
possible. In protocols that support content type indication, LoST
Sync uses the media type application/lostsync+xml.
When using HTTP [RFC2616] and HTTP-over-TLS [RFC2818], LoST Sync When using HTTP-over-TLS [RFC2818], LoST Sync messages use the POST
messages use the HTTP POST method. The HTTP request MUST use the method. Request MUST use the Cache-Control response directive "no-
Cache-Control response directive "no-cache" to HTTP-level caching cache".
even by caches that have been configured to return stale responses to
client requests.
All LoST Sync responses, including those indicating a LoST warning or All LoST Sync responses, including those indicating a LoST warning or
error, are carried in 2xx responses, typically 200 (OK). Other 2xx error, are carried in 2xx responses, typically 200 (OK). Other 2xx
responses, in particular 203 (Non-authoritative information) may be responses, in particular 203 (Non-authoritative information) may be
returned by HTTP caches that disregard the caching instructions. 3xx, returned by HTTP caches that disregard the caching instructions. 3xx,
4xx and 5xx HTTP response codes indicates that the HTTP request 4xx and 5xx HTTP response codes indicates that the HTTP request
itself failed or was redirected; these responses do not contain any itself failed or was redirected; these responses do not contain any
LoST Sync XML elements. LoST Sync XML elements.
6. RelaxNG 6. RelaxNG
skipping to change at page 23, line 9 skipping to change at page 23, line 9
systems should be particularly suspicious if an existing coverage systems should be particularly suspicious if an existing coverage
region is replaced with a new one with a new mapping address. With region is replaced with a new one with a new mapping address. With
this mechanism it is also possible to avoid the distribution of this mechanism it is also possible to avoid the distribution of
mappings that have been modified by servers forwarding mappings as mappings that have been modified by servers forwarding mappings as
part of the synchronization procedure. part of the synchronization procedure.
8. Security Considerations 8. Security Considerations
This document defines a protocol for exchange of mapping information This document defines a protocol for exchange of mapping information
between two entities. Hence, the operations described in this between two entities. Hence, the operations described in this
document involve mutually-trusting LoST nodes. These nodes need to document involve mutually-trusting LoST nodes. These nodes MUST
authenticate each other, using mechanisms such as HTTP Digest authenticate each other, using mechanisms such as HTTP Digest
[RFC2617], HTTP Basic [RFC2617] over TLS [RFC5246] or TLS client and [RFC2617] over TLS, HTTP Basic [RFC2617] over TLS [RFC5246] or TLS
server certificates. Manual configuration for the setup of the client and server certificates. Manual configuration for the setup
peering relationships is required and hence the choice of the of the peering relationships is required and hence the choice of the
security mechanisms used between the two entities is a deployment security mechanisms used between the two entities is a deployment
specific decision. In any case, it MUST be ensured that the two end specific decision. In any case, TLS MUST be implemented and used.
points are authenticated and that a secure communication channel TLS provides a secure communication channel, an integrity and
(i.e., an integrity protected exchange of data with the help of the confidentiality protected exchange of data with the help of the TLS
TLS Record Layer) is setup to avoid the possibility of injecting Record Layer, and prevents intermediaries to injecting bogus
bogus mappings. If an adversary manages to inject false mappings mappings.
then this could lead to denial of service attacks. If the mapping
data contains a URL that does not exist then emergency services for An additional threat is caused by compromised or misconfigured LoST
the indicated area are not reachable. If all mapping data contains servers. A denial of service could be the consequence of an injected
URLs that point to a single PSAP (rather than a large number) then mapping. If the mapping data contains an URL that does not exist
this PSAP is likely to experience overload conditions. If the then emergency services for the indicated area are not reachable. If
mapping data contains a URL that points to a server controlled by the all mapping data contains URLs that point to a single PSAP (rather
adversary itself then it might impersonate PSAPs. than a large number of PSAPs) then this PSAP is likely to experience
overload conditions. If the mapping data contains a URL that points
to a server controlled by the adversary itself then it might
impersonate PSAPs. Section 7 discusses this issue and recommends
individually signed mappings. For unusal changes to the mapping
database approval by an expert may be required before any mappings
are installed.
9. IANA Considerations 9. IANA Considerations
9.1. Content-type registration for 'application/lostsync+xml' 9.1. Content-type registration for 'application/lostsync+xml'
This specification requests the registration of a new MIME type This specification requests the registration of a new MIME type
according to the procedures of RFC 4288 [RFC4288] and guidelines in according to the procedures of RFC 4288 [RFC4288] and guidelines in
RFC 3023 [RFC3023]. RFC 3023 [RFC3023].
Type name: application Type name: application
Subtype name: lostsync+xml Subtype name: lostsync+xml
Required parameters: none Required parameters: none
Optional parameters: charset Optional parameters: charset
Indicates the character encoding of enclosed XML. Indicates the character encoding of enclosed XML.
Encoding considerations: Uses XML, which can employ 8-bit Encoding considerations: Identical to those of "application/xml" as
characters, depending on the character encoding used. See RFC described in RFC 3023 [RFC3023], Section 3.2.
3023 [RFC3023], Section 7.1.
Security considerations: This content type is designed to carry LoST Security considerations: This content type is designed to carry LoST
Syncronization protocol payloads described in RFCXXXX. [NOTE TO Synchronization protocol payloads described in RFCXXXX. The
IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this security considerations section of RFCXXXX is applicable. In
specification.] addition, as this media type uses the "+xml" convention, it shares
the same security considerations as described in RFC 3023
[RFC3023], Section 10. [NOTE TO IANA/RFC-EDITOR: Please replace
XXXX with the RFC number of this specification.]
Interoperability considerations: None Interoperability considerations: None
Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number of this specification.] replace XXXX with the RFC number of this specification.]
Applications which use this media type: Emergency and Location-based Applications which use this media type: Emergency and Location-based
Systems Systems
Additional information: Additional information:
skipping to change at page 27, line 16 skipping to change at page 27, line 16
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 We would like to particularly thank Andrew Newton for his timely and
valuable review of the XML-related content. valuable review of the XML-related content.
We would like to thank Robert Sparks for his AD review feedback, and We would like to thank Robert Sparks for his AD review feedback,
Bjoern Hoehrmann for his media type review. Bjoern Hoehrmann for his media type review, and Julian Reschke for
his applications area review.
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
 End of changes. 31 change blocks. 
169 lines changed or deleted 164 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/