draft-ietf-ecrit-lost-sync-06.txt   draft-ietf-ecrit-lost-sync-07.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: February 7, 2010 Nokia Siemens Networks Expires: February 10, 2010 Nokia Siemens Networks
August 6, 2009 August 9, 2009
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-06.txt draft-ietf-ecrit-lost-sync-07.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 7, 2010. This Internet-Draft will expire on February 10, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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
encapsulating information about service boundaries is defined in the encapsulating information about service boundaries is defined in the
LoST protocol specification and circumscribes the region within which LoST protocol specification and circumscribes the region within which
all locations map to the same service Uniform Resource Identifier all locations map to the same service Uniform Resource Identifier
(URI) or set of URIs for a given service. (URI) or set of URIs for a given service.
This document defines an XML protocol to exchange these mappings This document defines an XML protocol to exchange these mappings
between two nodes. This mechanism can be used for bulk exchange of between two nodes. This mechanism is designed for the exchange of
<mapping> elements between two entities. As such, this document can authoritative <mapping> elements between two entities. Exchanging
also be used without the LoST protocol. cached <mapping> elements, i.e. non-authoritative elements, is
possible but not envisioned. In any case, this document can also be
used without the LoST protocol even though the format of the
<mapping> element is re-used from the LoST specification.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Querying for Mappings with a <getMappingsRequest> / 3. Querying for Mappings with a <getMappingsRequest> /
<getMappingsResponse> Exchange . . . . . . . . . . . . . . . . 8 <getMappingsResponse> Exchange . . . . . . . . . . . . . . . . 8
3.1. LoST Sync Client's Behavior . . . . . . . . . . . . . . . 8 3.1. Behavior of the LoST Sync Source . . . . . . . . . . . . . 8
3.2. LoST Sync Server's Behavior . . . . . . . . . . . . . . . 8 3.2. Behavior of the LoST Sync Source . . . . . . . . . . . . . 8
3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Pushing Mappings via <pushMappings> and 4. Pushing Mappings via <pushMappings> and
<pushMappingsResponse> . . . . . . . . . . . . . . . . . . . . 11 <pushMappingsResponse> . . . . . . . . . . . . . . . . . . . . 11
4.1. LoST Sync Client's Behavior . . . . . . . . . . . . . . . 11 4.1. Behavior of the LoST Sync Source . . . . . . . . . . . . . 11
4.2. LoST Sync Server's Behavior . . . . . . . . . . . . . . . 11 4.2. Behavior of the LoST Sync Destination . . . . . . . . . . 11
4.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. RelaxNG . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. RelaxNG . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8.1. Content-type registration for 8.1. Content-type registration for
'application/lostsync+xml' . . . . . . . . . . . . . . . . 19 'application/lostsync+xml' . . . . . . . . . . . . . . . . 19
8.2. LoST Sync Relax NG Schema Registration . . . . . . . . . . 20 8.2. LoST Sync Relax NG Schema Registration . . . . . . . . . . 20
8.3. LoST Synchronization Namespace Registration . . . . . . . 20 8.3. LoST Synchronization Namespace Registration . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
skipping to change at page 4, line 15 skipping to change at page 4, line 15
1. Introduction 1. Introduction
The LoST (Location-to-Service Translation) protocol [RFC5222] maps The LoST (Location-to-Service Translation) protocol [RFC5222] maps
service identifiers and geodetic or civic location information to service identifiers and geodetic or civic location information to
service URIs. The main data structure, the <mapping> element, used service URIs. The main data structure, the <mapping> element, used
for encapsulating information about service boundaries is defined in for encapsulating information about service boundaries is defined in
the LoST protocol specification and circumscribes the region within the LoST protocol specification and circumscribes the region within
which all locations map to the same service Uniform Resource which all locations map to the same service Uniform Resource
Identifier (URI) or set of URIs for a given service. Identifier (URI) or set of URIs for a given service.
This document enables a bulk exchange of <mapping> elements between This mechanism is designed for the exchange of authoritative
two entities (the LoST Sync client and the LoST Sync server). <mapping> elements between two entities (the LoST Sync source and the
LoST Sync destination).
The LoST Sync mechanism can, for example, be used in the LoST The LoST Sync mechanism can, for example, be used in the LoST
architecture, as specified in the [I-D.ietf-ecrit-mapping-arch]. architecture, as specified in the [I-D.ietf-ecrit-mapping-arch].
There, LoST servers act in different roles that cooperate to There, LoST servers act in different roles that cooperate to provide
provide an ubiquitous, globally scalable and resilient mapping an ubiquitous, globally scalable and resilient mapping service. In
service. In the LoST mapping architecture, servers can peer, the LoST mapping architecture, LoST servers can peer, i.e., have an
i.e., have an on-going data exchange relationship. Peering on-going data exchange relationship. Peering relationships are set
relationships are set up manually, based on local policies. A up manually, based on local policies. A server can peer with any
server can peer with any number of other servers. Forest guides number of other servers. Forest guides peer with other forest
peer with other forest guides; resolvers peer with forest guides guides; resolvers peer with forest guides and other resolvers (in the
and other resolvers (in the same cluster); authoritative mapping same cluster); authoritative mapping servers peer with forest guides
servers peer with forest guides and other authoritative servers, and other authoritative servers, either in the same cluster or above
either in the same cluster or above or below them in the tree. or below them in the tree. Authoritative mapping servers push
Authoritative mapping servers push coverage regions "up" the tree, coverage regions "up" the tree, i.e., from child nodes to parent
i.e., from child nodes to parent nodes. The child informs the nodes. The child informs the parent of the geospatial or civic
parent of the geospatial or civic region that it covers for a region that it covers for a specific service.
specific service.
As an example consider the following two forest guides for two
countries, country Foo and country Bar. Country Foo has only 5 PSAPs
and the boundaries for fire, police and ambulance are identical.
Country Bar has a large number of PSAPs but their emergency services
architecture is designed in a way that all emergency calls are served
by a small number of replicated and highly available Emergency
Services Routing Proxies (ESRPs). These ESRPs give outside countries
the illusion of a single PSAP. From a call routing point of view a
ESRP receiving an emergency call performs location based routing to
forward calls to one of the large number of PSAPs.
Country Foo and country Bar utilize LoST Sync to keep their mappings
up-to-date. Every country is responsible for maintaining their own
mapping information and hence they configure their LoST Sync nodes in
a way that they exchange the respective mapping information. In this
case, the mapping data will be synchronized in both directions.
Since the amount of data being exchanged is small and the expected
rate of change is low the LoST Sync nodes are configured to always
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 1 and described by the exchange between two nodes as shown in Figure 1 and
Figure 2. The protocol exchange always runs between a LoST Sync Figure 2. The protocol exchange always runs between a LoST Sync
client and a LoST Sync server even through the roles are reversed for source and a LoST Sync destination. Node A in the examples of
the two available exchanges and logically the two nodes might often Figure 1 and Figure 2 has mappings that Node B is going to retrieve.
be peers rather than in a client-server relationship. Node A in the Node A acts as the source for the data and Node B is the destination.
example of Figure 1 and Figure 2 has mappings that Node B is going to
retrieve.
The <getMappingsRequest> and <getMappingsResponse> exchange allows a The <getMappingsRequest> request allows a LoST Sync source to request
LoST Sync client to request mappings from a LoST Sync server. mappings from a LoST Sync destination.
+---------+ +---------+ +---------+ +---------+
| Node B | | Node A | | Node B | | Node A |
| acting | | acting | | acting | | acting |
| as | | as | | as | | as |
| LoST | | LoST | | LoST | | LoST |
| Sync | | Sync | | Sync | | Sync |
| Client | | Server | | Dest. | | Source |
+---------+ +---------+ +---------+ +---------+
| | | |
| | | |
| | | |
| <getMappingsRequest> | | <getMappingsRequest> |
|----------------------------->| |----------------------------->|
| | | |
| <getMappingsResponse> | | <getMappingsResponse> |
|<-----------------------------| |<-----------------------------|
| | | |
| | | |
| | | |
Figure 1: Querying for Mappings with a <getMappingsRequest> Message Figure 1: Querying for Mappings with a <getMappingsRequest> Message
The <pushMappingsRequest> and <pushMappingsResponse> exchange allows Note that in the exchange illustrated in Figure 1 Node B issuing the
a LoST Sync client to push mappings to LoST Sync server. The first request and plays the role of the HTTP/HTTPS client (with HTTP
assumption is being made that Node A and B have previously been as selected transport) and Node A plays the role of the HTTP/HTTPS
configured in a way that they push mappings in such a fashion and server.
that Node A maintains state about the mappings that have to be pushed
to Node B. No subscribe mechanism is defined in this document that The <pushMappingsRequest> exchange allows a LoST Sync source to push
would allow Node B to tell Node A about what mappings it is mappings to LoST Sync destination. The assumption is being made that
interested. 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 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
what mappings it is interested nor a mechanism for learning to which
entities mappings have to be pushed.
+---------+ +---------+ +---------+ +---------+
| Node A | | Node B | | Node A | | Node B |
| acting | | acting | | acting | | acting |
| as | | as | | as | | as |
| LoST | | LoST | | LoST | | LoST |
| Sync | | Sync | | Sync | | Sync |
| Client | | Server | | Source | | Dest. |
+---------+ +---------+ +---------+ +---------+
| | | |
| | | |
| | | |
| <pushMappingsRequest> | | <pushMappingsRequest> |
|----------------------------->| |----------------------------->|
| | | |
| <pushMappingsResponse> | | <pushMappingsResponse> |
|<-----------------------------| |<-----------------------------|
| | | |
| | | |
| | | |
Figure 2: Pushing Mappings with a <pushMappingsRequest> Message Figure 2: Pushing Mappings with a <pushMappingsRequest> Message
Note that in the exchange illustrated in Figure 2 Node A issuing the
first request and plays the role of the HTTP/HTTPS client (with HTTP
as selected transport) and Node B plays the role of the HTTP/HTTPS
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 [I-D.ietf-ecrit-mapping-arch]. architecture document [I-D.ietf-ecrit-mapping-arch].
Throughout this document we use the term LoST Sync client and LoST Throughout this document we use the term LoST Sync source and LoST
Sync server to denote the protocol end points of the exchange. The Sync destination to denote the protocol end points of the exchange.
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. LoST Sync Client's Behavior 3.1. Behavior of the LoST Sync Source
A LoST Sync client has two ways to retrieve mapping elements from a A LoST Sync destination has two ways to retrieve mapping elements
LoST Sync server node. from a LoST Sync source.
1. A mechanisms that is suitable when no mappings are available on 1. A mechanisms that is suitable when no mappings are available on
the client side is to submit an empty <getMappingsRequest> the LoST Sync destination is to submit an empty
message, as shown in Figure 3. The intent by the LoST Sync <getMappingsRequest> message, as shown in Figure 3. The intent
client thereby is to retrieve all mappings from the LoST Sync by the LoST Sync destination thereby is to retrieve all mappings
server. Note that the request does not propagate further to from the LoST Sync source. Note that the request does not
other nodes. propagate further to other nodes.
2. A client that has already obtained mappings in previous exchanges 2. In case a LoST Sync destination node has already obtained
may want to check whether these mappings have been updated in the mappings in previous exchanges then it may want to check whether
meanwhile. The policy when to poll for updated mapping these mappings have been updated in the meanwhile. The policy
information is outside the scope of this document. The when to poll for updated mapping information is outside the scope
<getMappingsRequest> message with one or multiple <exists> child of this document. The <getMappingsRequest> message with one or
element(s) allows to reduce the number of returned mappings to multiple <exists> child element(s) allows to reduce the number of
those that have been updated and also to those that are missing. returned mappings to those that have been updated and also to
those that are missing.
In response to the <getMappingsRequest> message the client waits for In response to the <getMappingsRequest> message the LoST Sync
the <getMappingsResponse> message. In case of a successful response destination waits for the <getMappingsResponse> message. In case of
the client stores the received mappings and determines which mappings a successful response the LoST Sync destination stores the received
to replace. mappings and determines which mappings to replace.
3.2. LoST Sync Server's Behavior 3.2. Behavior of the LoST Sync Source
When a LoST Sync server receives an empty <getMappingsRequest> When a LoST Sync source receives an empty <getMappingsRequest>
message then all locally available mappings MUST be returned message then all locally available mappings MUST be returned.
(assuming that the client has been properly authenticated and
authorized).
When a LoST Sync server receives a <getMappingsRequest> message with When a LoST Sync source receives a <getMappingsRequest> message with
one or multiple <exists> child element(s) then it MUST consult with one or multiple <exists> child element(s) then it MUST consult with
the local mapping database to determine whether any of the mappings the local mapping database to determine whether any of the mappings
of the client is stale and whether there are mappings locally that of the client is stale and whether there are mappings locally that
the client does not yet have. The former can be determined by the client does not yet have. The former can be determined by
finding mappings corresponding to the 'source' and 'sourceID' finding mappings corresponding to the 'source' and 'sourceID'
attribut where a mapping with a more recent lastUpdated date exists. attribut where a mapping with a more recent lastUpdated date exists.
Processing a <getMappingsRequest> message MAY lead to a successful Processing a <getMappingsRequest> message MAY lead to a successful
response in the form of a <getMappingsResponse> or an <errors> response in the form of a <getMappingsResponse> or an <errors>
message. Only the <badRequest>, <forbidden>, <internalError>, message. Only the <badRequest>, <forbidden>, <internalError>,
<serverTimeout> errors, defined in [RFC5222], are utilized by this <serverTimeout> errors, defined in [RFC5222], are utilized by this
specification. Neither the <redirect> nor the <warnings> messages specification. Neither the <redirect> nor the <warnings> messages
are reused by this message. are reused by this message.
3.3. Examples 3.3. Examples
The first examples show the simplest <getMappingsRequest> message. The first example shows an empty <getMappingsRequest> message that
would retrieve all locally stored mappings at the LoST Sync source.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<getMappingsRequest xmlns="urn:ietf:params:xml:ns:lostsync1"/> <getMappingsRequest xmlns="urn:ietf:params:xml:ns:lostsync1"/>
Figure 3: Example of empty <getMappingsRequest> message Figure 3: Example of empty <getMappingsRequest> message
An further example request is shown in Figure 4, the corresponding A further example request is shown in Figure 4 and the corresponding
response in Figure 5. In this example a LoST node requests a response is depicted in Figure 5. In this example a request is made
specific mapping for source="authoritative.bar.example" and for a specific mapping (with source="authoritative.bar.example" and
sourceId="7e3f40b098c711dbb6060800200c9a66" that is fresher than sourceId="7e3f40b098c711dbb6060800200c9a66") that is more recent than
"2006-11-01T01:00:00Z". "2006-11-01T01:00:00Z".
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<getMappingsRequest xmlns="urn:ietf:params:xml:ns:lostsync1"> <getMappingsRequest xmlns="urn:ietf:params:xml:ns:lostsync1">
<exists> <exists>
<mapping-fingerprint source="authoritative.bar.example" <mapping-fingerprint source="authoritative.bar.example"
sourceId="7e3f40b098c711dbb6060800200c9a66" sourceId="7e3f40b098c711dbb6060800200c9a66"
lastUpdated="2006-11-01T01:00:00Z"> lastUpdated="2006-11-01T01:00:00Z">
</mapping-fingerprint> </mapping-fingerprint>
</exists> </exists>
</getMappingsRequest> </getMappingsRequest>
Figure 4: Example <getMappingsRequest> Message Figure 4: Example <getMappingsRequest> Message
The response is shown in Figure 5. A more recent mapping was The response to the above request is shown in Figure 5. A more
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:p2="http://www.opengis.net/gml">
skipping to change at page 11, line 7 skipping to change at page 11, line 7
<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 5: Example <getMappingsResponse> Message Figure 5: Example <getMappingsResponse> Message
4. Pushing Mappings via <pushMappings> and <pushMappingsResponse> 4. Pushing Mappings via <pushMappings> and <pushMappingsResponse>
4.1. LoST Sync Client's Behavior 4.1. Behavior of the LoST Sync Source
When a LoST Sync node obtains new information that is of interest to When a LoST Sync source obtains new information that is of interest
its peers, it MAY push the new mappings to its peers. Configuration to its peers, it may push the new mappings to its peers.
settings at both peers decide whether this functionality is used. Configuration settings at both peers decide whether this
New mappings may arrive through non-LoST means, such as a manual functionality is used and what mappings are pushed to which other
addition to the local mappings database, or through the interaction peers. New mappings may arrive through various means, such as a
with other LoST nodes. Mappings may also be deleted and this may manual addition to the local mapping database, or through the
trigger events. interaction with other entities. Deleting mappings may also trigger
a protocol interaction.
A sending node keeps track with which recipient it has exchanged The LoST Sync source SHOULD keep track to which LoST Sync destination
mapping elements with. As discussed in Section 5.1 of [RFC5222], it has pushed mapping elements. If it does not keep state
mapping elements are identified by the 'source', 'sourceID' and information then it always has to push the complete data set. As
'lastUpdated' attributes. A mapping is considered the same if these discussed in Section 5.1 of [RFC5222], mapping elements are
three attributes match. It is RECOMMENDED not to push the same identified by the 'source', 'sourceID' and 'lastUpdated' attributes.
information to the same peer more than once. A mapping is considered the same if these three attributes match. It
is RECOMMENDED not to push the same information to the same peer more
than once.
A LoST Sync client MUST send a <pushMappings> request containing one A <pushMappings> request sent by a LoST Sync source MUST containing
or more <mapping> elements. one or more <mapping> elements.
To delete a mapping, the content of the mapping is left empty. The To delete a mapping, the content of the mapping is left empty. The
node can delete the mapping from its internal mapping database, but node can delete the mapping from its internal mapping database, but
has to remember which peers it has distributed this update to. The has to remember which peers it has distributed this update to. The
'expires' attribute is required, but ignored. If an attempt is made 'expires' attribute is required, but ignored. If an attempt is made
to delete a non-existent mapping, the request is silently ignored. to delete a non-existent mapping, the request is silently ignored.
4.2. LoST Sync Server's Behavior 4.2. Behavior of the LoST Sync Destination
When a LoST Sync Server receives a <pushMappingsRequest> message then When a LoST Sync destination receives a <pushMappingsRequest> message
a newly received mapping M' MUST replace an existing mapping M if all then a newly received mapping M' MUST replace an existing mapping M
of the following conditions hold: if all of the following conditions hold:
1. M'.source equals M.source 1. M'.source equals M.source
2. M'.sourceID' equals M.sourceID 2. M'.sourceID' equals M.sourceID
3. M'.lastUpdated greater than M.lastUpdated 3. M'.lastUpdated is greater than M.lastUpdated
If the received mapping M' does not update any existing mapping M If the received mapping M' does not update any existing mapping M
then it MUST be added to the local cache as an independent mapping. then it MUST be added to the local cache as an independent mapping.
If a <pushMappingsRequest> message with an empty <mapping> element is If a <pushMappingsRequest> message with an empty <mapping> element is
received then a corresponding mapping has to be determined based on received then a corresponding mapping has to be determined based on
the 'source', 'sourceID' and 'lastUpdated' attributes. If a mapping the 'source', 'sourceID' and 'lastUpdated' attributes. If a mapping
has been found then it MUST be deleted. If no mapping can be has been found then it MUST be deleted. If no mapping can be
identified then an <errors> response MUST be returned that contains identified then an <errors> response MUST be returned that contains
the <notDeleted> child element. The <notDeleted> element MAY carry a the <notDeleted> child element. The <notDeleted> element MAY carry a
skipping to change at page 15, line 8 skipping to change at page 15, line 8
expires="2008-11-01T01:00:00Z"/> expires="2008-11-01T01:00:00Z"/>
</sync:notDeleted> </sync:notDeleted>
</errors> </errors>
Figure 8: Example <errors> Message Figure 8: 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 the use of LoST Sync requests and responses. This document defines an XML protocol over
over HTTP and LoST over HTTP-over-TLS. Client and server developers HTTP and over HTTP-over-TLS. Client and server developers are
are reminded that full support of RFC 2616 HTTP facilities is reminded that full support of RFC 2616 HTTP facilities is expected.
expected. If LoST Sync clients or servers re-implement HTTP, rather If clients or servers re-implement HTTP, rather than using available
than using available servers or client code as a base, careful servers or client code as a base, careful attention must be paid to
attention must be paid to full interoperability. Other transport full interoperability. Other transport mechanisms are left to future
mechanisms are left to future documents. The available transport documents. The selection of the transport mechanism will in most
mechanisms are determined through the use of the LoST U-NAPTR cases be determined through manual configuration although the usage
application. In protocols that support content type indication, LoST 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. Sync uses the media type application/lostsync+xml.
When using HTTP [RFC2616] and HTTP-over-TLS [RFC2818], LoST Sync When using HTTP [RFC2616] and HTTP-over-TLS [RFC2818], LoST Sync
messages use the HTTP POST method. The HTTP request MUST use the messages use the HTTP POST method. The HTTP request MUST use the
Cache-Control response directive "no-cache" to HTTP-level caching Cache-Control response directive "no-cache" to HTTP-level caching
even by caches that have been configured to return stale responses to even by caches that have been configured to return stale responses to
client requests. 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.
The HTTP URL is derived from the LoST Sync server name via U-NAPTR
application.
6. RelaxNG 6. RelaxNG
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<grammar ns="urn:ietf:params:xml:ns:lostsync1" <grammar ns="urn:ietf:params:xml:ns:lostsync1"
xmlns="http://relaxng.org/ns/structure/1.0" xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<include href="lost.rng"/> <include href="lost.rng"/>
skipping to change at page 18, line 7 skipping to change at page 18, line 7
<ref name="basicException"/> <ref name="basicException"/>
<oneOrMore> <oneOrMore>
<ref name="mapping"/> <ref name="mapping"/>
</oneOrMore> </oneOrMore>
</element> </element>
</define> </define>
</grammar> </grammar>
7. Security Considerations 7. Security Considerations
The LoST security considerations are discussed in [RFC5222]. The This document defines a protocol for exchange of mapping information
operations described in this document involve mutually-trusting LoST between two entities. Hence, the operations described in this
nodes. These nodes need to authenticate each other, using mechanisms document involve mutually-trusting LoST nodes. These nodes need to
such as HTTP Digest [RFC2617], HTTP Basic [RFC2617] over TLS authenticate each other, using mechanisms such as HTTP Digest
[RFC5246] or TLS client and server certificates. [RFC2617], HTTP Basic [RFC2617] over TLS [RFC5246] or TLS client and
server certificates. Manual configuration for the setup of the
peering relationships is required and hence the choice of the
security mechanisms used between the two entities is a deployment
specific decision. In any case, it MUST be ensured that the two end
points are authenticated and that a secure communication channel
(i.e., an integrity protected exchange of data with the help of the
TLS Record Layer) is setup to avoid the possibility of injecting
bogus mappings. If an adversary manages to inject false 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
the indicated area are not reachable. If all mapping data contains
URLs that point to a single PSAP (rather than a large number) 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.
8. IANA Considerations 8. IANA Considerations
8.1. Content-type registration for 'application/lostsync+xml' 8.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].
MIME media type name: application MIME media type name: application
 End of changes. 36 change blocks. 
117 lines changed or deleted 164 lines changed or added

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