One document matched: draft-ietf-ecrit-lost-sync-01.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 compact="yes"?>
<rfc ipr="full3978" category="std" docName="draft-ietf-ecrit-lost-sync-01">
<front>
<title abbrev="LoST Sync">Synchronizing Location-to-Service Translation
(LoST) Servers</title>
<author initials="H." surname="Schulzrinne" fullname="Henning Schulzrinne">
<organization abbrev="Columbia U.">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 initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization abbrev="NSN">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="2008"/>
<area>RAI</area>
<workgroup>ECRIT</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Location</keyword>
<abstract>
<t>The LoST (Location-to-Service Translation) protocol is used to map
locations to service URLs. This document defines a set of LoST
extensions that allow LoST servers to synchronize their lists of
mappings.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The <xref target="RFC5222">LoST (Location-to-Service
Translation) protocol</xref> maps geographic locations to service URLs.
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 a global, scalable and resilient mapping
service. The LoST protocol specification only describes the protocol
used for individual seeker-originated queries. This document adds LoST
operations that 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 remove a
non-existent mapping, the query is silently ignored.</t>
<t>The response to a <pushMappings> request is a
<pushMappingsResponse>, currently without additional elements, if the
request was successful or an <errors> response if the request failed.
Only the <badRequest>, <forbidden>, <internalError> or
<serverTimeout> errors defined in Section 13.1 of <xref
target="RFC5222"/> are used. Neither the <redirect> nor the
<warnings> messages are used for this query.</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,
giving 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"/>. In the
example, the mappings with sourceId 7e3f40b098c711dbb6060800200c9a66
sourceId 7e3f40b098c711dbb606011111111111 are added by the recipient.
The last mapping, with source 'nj.us.example' and sourceID 'englewood',
is removed.</t>
<t>
<figure anchor="pushMappings"
title="Example <pushMappings>">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<sync:pushMappings
xmlns:sync="urn:ietf:params:xml:ns:lost-sync1"
xmlns:p2="http://www.opengis.net/gml"
xmlns="urn:ietf:params:xml:ns:lost1:sync">
<sync:mappings>
<mapping source="leonia.nj.us.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@leonianj.example.org</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<mapping source="authoritative.example"
sourceId="7e3f40b098c711dbb606011111111111"
expires="2009-01-01T01:44:33Z"
lastUpdated="2008-11-01T01:00:00Z">
<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@example.com</uri>
<uri>xmpp:nypd@example.com</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<mapping source="nj.us.example"
sourceId="englewood"
lastUpdated="2008-11-01T01:00:00Z"
expires="2008-11-01T01:00:00Z"/>
</sync:mappings>
</sync:pushMappings>
]]></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" />
</pushMappingsResponse>
]]></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 the
example, the queried node did not have anything newer for mapping
7e3f40b098c711dbb606011111111111, but did have a mapping with sourceId
7b7c9630-a93b-11dd-ad8b-0800200c9a66 that matched the source parameter
'authoritative.example'.</t>
<t><figure anchor="getMappings"
title="Example <getMappings> request">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<getMappings xmlns="urn:ietf:params:xml:ns:lost1:sync"
source="authoritative.example">
<m sourceId="7e3f40b098c711dbb606011111111111"
lastUpdated="2008-11-26T01:00:00Z" />
</getMappings>
]]></artwork>
</figure>
</t>
<t><figure anchor="getMappingsResponse"
title="Example <getMappingsResponse>">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<sync:getMappingsResponse
xmlns="urn:ietf:params:xml:ns:lost1:sync"
xmlns:sync="urn:ietf:params:xml:ns:lost-sync1">
<sync:mappings>
<mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="authoritative.example"
sourceId="7b7c9630-a93b-11dd-ad8b-0800200c9a66"
<displayName xml:lang="en">
Englewood Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary profile="civic">
...
</serviceBoundary>
<uri>sip:police@englewood.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.</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:32:19 |