One document matched: draft-ietf-ecrit-lost-sync-02.xml
<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2617 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2617.xml'>
<!ENTITY rfc5222 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5222.xml'>
<!ENTITY rfc5246 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml'>
<!ENTITY I-D.ietf-ecrit-mapping-arch PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-mapping-arch.xml'>
]>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<rfc ipr="trust200811" category="std" docName="draft-ietf-ecrit-lost-sync-02.txt">
<front>
<title abbrev="LoST Sync">Synchronizing Location-to-Service Translation
(LoST) Protocol based Service Boundaries and Mapping Elements</title>
<author initials="H." surname="Schulzrinne" fullname="Henning Schulzrinne">
<organization>Columbia University</organization>
<address>
<postal>
<street>Department of Computer Science</street>
<street>450 Computer Science Building</street>
<city>New York</city>
<region>NY</region>
<code>10027</code>
<country>US</country>
</postal>
<phone>+1 212 939 7004</phone>
<email>hgs+ecrit@cs.columbia.edu</email>
<uri>http://www.cs.columbia.edu</uri>
</address>
</author>
<author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<date year="2009"/>
<area>RAI</area>
<workgroup>ECRIT</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Location</keyword>
<abstract>
<t>The Location-to-Service Translation (LoST) protocol is an XML-based protocol for
mapping service identifiers and geodetic or civic location information to service
URIs and service boundaries. In particular, it can be used to determine the
location-appropriate Public Safety Answering Point (PSAP) for emergency services. </t>
<t>The main data structure, the XML <mapping> element, used for
encapsulating information about service boundaries is defined in the LoST protocol
specification and circumscribes the region within which all locations map to the
same service URI or set of URIs for a given service.</t>
<t>This document defines an XML protocol to exchange these mappings between two nodes.
As motived in the Location-to-URL Mapping Architecture document this mechanism is
useful for the synchronization of top-level LoST Forest Guides. This document is,
however, even useful in a deployment that does not make use of the LoST protocol but
purely wants to distribute service boundaries. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The <xref target="RFC5222">LoST (Location-to-Service Translation) protocol</xref>
maps service identifiers and geodetic or civic location information to service URIs.
As specified in the <xref target="I-D.ietf-ecrit-mapping-arch">LoST architecture
description</xref>, there are a variety of LoST servers that cooperate to
provide an ubiquitous, globally scalable and resilient mapping service. The LoST
protocol specification only describes the protocol used for individual
seeker-originated queries. This document allow forest guides, resolver clusters and
authoritative servers to synchronize their database of mappings.</t>
<t>In the LoST architecture, servers can peer, i.e., have an on-going data exchange
relationship. Peering relationships are set up manually, based on local policies. A
server can peer with any number of other servers. Forest guides peer with other
forest guides; resolvers peer with forest guides and other resolvers (in the same
cluster); authoritative mapping servers peer with forest guides and other
authoritative servers, either in the same cluster or above or below them in the
tree. If the type of LoST role does not matter, we refer to LoST protocol
participants as LoST nodes.</t>
<t>Authoritative mapping servers push coverage 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 covers.</t>
<t>The coverage regions of different authoritative servers can overlap. This should only
happen if the authoritative servers are misconfigured or if there is a political
dispute that involves competing claims for the same region. A server MUST detect
such colliding claims and implement a policy to resolve the collision, either
through an automated policy mechanism or manual intervention.</t>
<t>This extension defines two new requests, <pushMappings> and
<getMappings>, that allow peering servers to exchange mappings. These
requests are used for all peering relationships and always contain mapping entries,
but naturally the content of the data exchanged differs. <pushMappings>
allows a peer to send newer mappings to another peer; with a <getMappings>
query, a node can obtain mappings that are newer than those it already has.</t>
</section>
<section anchor="terminology" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as
described in RFC 2119 <xref target="RFC2119"/>.</t>
<t>This document reuses terminology introduced by the <xref
target="I-D.ietf-ecrit-mapping-arch">mapping architecture document</xref>.</t>
</section>
<section
title="Distributing Mappings via <pushMappings> and
<pushMappingsResponse>">
<t>When a LoST node obtains new information that is of interest to its peers, it pushes
the new mappings to its peers. This information might arrive through non-LoST means,
such as a manual addition to the local mappings database, or through another LoST
node, via a <pushMappings> request or a <getMappingsResponse>
described later.</t>
<t>Each peer keeps track of which peer it has exchanged which mapping elements with. As
discussed in Section 5.1 of <xref target="RFC5222"/>, mapping elements are
identified by the 'source', 'sourceID' and 'lastUpdated' attributes. A mapping is
considered the same if these three attributes match. Nodes never push the same
information to the same peer twice.</t>
<t>To delete a mapping, the content of the mapping is left empty. The node can delete
the mapping from its internal mapping database, but has to remember which peers it
has distributed this update to. The 'expires' attribute is required, but ignored. If
the querier attempts to delete a non-existent mapping, the query is silently
ignored.</t>
<t>The response to a <pushMappings> request is a <pushMappingsResponse>
message. Currently, a successful response message returns no additional elements,
whereas an <errors> response is returned in the response message, if the
request failed. Only the <badRequest>, <forbidden>,
<internalError> or <serverTimeout> errors defined in Section 13.1 of
<xref target="RFC5222"/>, are used. The <redirect> and <warnings>
messages are not used for this query/response." </t>
<t>If the set of nodes that are synchronizing their data does not form a tree, it is
possible that the same information arrives through several other nodes. This is
unavoidable, but generally only imposes a modest overhead. (It would be possible to
create a spanning tree in the same fashion as IP multicast, but the complexity does
not seem warranted, given the relatively low volume of data.)</t>
<t>A newly received mapping M' replaces an existing mapping M if all of the following
conditions hold: <list style="numbers">
<t>M'.source equals M.source, ignoring case</t>
<t>M'.sourceID' equals M.sourceID, ignoring case</t>
<t>M'.lastUpdated greater or equal to M.lastUpdated</t>
</list>
</t>
<t> An example is shown in <xref target="pushMappings"/>. Image a LoST node that
obtained two new mappings identified as follows: <list style="symbols">
<t> source="authoritative.example" sourceId="7e3f40b098c711dbb6060800200c9a66"
lastUpdated="2008-11-26T01:00:00Z" </t>
<t>source="authoritative.example" sourceId="7e3f40b098c711dbb606011111111111"
lastUpdated="2008-11-01T01:00:00Z" </t>
</list>
</t>
<t> These two mappings have to be added to the peer's mapping database. </t>
<t> Additionally, it determines that the following mapping has to be deleted: <list
style="symbols">
<t> source="nj.us.example" sourceId="123" lastUpdated="2008-11-01T01:00:00Z"
</t>
</list>
</t>
<t>
<figure anchor="pushMappings" title="Example <pushMappings>">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<sync:pushMappingsRequest
xmlns:sync="urn:ietf:params:xml:ns:lost-sync1"
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml";>
<sync:mappings>
<mapping source="authoritative.example"
sourceId="7e3f40b098c711dbb6060800200c9a66"
lastUpdated="2008-11-26T01:00:00Z"
expires="2009-12-26T01:00:00Z">
<displayName xml:lang="en">
Leonia Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary
profile="urn:ietf:params:lost:location-profile:basic-civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>US</country>
<A1>NJ</A1>
<A3>Leonia</A3>
<PC>07605</PC>
</civicAddress>
</serviceBoundary>
<uri>sip:police at leonianj.example.org</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<mapping expires="2009-01-01T01:44:33Z"
lastUpdated="2008-11-01T01:00:00Z"
source="authoritative.example"
sourceId="7e3f40b098c711dbb606011111111111">
<displayName xml:lang="en">
New York City Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary profile="geodetic-2d">
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior>
<p2:LinearRing>
<p2:pos>37.775 -122.4194</p2:pos>
<p2:pos>37.555 -122.4194</p2:pos>
<p2:pos>37.555 -122.4264</p2:pos>
<p2:pos>37.775 -122.4264</p2:pos>
<p2:pos>37.775 -122.4194</p2:pos>
</p2:LinearRing>
</p2:exterior>
</p2:Polygon>
</serviceBoundary>
<uri>sip:nypd at example.com</uri>
<uri>xmpp:nypd at example.com</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<mapping source="nj.us.example"
sourceId="123"
lastUpdated="2008-11-01T01:00:00Z"
expires="2008-11-01T01:00:00Z"/>
</sync:mappings>
</sync:pushMappingsRequest>
]]></artwork>
</figure>
</t>
<t>In response, the peer performs the necessary operation and updates its mapping
database. In particular, it will check whether the querier is authorized to perform
the update and whether the elements and attributes contain values that it
understands. In our example, a positive response is returned as shown in <xref
target="pushMappingsResponse"/>.</t>
<t>
<figure anchor="pushMappingsResponse" title="Example <pushMappingsResponse>">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<pushMappingsResponse xmlns="urn:ietf:params:xml:ns:lost1:sync" />
]]></artwork>
</figure>
</t>
</section>
<section
title="Synchronizing Mapping Stores via <getMappings>
and <getMappingsResponse>">
<t>Instead of pushing mappings to another LoST node, a LoST client can declare all the
mappings it has, via a sequence of <m> elements in the <getMappings>,
and then obtain any missing or outdated mappings in the
<getMappingsResponse>. Specifying the existing mappings avoids retransmitting
data that the querier has already stored.</t>
<t>If the <getMappings> query has no attributes, the <getMappingsResponse>
contains all mappings that are either newer than the <m> elements or not
contained in the sequence of <m> elements. The querier can restrict the
mappings returned by adding 'source' and 'sourceId' attributes to the
<getMappings> query. Only the combinations <list style="symbols">
<t>source</t>
<t>source, sourceID</t>
</list> are allowed.</t>
<t>If the 'source' attribute is specified, only mappings with that particular source
attribute are considered. Similarly, the 'sourceId' attribute restricts mappings to
those matching the attribute from the 'source' named.</t>
<t><m> elements MUST only contain the 'source', 'sourceId' and 'lastUpdated'
attributes that are not contained in the <GetMappings> element itself. Extra
attributes that do not match the values of the <getMappings> attributes are
silently ignored. (This structure reduces the query size for the common case that
there are many mappings from the same source.)</t>
<t>Processing a <getMappings> message may lead to a successful response in the
form of a &tl;getMappingsResponse> or an <errors> message. Only the
<badRequest>, <forbidden>, <internalError>,
<serverTimeout> errors defined in <xref target="RFC5222"/> are used. Neither
the <redirect> nor the <warnings> messages are used for this query.</t>
<t>An example request is shown in <xref target="getMappings"/>, the corresponding
response in <xref target="getMappingsResponse"/>. In this example a LoST node
requests a specific mapping for source="authoritative.bar.example" and
sourceId="7e3f40b098c711dbb6060800200c9a66" that is fresher than
"2006-11-01T01:00:00Z". Additionally, all mappings that match
source="authoritative.foo.example" are requested. </t>
<t>
<figure anchor="getMappings" title="Example <getMappings> request">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<getMappingsRequest xmlns="urn:ietf:params:xml:ns:lost-sync1">
<m source="authoritative.bar.example"
sourceId="7e3f40b098c711dbb6060800200c9a66"
lastUpdated="2006-11-01T01:00:00Z"/>
<m source="authoritative.foo.example"/>
</getMappingsRequest>
]]></artwork>
</figure>
</t>
<t>The response is shown in <xref target="getMappingsResponse"/>. A more recent mapping
was available with the identification of source="authoritative.bar.example" and
sourceId="7e3f40b098c711dbb6060800200c9a66". Only one mapping that matched
source="authoritative.foo.example" was found and returned. </t>
<t>
<figure anchor="getMappingsResponse" title="Example <getMappingsResponse>">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<sync:getMappingsResponse
xmlns:sync="urn:ietf:params:xml:ns:lost-sync1"
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml";>
<sync:mappings>
<mapping source="authoritative.bar.example"
sourceId="7e3f40b098c711dbb6060800200c9a66"
lastUpdated="2008-11-26T01:00:00Z"
expires="2009-12-26T01:00:00Z">
<displayName xml:lang="en">
Leonia Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary
profile="urn:ietf:params:lost:location-profile:basic-civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>US</country>
<A1>NJ</A1>
<A3>Leonia</A3>
<PC>07605</PC>
</civicAddress>
</serviceBoundary>
<uri>sip:police at leonianj2.example.org</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<mapping expires="2009-01-01T01:44:33Z"
lastUpdated="2008-11-01T01:00:00Z"
source="authoritative.foo.example"
sourceId="7e3f40b098c711dbb606011111111111">
<displayName xml:lang="en">
New York City Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary profile="geodetic-2d">
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior>
<p2:LinearRing>
<p2:pos>37.775 -122.4194</p2:pos>
<p2:pos>37.555 -122.4194</p2:pos>
<p2:pos>37.555 -122.4264</p2:pos>
<p2:pos>37.775 -122.4264</p2:pos>
<p2:pos>37.775 -122.4194</p2:pos>
</p2:LinearRing>
</p2:exterior>
</p2:Polygon>
</serviceBoundary>
<uri>sip:nypd at example.com</uri>
<uri>xmpp:nypd at example.com</uri>
<serviceNumber>911</serviceNumber>
</mapping>
</sync:mappings>
</sync:getMappingsResponse>
]]></artwork>
</figure>
</t>
</section>
<section title="Security Considerations">
<t>The LoST security considerations are discussed in <xref target="RFC5222"/>. The
operations described in this document involve mutually-trusting LoST nodes. These
nodes need to authenticate each other, using mechanisms such as <xref
target="RFC2617">HTTP Digest</xref>, <xref target="RFC2617">HTTP Basic</xref>
over <xref target="RFC5246">TLS</xref> or TLS client and server certificates. Nodes
implementing LoST MUST implement HTTP Basic authentication over TLS and MAY
implement other authentication mechanisms.</t>
</section>
<section title="IANA Considerations">
<section title="LoST Synchronization Namespace Registration">
<t>
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:ns:lost1:sync</t>
<t hangText="Registrant Contact:">IETF ECRIT Working Group, Henning
Schulzrinne (hgs@cs.columbia.edu).</t>
<t hangText="XML:">
<figure>
<artwork><![CDATA[
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>LoST Synchronization Namespace</title>
</head>
<body>
<h1>Namespace for LoST server synchronization</h1>
<h2>urn:ietf:params:xml:ns:lost1:sync</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX
[NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this
specification.]</a>.</p>
</body>
</html>
END
]]></artwork>
</figure>
</t>
</list>
</t>
</section>
</section>
<section title="Acknowledgments">
<t>Robins George, Cullen Jennings and Andrew Newton provided helpful input. Jari
Urpalainen assisted with the Relax NG schema. We would also like to thank our PROTO
shepherd Roger Marshall for his help with the document.</t>
</section>
<section title="RelaxNG">
<figure>
<artwork><![CDATA[
<?xml version="1.0" encoding="utf-8"?>
<grammar ns="urn:ietf:params:xml:ns:lost-sync1"
xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<include href="lost.rng"/>
<start combine="choice">
<a:documentation> Location-to-Service Translation (LoST)
Synchronization Protocol</a:documentation>
<choice>
<ref name="pushMappings"/>
<ref name="pushMappingsResponse"/>
<ref name="getMappings"/>
<ref name="getMappingsResponse"/>
</choice>
</start>
<define name="pushMappings">
<element name="pushMappings">
<element name="mappings">
<oneOrMore>
<ref name="mapping"/>
</oneOrMore>
</element>
<ref name="extensionPoint"/>
</element>
</define>
<define name="pushMappingsResponse">
<element name="pushMappingsResponse">
<ref name="extensionPoint"/>
</element>
</define>
<define name="getMappings">
<element name="getMappings">
<choice>
<ref name="ScopeSource"/>
<ref name="ScopeSourceId"/>
</choice>
<oneOrMore>
<element name="m">
<choice>
<ref name="ScopeSource"/>
<ref name="ScopeSourceId"/>
<ref name="ScopeLastUpdated"/>
</choice>
</element>
</oneOrMore>
<ref name="extensionPoint"/>
</element>
</define>
<define name="getMappingsResponse">
<element name="getMappingsResponse">
<element name="mappings">
<oneOrMore>
<ref name="mapping"/>
</oneOrMore>
</element>
<ref name="extensionPoint"/>
</element>
</define>
<define name="ScopeSource">
<attribute name="source">
<data type="token"/>
</attribute>
</define>
<define name="ScopeSourceId">
<attribute name="source">
<data type="token"/>
</attribute>
<attribute name="sourceId">
<data type="token"/>
</attribute>
</define>
<define name="ScopeLastUpdated">
<attribute name="source">
<data type="token"/>
</attribute>
<attribute name="sourceId">
<data type="token"/>
</attribute>
<attribute name="lastUpdated">
<data type="dateTime"/>
</attribute>
</define>
</grammar>
]]></artwork>
</figure>
</section>
</middle>
<back>
<references title="Normative References"> &rfc2119; &rfc2617; &rfc5222;
&rfc5246; </references>
<references title="Informative References"> &I-D.ietf-ecrit-mapping-arch; </references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 04:34:09 |