draft-ietf-ecrit-lost-sync-03.txt   draft-ietf-ecrit-lost-sync-04.txt 
ECRIT H. Schulzrinne ECRIT H. Schulzrinne
Internet-Draft Columbia University Internet-Draft Columbia University
Intended status: Standards Track H. Tschofenig Intended status: Experimental H. Tschofenig
Expires: August 19, 2009 Nokia Siemens Networks Expires: September 8, 2009 Nokia Siemens Networks
February 15, 2009 March 7, 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-03.txt draft-ietf-ecrit-lost-sync-04.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 August 19, 2009. This Internet-Draft will expire on September 8, 2009.
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 Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
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 XML <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 URI or set of URIs for a given all locations map to the same service Uniform Resource Identifier
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. As motived in the Location-to-URL Mapping between two nodes. This mechanism can be used for bulk exchange of
Architecture document this mechanism is useful for the <mapping> elements between two entities. As such, this document can
synchronization of top-level LoST Forest Guides. This document is, also be used without the LoST protocol.
however, even useful in a deployment that does not make use of the
LoST protocol but purely wants to distribute service boundaries.
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. LoST Sync Client's Behavior . . . . . . . . . . . . . . . 8
3.2. LoST Sync Server's Behavior . . . . . . . . . . . . . . . 8 3.2. LoST Sync Server's Behavior . . . . . . . . . . . . . . . 8
3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Pushing Mappings via <pushMappings> and 4. Pushing Mappings via <pushMappings> and
<pushMappingsResponse> . . . . . . . . . . . . . . . . . . . . 12 <pushMappingsResponse> . . . . . . . . . . . . . . . . . . . . 11
4.1. LoST Sync Client's Behavior . . . . . . . . . . . . . . . 12 4.1. LoST Sync Client's Behavior . . . . . . . . . . . . . . . 11
4.2. LoST Sync Server's Behavior . . . . . . . . . . . . . . . 12 4.2. LoST Sync Server's Behavior . . . . . . . . . . . . . . . 11
4.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. RelaxNG . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. RelaxNG . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8.1. Content-type registration for 8.1. Content-type registration for
'application/lostsync+xml' . . . . . . . . . . . . . . . . 21 'application/lostsync+xml' . . . . . . . . . . . . . . . . 19
8.2. LoST Sync Relax NG Schema Registration . . . . . . . . . . 22 8.2. LoST Sync Relax NG Schema Registration . . . . . . . . . . 20
8.3. LoST Synchronization Namespace Registration . . . . . . . 22 8.3. LoST Synchronization Namespace Registration . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 25 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 25 10.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
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. As specified in the LoST architecture description service URIs. The main data structure, the <mapping> element, used
[I-D.ietf-ecrit-mapping-arch], LoST servers act in different roles for encapsulating information about service boundaries is defined in
that cooperate to provide an ubiquitous, globally scalable and the LoST protocol specification and circumscribes the region within
resilient mapping service. In the LoST mapping architecture, servers which all locations map to the same service Uniform Resource
can peer, i.e., have an on-going data exchange relationship. Peering Identifier (URI) or set of URIs for a given service.
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.
Authoritative mapping servers push coverage regions "up" the tree, This document enables a bulk exchange of <mapping> elements between
i.e., from child nodes to parent nodes. The child informs the parent two entities (the LoST Sync client and the LoST Sync server).
of the geospatial or civic region that it covers for a specific
service.
The coverage regions of different authoritative servers can overlap. The LoST Sync mechanism can, for example, be used in the LoST
This should only happen if the authoritative servers are architecture, as specified in the [I-D.ietf-ecrit-mapping-arch].
misconfigured or if there is a political dispute that involves There, LoST servers act in different roles that cooperate to
competing claims for the same region. A server must detect such provide an ubiquitous, globally scalable and resilient mapping
colliding claims and implement a policy to resolve the collision, service. In the LoST mapping architecture, servers can peer,
either through an automated policy mechanism or manual intervention. 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.
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 for a
specific service.
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 client and a LoST Sync server even through the roles are reversed for
the two available exchanges and logically the two nodes might often the two available exchanges and logically the two nodes might often
be peers than in a client-server relationship. Node A in the example be peers rather than in a client-server relationship. Node A in the
exchanges of Figure 1 and Figure 2 has mappings that Node B is going example of Figure 1 and Figure 2 has mappings that Node B is going to
to retrieve. retrieve.
The <getMappingsRequest> and <getMappingsResponse> exchange allows a The <getMappingsRequest> and <getMappingsResponse> exchange allows a
LoST Sync client to request mappings from a LoST Sync server. As LoST Sync client to request mappings from a LoST Sync server.
described in Section 3 the <getMappingsRequest> message may contain
further information to scope the retrieval of all available mappings
on the LoST Sync server node.
+---------+ +---------+ +---------+ +---------+
| 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 | | Client | | Server |
+---------+ +---------+ +---------+ +---------+
| | | |
skipping to change at page 5, line 32 skipping to change at page 5, line 32
| | | |
| | | |
Figure 1: Querying for Mappings with a <getMappingsRequest> Message Figure 1: Querying for Mappings with a <getMappingsRequest> Message
The <pushMappingsRequest> and <pushMappingsResponse> exchange allows The <pushMappingsRequest> and <pushMappingsResponse> exchange allows
a LoST Sync client to push mappings to LoST Sync server. The a LoST Sync client to push mappings to LoST Sync server. The
assumption is being made that Node A and B have previously been assumption is being made that Node A and B have previously been
configured in a way that they push mappings in such a fashion and configured in a way that they push mappings in such a fashion and
that Node A maintains state about the mappings that have to be pushed that Node A maintains state about the mappings that have to be pushed
to Node B. No subscribe alike mechanism is defined in this document to Node B. No subscribe mechanism is defined in this document that
that would allow Node B to tell Node A about what mappings it is would allow Node B to tell Node A about what mappings it is
interested. interested.
+---------+ +---------+ +---------+ +---------+
| 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 | | Client | | Server |
+---------+ +---------+ +---------+ +---------+
skipping to change at page 8, line 10 skipping to change at page 8, line 10
Throughout this document we use the term LoST Sync client and LoST Throughout this document we use the term LoST Sync client and LoST
Sync server to denote the protocol end points of the exchange. The Sync server to denote the protocol end points of the exchange. The
protocol is referred as LoST Sync within the text. 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. LoST Sync Client's Behavior
A LoST Sync client has a few ways to retrieve mapping elements from a A LoST Sync client has two ways to retrieve mapping elements from a
LoST Sync server node. A mechanisms that is suitable when no LoST Sync server node.
mappings are available on the client side is to submit an empty
<getMappingsRequest> message, as shown in Figure 3. The intent by
the client thereby is to retrieve all mappings from the other
communication peer. Note that the request is purely between the two
nodes and does not propagate further.
Next, a client that has already obtained mappings in previous 1. A mechanisms that is suitable when no mappings are available on
exchanges may want to check whether these mappings have been updated the client side is to submit an empty <getMappingsRequest>
in the meanwhile. The policy when to poll for updated mapping message, as shown in Figure 3. The intent by the LoST Sync
client thereby is to retrieve all mappings from the LoST Sync
server. Note that the request does not propagate further to
other nodes.
2. A client that has already obtained mappings in previous exchanges
may want to check whether these mappings have been updated in the
meanwhile. The policy when to poll for updated mapping
information is outside the scope of this document. The information is outside the scope of this document. The
<getMappingsRequest> message with one or multiple <exists> child <getMappingsRequest> message with one or multiple <exists> child
element(s) is a suitable mechanism to reduce the number of returned element(s) allows to reduce the number of returned mappings to
mappings to those that have been updated and also to obtain missing those that have been updated and also to those that are missing.
mappings.
Finally, a client may issue a <getMappingsRequest> message with one
or multiple <scope> child element(s). The query for mappings can be
restricted by adding 'source', 'sourceId' and 'service' attributes to
the <scope> element. If the 'source' attribute is specified, only
mappings from this particular source attribute MUST be returned.
Similarly, the 'sourceId' attribute restricts mappings to those
matching the attribute from the 'source' named. The same holds true
for the 'service' attribute. The comparison operation is a bit-wise
equality match.
In response to the <getMappingsRequest> message the client waits for In response to the <getMappingsRequest> message the client waits for
the <getMappingsResponse> message. In case of a successful response the <getMappingsResponse> message. In case of a successful response
the client stores the received mappings and determines which mappings the client stores the received mappings and determines which mappings
to replace. to replace.
3.2. LoST Sync Server's Behavior 3.2. LoST Sync Server's Behavior
When a LoST Sync server receives an empty <getMappingsRequest> When a LoST Sync server receives an empty <getMappingsRequest>
message then all locally available mappings MUST be returned message then all locally available mappings MUST be returned
skipping to change at page 9, line 8 skipping to change at page 8, line 48
authorized). authorized).
When a LoST Sync server receives a <getMappingsRequest> message with When a LoST Sync server 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.
When a LoST Sync server receives a <getMappingsRequest> message with
one or multiple <query> child element(s) then it MUST treat the
mappings returned of all <query> child elements with a union
operation, i.e. the results are concatinated with duplicates removed.
The number of mappings that are being returned by each individual
<query> element MUST be determined by looking at all the locally
available mappings and considering only those where the values of the
'source', 'sourceId' and 'service' attributes match. Note that a
query may have only one of these attributes set.
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 used 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 examples show the simplest <getMappingsRequest> message.
<?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 An further example request is shown in Figure 4, the corresponding
response in Figure 6. In this example a LoST node requests a response in Figure 5. In this example a LoST node requests a
specific mapping for source="authoritative.bar.example" and specific mapping for source="authoritative.bar.example" and
sourceId="7e3f40b098c711dbb6060800200c9a66" that is fresher than sourceId="7e3f40b098c711dbb6060800200c9a66" that is fresher 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
The following <getMappingsRequest> message quests all mappings that
where the 'source' attribute matches "authoritative.foo.example".
<?xml version="1.0" encoding="UTF-8"?>
<getMappingsRequest xmlns="urn:ietf:params:xml:ns:lostsync1">
<query>
<scope source="authoritative.bar.example"/>
</query>
</getMappingsRequest>
Figure 5: Example of scoped <getMappingsRequest> message Figure 4: Example <getMappingsRequest> Message
The response is shown in Figure 6. A more recent mapping was The response is shown in Figure 5. A more recent mapping was
available with the identification of 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 34 skipping to change at page 10, line 50
</p2:exterior> </p2:exterior>
</p2:Polygon> </p2: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 6: 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. LoST Sync Client's Behavior
When a LoST Sync node obtains new information that is of interest to When a LoST Sync node obtains new information that is of interest to
its peers, it MAY push the new mappings to its peers. Configuration its peers, it MAY push the new mappings to its peers. Configuration
settings at both peers decide whether this functionality is used. settings at both peers decide whether this functionality is used.
New mappings might arrive through non-LoST means, such as a manual New mappings may arrive through non-LoST means, such as a manual
addition to the local mappings database, or through the interaction addition to the local mappings database, or through the interaction
with other LoST nodes. Mappings may also be deleted and this may with other LoST nodes. Mappings may also be deleted and this may
trigger events. trigger events.
A sending node keeps track with which recipient it has exchanged A sending node keeps track with which recipient it has exchanged
mapping elements with. As discussed in Section 5.1 of [RFC5222], mapping elements with. As discussed in Section 5.1 of [RFC5222],
mapping elements are identified by the 'source', 'sourceID' and mapping elements are identified by the 'source', 'sourceID' and
'lastUpdated' attributes. A mapping is considered the same if these 'lastUpdated' attributes. A mapping is considered the same if these
three attributes match. LoST Sync nodes MUST NOT push the same three attributes match. It is RECOMMENDED not to push the same
information to the same peer twice. information to the same peer more than once.
A LoST Sync client MUST send a <pushMappings> request containing one A LoST Sync client MUST send a <pushMappings> request containing one
or more <mapping> elements. 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.
skipping to change at page 13, line 26 skipping to change at page 12, line 26
If the set of nodes that are synchronizing their data does not form a If the set of nodes that are synchronizing their data does not form a
tree, it is possible that the same information arrives through tree, it is possible that the same information arrives through
several other nodes. This is unavoidable, but generally only imposes several other nodes. This is unavoidable, but generally only imposes
a modest overhead. (It would be possible to create a spanning tree 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 in the same fashion as IP multicast, but the complexity does not seem
warranted, given the relatively low volume of data.) warranted, given the relatively low volume of data.)
4.3. Example 4.3. Example
An example is shown in Figure 7. Image a LoST node that obtained two An example is shown in Figure 6. Image a LoST node that obtained two
new mappings identified as follows: new mappings identified as follows:
o source="authoritative.example" o source="authoritative.example"
sourceId="7e3f40b098c711dbb6060800200c9a66" lastUpdated="2008-11- sourceId="7e3f40b098c711dbb6060800200c9a66" lastUpdated="2008-11-
26T01:00:00Z" 26T01:00:00Z"
o source="authoritative.example" o source="authoritative.example"
sourceId="7e3f40b098c711dbb606011111111111" lastUpdated="2008-11- sourceId="7e3f40b098c711dbb606011111111111" lastUpdated="2008-11-
01T01:00:00Z" 01T01:00:00Z"
skipping to change at page 15, line 10 skipping to change at page 14, line 10
<serviceNumber>911</serviceNumber> <serviceNumber>911</serviceNumber>
</mapping> </mapping>
<mapping source="nj.us.example" <mapping source="nj.us.example"
sourceId="123" sourceId="123"
lastUpdated="2008-11-01T01:00:00Z" lastUpdated="2008-11-01T01:00:00Z"
expires="2008-11-01T01:00:00Z"/> expires="2008-11-01T01:00:00Z"/>
</sync:pushMappingsRequest> </sync:pushMappingsRequest>
Figure 7: Example <pushMappingsRequest> Message Figure 6: 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 8. positive response is returned as shown in Figure 7.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<pushMappingsResponse xmlns="urn:ietf:params:xml:ns:lostsync1" /> <pushMappingsResponse xmlns="urn:ietf:params:xml:ns:lostsync1" />
Figure 8: Example <pushMappingsResponse> Figure 7: Example <pushMappingsResponse>
In case that a mapping could not be deleted as requested the In case that a mapping could not be deleted as requested the
following error response might be returned instead. following error response might be returned instead.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<errors xmlns="urn:ietf:params:xml:ns:lost1" <errors xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:sync="urn:ietf:params:xml:ns:lostsync1" xmlns:sync="urn:ietf:params:xml:ns:lostsync1"
source="nodeA.example.com"> source="nodeA.example.com">
<sync:notDeleted <sync:notDeleted
skipping to change at page 15, line 43 skipping to change at page 14, line 43
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 9: 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 the use of LoST Sync
over HTTP and LoST over HTTP-over-TLS. Client and server developers over HTTP and LoST over HTTP-over-TLS. Client and server developers
are reminded that full support of RFC 2616 HTTP facilities is are reminded that full support of RFC 2616 HTTP facilities is
expected. If LoST Sync clients or servers re-implement HTTP, rather expected. If LoST Sync clients or servers re-implement HTTP, rather
than using available servers or client code as a base, careful than using available servers or client code as a base, careful
attention must be paid to full interoperability. Other transport attention must be paid to full interoperability. Other transport
skipping to change at page 17, line 49 skipping to change at page 16, line 49
<define name="pushMappingsResponse"> <define name="pushMappingsResponse">
<element name="pushMappingsResponse"> <element name="pushMappingsResponse">
<ref name="extensionPoint"/> <ref name="extensionPoint"/>
</element> </element>
</define> </define>
<define name="getMappingsRequest"> <define name="getMappingsRequest">
<element name="getMappingsRequest"> <element name="getMappingsRequest">
<choice> <choice>
<ref name="exists"></ref> <ref name="exists"></ref>
<ref name="query"></ref>
<ref name="extensionPoint"/> <ref name="extensionPoint"/>
</choice> </choice>
</element> </element>
</define> </define>
<define name="exists"> <define name="exists">
<element name="exists"> <element name="exists">
<oneOrMore> <oneOrMore>
<element name="mapping-fingerprint"> <element name="mapping-fingerprint">
<attribute name="source"> <attribute name="source">
skipping to change at page 18, line 27 skipping to change at page 17, line 26
</attribute> </attribute>
<attribute name="lastUpdated"> <attribute name="lastUpdated">
<data type="dateTime"/> <data type="dateTime"/>
</attribute> </attribute>
<ref name="extensionPoint"/> <ref name="extensionPoint"/>
</element> </element>
</oneOrMore> </oneOrMore>
</element> </element>
</define> </define>
<define name="query">
<element name="query">
<oneOrMore>
<element name="scope">
<choice>
<attribute name="source">
<data type="token"/>
</attribute>
<attribute name="sourceId">
<data type="token"/>
</attribute>
<attribute name="service">
<data type="anyURI"/>
</attribute>
<ref name="extensionPoint"/>
</choice>
</element>
</oneOrMore>
<ref name="extensionPoint"/>
</element>
</define>
<define name="getMappingsResponse"> <define name="getMappingsResponse">
<element name="getMappingsResponse"> <element name="getMappingsResponse">
<oneOrMore> <oneOrMore>
<ref name="mapping"/> <ref name="mapping"/>
</oneOrMore> </oneOrMore>
<ref name="extensionPoint"/> <ref name="extensionPoint"/>
</element> </element>
</define> </define>
<!-- error messages --> <!-- error messages -->
skipping to change at page 25, line 40 skipping to change at page 23, line 40
Tschofenig, "LoST: A Location-to-Service Translation Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, August 2008. Protocol", RFC 5222, August 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
10.2. Informative References 10.2. Informative References
[I-D.ietf-ecrit-mapping-arch] [I-D.ietf-ecrit-mapping-arch]
Schulzrinne, H., "Location-to-URL Mapping Architecture and Schulzrinne, H., "Location-to-URL Mapping Architecture and
Framework", draft-ietf-ecrit-mapping-arch-03 (work in Framework", draft-ietf-ecrit-mapping-arch-04 (work in
progress), September 2007. progress), March 2009.
Authors' Addresses Authors' Addresses
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building 450 Computer Science Building
New York, NY 10027 New York, NY 10027
US US
 End of changes. 35 change blocks. 
148 lines changed or deleted 89 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/