idnits 2.17.1 

draft-ietf-ecrit-lost-sync-18.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
     document.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  -- The document date (July 10, 2012) is 3860 days in the past.  Is this
     intentional?


  Checking references for intended status: Experimental
  ----------------------------------------------------------------------------

  == Unused Reference: 'RFC2616' is defined on line 1057, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC2617' is defined on line 1061, but no explicit
     reference was found in the text

  ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346)

  ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
     RFC 7232, RFC 7233, RFC 7234, RFC 7235)

  ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615,
     RFC 7616, RFC 7617)

  ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110)

  ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303)

  ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838)

  ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)


     Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------


2	ECRIT                                                     H. Schulzrinne
3	Internet-Draft                                       Columbia University
4	Intended status: Experimental                              H. Tschofenig
5	Expires: January 11, 2013                         Nokia Siemens Networks
6	                                                           July 10, 2012

8	  Synchronizing Location-to-Service Translation (LoST) Protocol based
9	                Service Boundaries and Mapping Elements
10	                   draft-ietf-ecrit-lost-sync-18.txt

12	Abstract

14	   The Location-to-Service Translation (LoST) protocol is an XML-based
15	   protocol for mapping service identifiers and geodetic or civic
16	   location information to service URIs and service boundaries.  In
17	   particular, it can be used to determine the location-appropriate
18	   Public Safety Answering Point (PSAP) for emergency services.

20	   The <mapping> element is used to encapsulate information about
21	   service boundaries is defined in the LoST protocol specification and
22	   circumscribes the region within which all locations map to the same
23	   service Uniform Resource Identifier (URI) or set of URIs for a given
24	   service.

26	   This document defines an XML protocol to exchange these mappings
27	   between two nodes.  This mechanism is designed for the exchange of
28	   authoritative <mapping> elements between two entities.  Exchanging
29	   cached <mapping> elements, i.e. non-authoritative elements, is
30	   possible but not envisioned.  In any case, this document can also be
31	   used without the LoST protocol even though the format of the
32	   <mapping> element is re-used from the LoST specification.

34	Status of this Memo

36	   This Internet-Draft is submitted in full conformance with the
37	   provisions of BCP 78 and BCP 79.

39	   Internet-Drafts are working documents of the Internet Engineering
40	   Task Force (IETF).  Note that other groups may also distribute
41	   working documents as Internet-Drafts.  The list of current Internet-
42	   Drafts is at http://datatracker.ietf.org/drafts/current/.

44	   Internet-Drafts are draft documents valid for a maximum of six months
45	   and may be updated, replaced, or obsoleted by other documents at any
46	   time.  It is inappropriate to use Internet-Drafts as reference
47	   material or to cite them other than as "work in progress."
48	   This Internet-Draft will expire on January 11, 2013.

50	Copyright Notice

52	   Copyright (c) 2012 IETF Trust and the persons identified as the
53	   document authors.  All rights reserved.

55	   This document is subject to BCP 78 and the IETF Trust's Legal
56	   Provisions Relating to IETF Documents
57	   (http://trustee.ietf.org/license-info) in effect on the date of
58	   publication of this document.  Please review these documents
59	   carefully, as they describe your rights and restrictions with respect
60	   to this document.  Code Components extracted from this document must
61	   include Simplified BSD License text as described in Section 4.e of
62	   the Trust Legal Provisions and are provided without warranty as
63	   described in the Simplified BSD License.

65	Table of Contents

67	   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
68	   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
69	   3.  A Motivating Example . . . . . . . . . . . . . . . . . . . . .  6
70	   4.  Querying for Mappings with a <getMappingsRequest> /
71	       <getMappingsResponse> Exchange . . . . . . . . . . . . . . . . 12
72	     4.1.  Behavior of the LoST Sync Destination  . . . . . . . . . . 12
73	     4.2.  Behavior of the LoST Sync Source . . . . . . . . . . . . . 12
74	     4.3.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13
75	   5.  Pushing Mappings via <pushMappings> and
76	       <pushMappingsResponse> . . . . . . . . . . . . . . . . . . . . 15
77	     5.1.  Behavior of the LoST Sync Source . . . . . . . . . . . . . 15
78	     5.2.  Behavior of the LoST Sync Destination  . . . . . . . . . . 15
79	     5.3.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . 16
80	   6.  Transport  . . . . . . . . . . . . . . . . . . . . . . . . . . 20
81	   7.  RelaxNG  . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
82	   8.  Operational Considerations . . . . . . . . . . . . . . . . . . 23
83	   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
84	   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
85	     10.1. Media Type Registration  . . . . . . . . . . . . . . . . . 25
86	     10.2. LoST Sync Relax NG Schema Registration . . . . . . . . . . 26
87	     10.3. LoST Synchronization Namespace Registration  . . . . . . . 27
88	   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 28
89	   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
90	     12.1. Normative References . . . . . . . . . . . . . . . . . . . 29
91	     12.2. Informative References . . . . . . . . . . . . . . . . . . 29
92	   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30

94	1.  Introduction

96	   Since the early days of emergency services there has been a desire to
97	   route emergency calls to Public Safety Answering Points (PSAPs) that
98	   are nearest to the location of the emergency caller.  For this
99	   purpose each PSAP discloses one or multiple service boundaries so
100	   that this information can be used to select the appropriate PSAP and
101	   to route the call to it.  RFC 5222 [RFC5222] defines this data
102	   structure in the following way:

104	      A service boundary circumscribes the region within which all
105	      locations map to the same service Uniform Resource Identifier
106	      (URI) or set of URIs for a given service.  A service boundary may
107	      consist of several non-contiguous geometric shapes.

109	   RFC 5222 [RFC5222] not only defines the term but it also specifies
110	   the data structure itself: the <mapping> element.

112	   This document re-uses this existing data structure and defines an
113	   XML-based protocol to exchange authoritative service boundaries
114	   between two entities (the LoST Sync source and the LoST Sync
115	   destination).  This protocol can be used with and without the actual
116	   LoST protocol.

118	   The rest of the document is structured as follows: Section 3 starts
119	   with an example usage of the LoST protocol.  In Section 4, Section 5,
120	   Section 6, and Section 7 we describe the protocol semantics,
121	   transport considerations and the schema.  Finally, we conclude with
122	   operational and security considerations in Section 8, and in
123	   Section 9.

125	2.  Terminology

127	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
128	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
129	   document are to be interpreted as described in RFC 2119 [RFC2119].

131	   This document reuses terminology introduced by the mapping
132	   architecture document [RFC5582], such as 'coverage region', 'forest
133	   guide', 'mapping', 'authoritative mapping server', and 'ESRP'.

135	   Throughout this document we use the term LoST Sync source and LoST
136	   Sync destination to denote the protocol end points of the exchange.
137	   The protocol is referred as LoST Sync within the text.

139	3.  A Motivating Example

141	   The LoST Sync mechanism can, for example, be used in the LoST
142	   architecture, as specified in the [RFC5582].  There, LoST servers act
143	   in different roles that cooperate to provide an ubiquitous, globally
144	   scalable and resilient mapping service.  In the LoST mapping
145	   architecture, LoST servers can peer, i.e., have an on-going data
146	   exchange relationship.  Peering relationships are set up manually,
147	   based on local policies.  A LoST server may peer with any number of
148	   other LoST servers.  Forest guides peer with other forest guides;
149	   authoritative mapping servers peer with forest guides and other
150	   authoritative servers, either in the same cluster or above or below
151	   them in the tree.  Authoritative mapping servers push coverage
152	   regions "up" the tree, i.e., from child nodes to parent nodes.  The
153	   child informs the parent of the geospatial or civic region that it
154	   covers for a specific service.

156	   Consider a hypothetical deployent of LoST in two countries, for
157	   example Austria and Finland.  Austria, in our example, runs three
158	   authoritative mapping servers labeled as 'East', 'West' and 'Vienna'
159	   whereby the former two cover the entire country expect for Vienna,
160	   which is covered by a separate LoST server.  There may be other
161	   caching LoST servers run by ISPs, universities, and VSPs but they are
162	   not relevant for this illustration.  Finland, on the other hand,
163	   decided to only deploy a single LoST server that also acts as a
164	   Forest Guide.  For this simplistic illustration we assume that only
165	   one service is available, namely 'urn:service:sos' since otherwise
166	   the number of stored mappings would have to be multiplied by the
167	   number of used services.

169	   Figure 1 shows the example deployment.

171	                      +---LoST-Sync-->\\     //<--LoST-Sync----+
172	                      |                 -----                  |
173	                      |                                        |
174	                      \/                                       \/
175	                    -----                                     -----
176	                  //     \\                                 //     \\
177	                 /         \                               /         \
178	                |  Forest   |                             |   Forest  |
179	                |  Guide    |                             |   Guide   |
180	                |  Austria  |                             |   Finland
181	                 \         /                               \         /
182	       +--------->\\     //<--------+                       \\     //
183	       |            -----           |                         -----
184	       |             /\             |                           |
185	     LoST            |             LoST                     //------\\
186	     Sync           LoST           Sync                    |Co-Located|
187	       |            Sync            |                      |   LoST   |
188	       \/            |              \/                     | Server   |
189	    //----\\         \/          //----\\                   \\------//
190	   |  LoST  |     //----\\      |  LoST  |
191	   | Server |    |  LoST  |     | Server |
192	   | (East) |    | Server |     |(Vienna)|
193	    \\----//     | (West) |      \\----//
194	                  \\----//

196	                     Figure 1: LoST Deployment Example

198	   The configuration of these nodes would therefore be as follows:

200	   Forest Guide Austria:  This forest guide would contain mappings for
201	      the three authoritative mapping servers (East, West and Vienna)
202	      describing what area they are responsible for.  Note that each
203	      mapping would contain a service URN and these mappings point to
204	      LoST servers rather than to PSAPs or ESRPs.

206	   LoST Server 'East':  This LoST server would contain all the mappings
207	      to PSAPs covering one half of the country.

209	      Additionally, the LoST server aggregates all the information it
210	      has and provides an abstracted view towards the Forest Guide
211	      indicating that it is responsible for a certain area (for a given
212	      service, and for a given location profile).  Such a mapping could
213	      have the following structure:

215	   <mapping
216	       xmlns="urn:ietf:params:xml:ns:lost1"
217	       xmlns:gml="http://www.opengis.net/gml"
218	       expires="2009-01-01T01:44:33Z"
219	       lastUpdated="2009-12-01T01:00:00Z"
220	       source="east-austria.lost-example.com"
221	       sourceId="e8b05a41d8d1415b80f2cdbb96ccf109">
222	       <displayName xml:lang="en">LoST Server 'East'</displayName>
223	       <service>urn:service:sos</service>
224	       <serviceBoundary profile="geodetic-2d">
225	           <gml:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
226	               <gml:exterior>
227	                   <gml:LinearRing>
228	                       <gml:pos> ... </gml:pos>
229	                       ..... list of coordinates for
230	                       boundary of LoST server 'East'
231	                       <gml:pos> ... </gml:pos>
232	                   </gml:LinearRing>
233	               </gml:exterior>
234	           </gml:Polygon>
235	       </serviceBoundary>
236	       <uri/>
237	   </mapping>

239	              Figure 2: Forest Guide Austria Mapping XML Snippet

241	      Note that the XML code snippet in Figure 2 serves illustrative
242	      purposes only and does not validate.  As it can be seen in this
243	      example the <uri> element is absent and the 'source' attribute
244	      identifies the LoST server, namely "east-austria.lost-
245	      example.com".

247	      The above-shown mapping is what is the LoST server "east-
248	      austria.lost-example.com" provides to the Austrian Forest Guide.

250	   LoST Server 'West':  This LoST server would contain all the mappings
251	      to PSAPs covering the other half of the country.

253	   LoST Server 'Vienna':  This LoST server would contain all the
254	      mappings to PSAPs in the area of Vienna.

256	   Forest Guide Finland:  In our example we assume that Finland would
257	      deploy a single ESRP for the entire country as their IP-based
258	      emergency services solution.  There is only a single LoST server
259	      and it is co-located with the Forest Guide, as shown in Figure 1.
260	      The mapping data this FG would distribute via LoST sync is shown
261	      in Figure 3.

263	   <mapping xmlns="urn:ietf:params:xml:ns:lost1"
264	       expires="2007-01-01T01:44:33Z"
265	       lastUpdated="2006-11-01T01:00:00Z"
266	       source="finland.lost-example.com"
267	       sourceId="7e3f40b098c711dbb6060800200c9a66">
268	       <displayName xml:lang="en">Finland ESRP</displayName>
269	       <service>urn:service:sos</service>
270	       <serviceBoundary profile="civic">
271	           <civicAddress
272	               xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
273	               <country>FI</country>
274	           </civicAddress>
275	       </serviceBoundary>
276	       <uri/>
277	   </mapping>

279	              Figure 3: Forest Guide Finland Mapping XML Snippet

281	      An example mapping stored at the co-located LoST server is shown
282	      in Figure 4.

284	   <mapping xmlns="urn:ietf:params:xml:ns:lost1"
285	       expires="2007-01-01T01:44:33Z"
286	       lastUpdated="2006-11-01T01:00:00Z"
287	       source="finland.lost-example.com"
288	       sourceId="7e3f40b098c711dbb6060800200c9a66">
289	       <displayName xml:lang="en">Finland ESRP</displayName>
290	       <service>urn:service:sos</service>
291	       <serviceBoundary profile="civic">
292	           <civicAddress
293	               xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
294	               <country>FI</country>
295	           </civicAddress>
296	       </serviceBoundary>
297	       <uri>sip:esrp@finland-example.com</uri>
298	       <uri>xmpp:esrp@finland-example.com</uri>
299	       <serviceNumber>112</serviceNumber>
300	   </mapping>

302	       Figure 4: Forest Guide Finland / Co-Located LoST Server Mapping
303	                                 XML Snippet

305	   The LoST sync mechanism described in this document could be run
306	   between the two Forest Guides.  Thereby, the three mappings stored in
307	   the Austria FG are sent to the FG Finland and a single mapping in the
308	   FG Finland is sent to the FG Austria.  Additionally, the three
309	   Austrian LoST servers could utilize LoST sync to inform the Austrian
310	   FG about their boundaries.  These three authoritative mapping servers
311	   in Austria would be responsible to maintain their own mapping
312	   information.  Since the amount of data being exchanged is small and
313	   the expected rate of change is low the nodes are configured to always
314	   exchange all their mapping information whenever a change happens.

316	   This document defines two types of exchanges and those are best
317	   described by the exchange between two nodes as shown in Figure 5 and
318	   Figure 6.  The protocol exchange always runs between a LoST Sync
319	   source and a LoST Sync destination.  Node A in the examples of
320	   Figure 5 and Figure 6 has mappings that Node B is going to retrieve.
321	   Node A acts as the source for the data and Node B is the destination.

323	   The <getMappingsRequest> request allows a LoST Sync source to request
324	   mappings from a LoST Sync destination.

326	      +---------+                   +---------+
327	      | Node B  |                   | Node A  |
328	      | acting  |                   | acting  |
329	      | as      |                   | as      |
330	      | LoST    |                   | LoST    |
331	      | Sync    |                   | Sync    |
332	      | Dest.   |                   | Source  |
333	      +---------+                   +---------+
334	          |                              |
335	          |                              |
336	          |                              |
337	          | <getMappingsRequest>         |
338	          |----------------------------->|
339	          |                              |
340	          | <getMappingsResponse>        |
341	          |<-----------------------------|
342	          |                              |
343	          |                              |
344	          |                              |

346	    Figure 5: Querying for Mappings with a <getMappingsRequest> Message

348	   Note that in the exchange illustrated in Figure 5 Node B is issuing
349	   the first request and plays the role of the HTTPS client and Node A
350	   plays the role of the HTTPS server.

352	   The <pushMappingsRequest> exchange allows a LoST Sync source to push
353	   mappings to LoST Sync destination.  In this example we assume that
354	   Node A has been configured maintain state about the mappings it had
355	   pushed to Node B.

357	   No publish/subscribe mechanism is defined in this document that would
358	   allow Node B to tell Node A about what mappings it is interested in
359	   nor a mechanism for learning to which entities mappings have to be
360	   pushed.

362	       +---------+                   +---------+
363	       | Node A  |                   | Node B  |
364	       | acting  |                   | acting  |
365	       | as      |                   | as      |
366	       | LoST    |                   | LoST    |
367	       | Sync    |                   | Sync    |
368	       | Source  |                   | Dest.   |
369	       +---------+                   +---------+
370	           |                              |
371	           |                              |
372	           |                              |
373	           | <pushMappingsRequest>        |
374	           |----------------------------->|
375	           |                              |
376	           | <pushMappingsResponse>       |
377	           |<-----------------------------|
378	           |                              |
379	           |                              |
380	           |                              |

382	      Figure 6: Pushing Mappings with a <pushMappingsRequest> Message

384	   Node A issuing the first request in Figure 6 plays the role of the
385	   HTTPS client and Node B plays the role of the HTTPS server.

387	4.  Querying for Mappings with a <getMappingsRequest> /
388	    <getMappingsResponse> Exchange

390	4.1.  Behavior of the LoST Sync Destination

392	   A LoST Sync destination has two ways to retrieve mapping elements
393	   from a LoST Sync source.

395	   1.  A mechanisms that is suitable when no mappings are available on
396	       the LoST Sync destination is to submit an empty
397	       <getMappingsRequest> message, as shown in Figure 7.  The intent
398	       by the LoST Sync destination thereby is to retrieve all mappings
399	       from the LoST Sync source.  Note that the request does not
400	       propagate further to other nodes.

402	   2.  In case a LoST Sync destination node has already obtained
403	       mappings in previous exchanges then it may want to check whether
404	       these mappings have been updated in the meanwhile.  The policy
405	       when to poll for updated mapping information is outside the scope
406	       of this document.  The <getMappingsRequest> message with one or
407	       multiple <exists> child element(s) allows to reduce the number of
408	       returned mappings to those that have been updated and also to
409	       those that are missing.

411	   In response to the <getMappingsRequest> message the LoST Sync
412	   destination waits for the <getMappingsResponse> message.  In case of
413	   a successful response the LoST Sync destination stores the received
414	   mappings and determines which mappings to update.

416	4.2.  Behavior of the LoST Sync Source

418	   When a LoST Sync source receives an empty <getMappingsRequest>
419	   message then all locally available mappings MUST be returned.

421	   When a LoST Sync source receives a <getMappingsRequest> message with
422	   one or multiple <exists> child element(s) then it MUST consult with
423	   the local mapping database to determine whether any of the mappings
424	   of the client is stale and whether there are mappings locally that
425	   the client does not yet have.  The former can be determined by
426	   finding mappings corresponding to the 'source' and 'sourceID'
427	   attribut where a mapping with a more recent lastUpdated date exists.

429	   Processing a <getMappingsRequest> message MAY lead to a successful
430	   response in the form of a <getMappingsResponse> or an <errors>
431	   message.  Only the <badRequest>, <forbidden>, <internalError>,
432	   <serverTimeout> errors, defined in [RFC5222], are utilized by this
433	   specification.  Neither the <redirect> nor the <warnings> messages
434	   are reused by this message.

436	4.3.  Examples

438	   The first example shows an empty <getMappingsRequest> message that
439	   would retrieve all locally stored mappings at the LoST Sync source.

441	   <?xml version="1.0" encoding="UTF-8"?>
442	   <getMappingsRequest xmlns="urn:ietf:params:xml:ns:lostsync1"/>

444	          Figure 7: Example of empty <getMappingsRequest> message

446	   A further example request is shown in Figure 8 and the corresponding
447	   response is depicted in Figure 9.  In this example the
448	   <getMappingsRequest> element contains information about the mapping
449	   that is locally available to the client inside the <mapping-
450	   fingerprint> element (with source="authoritative.bar.example",
451	   sourceId="7e3f40b098c711dbb6060800200c9a66", and lastUpdated="2006-
452	   11-01T01:00:00Z").  The query asks for mappings that are more recent
453	   than the available one as well as any missing mapping.

455	   <?xml version="1.0" encoding="UTF-8"?>
456	   <getMappingsRequest xmlns="urn:ietf:params:xml:ns:lostsync1">
457	       <exists>
458	           <mapping-fingerprint source="authoritative.bar.example"
459	           sourceId="7e3f40b098c711dbb6060800200c9a66"
460	           lastUpdated="2006-11-01T01:00:00Z">
461	           </mapping-fingerprint>
462	       </exists>
463	   </getMappingsRequest>

465	              Figure 8: Example <getMappingsRequest> Message

467	   The response to the above request is shown in Figure 9.  A more
468	   recent mapping was available with the identification of
469	   source="authoritative.bar.example" and
470	   sourceId="7e3f40b098c711dbb6060800200c9a66".  Only one mapping that
471	   matched source="authoritative.foo.example" was found and returned.

473	  <?xml version="1.0" encoding="UTF-8"?>
474	  <sync:getMappingsResponse
475	      xmlns:sync="urn:ietf:params:xml:ns:lostsync1"
476	      xmlns="urn:ietf:params:xml:ns:lost1"
477	      xmlns:gml="http://www.opengis.net/gml">

479	          <mapping source="authoritative.bar.example"
480	              sourceId="7e3f40b098c711dbb6060800200c9a66"
481	              lastUpdated="2008-11-26T01:00:00Z"
482	              expires="2009-12-26T01:00:00Z">
483	              <displayName xml:lang="en">Leonia Police Department
484	              </displayName>
485	              <service>urn:service:sos.police</service>
486	              <serviceBoundary
487	  profile="urn:ietf:params:lost:location-profile:basic-civic">
488	                  <civicAddress
489	  xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
490	                      <country>US</country>
491	                      <A1>NJ</A1>
492	                      <A3>Leonia</A3>
493	                      <PC>07605</PC>
494	                  </civicAddress>
495	              </serviceBoundary>
496	              <uri>sip:police@leonianj2.example.org</uri>
497	              <serviceNumber>911</serviceNumber>
498	          </mapping>

500	          <mapping expires="2009-01-01T01:44:33Z"
501	              lastUpdated="2008-11-01T01:00:00Z"
502	              source="authoritative.foo.example"
503	              sourceId="7e3f40b098c711dbb606011111111111">
504	              <displayName xml:lang="en">New York City Police Department
505	              </displayName>
506	              <service>urn:service:sos.police</service>
507	              <serviceBoundary profile="geodetic-2d">
508	                  <gml:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
509	                      <gml:exterior>
510	                          <gml:LinearRing>
511	                              <gml:pos>37.775 -122.4194</gml:pos>
512	                              <gml:pos>37.555 -122.4194</gml:pos>
513	                              <gml:pos>37.555 -122.4264</gml:pos>
514	                              <gml:pos>37.775 -122.4264</gml:pos>
515	                              <gml:pos>37.775 -122.4194</gml:pos>
516	                          </gml:LinearRing>
517	                      </gml:exterior>
518	                  </gml:Polygon>
519	              </serviceBoundary>
520	              <uri>sip:nypd@example.com</uri>
521	              <uri>xmpp:nypd@example.com</uri>
522	              <serviceNumber>911</serviceNumber>
523	          </mapping>

525	  </sync:getMappingsResponse>

527	              Figure 9: Example <getMappingsResponse> Message

529	5.  Pushing Mappings via <pushMappings> and <pushMappingsResponse>

531	5.1.  Behavior of the LoST Sync Source

533	   When a LoST Sync source obtains new information that is of interest
534	   to its peers, it may push the new mappings to its peers.
535	   Configuration settings at both peers decide whether this
536	   functionality is used and what mappings are pushed to which other
537	   peers.  New mappings may arrive through various means, such as a
538	   manual addition to the local mapping database, or through the
539	   interaction with other entities.  Deleting mappings may also trigger
540	   a protocol interaction.

542	   The LoST Sync source SHOULD keep track of which LoST Sync destination
543	   it has pushed mapping elements.  If it does not keep state
544	   information then it always has to push the complete data set.  As
545	   discussed in Section 5.1 of [RFC5222], mapping elements are
546	   identified by the 'source', 'sourceID' and 'lastUpdated' attributes.
547	   A mapping is considered the same if these three attributes match.

549	   A <pushMappings> request sent by a LoST Sync source MUST containing
550	   one or more <mapping> elements.

552	   To delete a mapping, the content of the mapping is left empty, i.e.
553	   the <mapping> element only contains the 'source', 'sourceID',
554	   'lastUpdated', and 'expires" attribute.  Figure 10 shows an example
555	   request where the mapping with the source="nj.us.example",
556	   sourceId="123", lastUpdated="2008-11-01T01:00:00Z", expires="2008-11-
557	   01T01:00:00Z" is requested to be deleted.  Note that the 'expires'
558	   attribute is required per schema definition but will be ignored in
559	   processing the request on the receiving side.  A sync source may want
560	   to delete the mapping from its internal mapping database, but has to
561	   remember which peers it has distributed this update to unless it has
562	   other ways to ensure that databases do not get out of sync.

564	5.2.  Behavior of the LoST Sync Destination

566	   When a LoST Sync destination receives a <pushMappingsRequest> message
567	   then the cache with the existing mappings is inspected to determine
568	   whether the received mapping should lead to an update of an already
569	   existing mapping, should create a new mapping in the cache, or should
570	   be discarded.

572	   If a newly received mapping has a more recent time in its
573	   'lastUpdated' attribute, it MUST update an existing mapping that has
574	   matching 'source' and 'sourceID' attributes.

576	   If the received mapping does not match with any existing mapping
577	   based on the 'source' and 'sourceId' then it MUST be added to the
578	   local cache as an independent mapping.

580	   If a <pushMappingsRequest> message with an empty <mapping> element is
581	   received then a corresponding mapping has to be determined based on
582	   the 'source', and the 'sourceID'.

584	   If no mapping can be identified then an <errors> response MUST be
585	   returned that contains the <notDeleted> child element.  The
586	   <notDeleted> element MAY contain a 'message' attribute with an error
587	   description used for debugging purposes.  The <notDeleted> element
588	   MUST contain the <mapping> element(s) that caused the error.

590	   The response to a <pushMappingsRequest> request is a
591	   <pushMappingsResponse> message.  With this specification, a
592	   successful response message returns no additional elements, whereas
593	   an <errors> response is returned in the response message, if the
594	   request failed.  Only the <badRequest>, <forbidden>, <internalError>
595	   or <serverTimeout> errors defined in Section 13.1 of [RFC5222], are
596	   used.  The <redirect> and <warnings> messages are not used for this
597	   query/response.

599	   If the set of nodes that are synchronizing their data does not form a
600	   tree, it is possible that the same information arrives through
601	   several other nodes.  This is unavoidable, but generally only imposes
602	   a modest overhead.  (It would be possible to create a spanning tree
603	   in the same fashion as IP multicast, but the complexity does not seem
604	   warranted, given the relatively low volume of data.)

606	5.3.  Example

608	   An example is shown in Figure 10.  Imagine a LoST node that obtained
609	   two new mappings identified as follows:

611	   o

613	   source="authoritative.example"
614	   sourceId="7e3f40b098c711dbb6060800200c9a66"
615	   lastUpdated="2008-11-26T01:00:00Z"

617	   o

619	   source="authoritative.example"
620	   sourceId="7e3f40b098c711dbb606011111111111"
621	   lastUpdated="2008-11-01T01:00:00Z"

623	   These two mappings have to be added to the peer's mapping database.

625	   Additionally, the following mapping has to be deleted:

627	   o  source="nj.us.example" sourceId="123" lastUpdated="2008-11-
628	      01T01:00:00Z"

630	  <?xml version="1.0" encoding="UTF-8"?>
631	  <sync:pushMappings
632	      xmlns:sync="urn:ietf:params:xml:ns:lostsync1"
633	      xmlns="urn:ietf:params:xml:ns:lost1"
634	      xmlns:gml="http://www.opengis.net/gml">

636	          <mapping source="authoritative.example"
637	              sourceId="7e3f40b098c711dbb6060800200c9a66"
638	              lastUpdated="2008-11-26T01:00:00Z"
639	              expires="2009-12-26T01:00:00Z">
640	              <displayName xml:lang="en">Leonia Police Department
641	              </displayName>
642	              <service>urn:service:sos.police</service>
643	              <serviceBoundary
644	       profile="urn:ietf:params:lost:location-profile:basic-civic">
645	                  <civicAddress
646	       xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
647	                      <country>US</country>
648	                      <A1>NJ</A1>
649	                      <A3>Leonia</A3>
650	                      <PC>07605</PC>
651	                  </civicAddress>
652	              </serviceBoundary>
653	              <uri>sip:police@leonianj.example.org</uri>
654	              <serviceNumber>911</serviceNumber>
655	          </mapping>

657	          <mapping expires="2009-01-01T01:44:33Z"
658	              lastUpdated="2008-11-01T01:00:00Z"
659	              source="authoritative.example"
660	              sourceId="7e3f40b098c711dbb606011111111111">
661	              <displayName xml:lang="en">New York City Police Department
662	              </displayName>
663	              <service>urn:service:sos.police</service>
664	              <serviceBoundary profile="geodetic-2d">
665	                  <gml:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
666	                      <gml:exterior>
667	                          <gml:LinearRing>
668	                              <gml:pos>37.775 -122.4194</gml:pos>
669	                              <gml:pos>37.555 -122.4194</gml:pos>
670	                              <gml:pos>37.555 -122.4264</gml:pos>
671	                              <gml:pos>37.775 -122.4264</gml:pos>
672	                              <gml:pos>37.775 -122.4194</gml:pos>
673	                          </gml:LinearRing>
674	                      </gml:exterior>
675	                  </gml:Polygon>
676	              </serviceBoundary>
677	              <uri>sip:nypd@example.com</uri>
678	              <uri>xmpp:nypd@example.com</uri>
679	              <serviceNumber>911</serviceNumber>
680	          </mapping>

682	          <mapping source="nj.us.example"
683	              sourceId="123"
684	              lastUpdated="2008-11-01T01:00:00Z"
685	              expires="2008-11-01T01:00:00Z"/>

687	  </sync:pushMappings>

689	             Figure 10: Example <pushMappingsRequest> Message

691	   In response, the peer performs the necessary operation and updates
692	   its mapping database.  In particular, it will check whether the other
693	   peer is authorized to perform the update and whether the elements and
694	   attributes contain values that it understands.  In our example, a
695	   positive response is returned as shown in Figure 11.

697	   <?xml version="1.0" encoding="UTF-8"?>
698	   <pushMappingsResponse xmlns="urn:ietf:params:xml:ns:lostsync1" />

700	                 Figure 11: Example <pushMappingsResponse>

702	   In case that a mapping could not be deleted as requested the
703	   following error response might be returned instead.

705	   <?xml version="1.0" encoding="UTF-8"?>
706	   <errors xmlns="urn:ietf:params:xml:ns:lost1"
707	       xmlns:sync="urn:ietf:params:xml:ns:lostsync1"
708	       source="nodeA.example.com">

710	       <sync:notDeleted
711	           message="Could not delete the indicated mapping."
712	           xml:lang="en">

714	           <mapping source="nj.us.example"
715	               sourceId="123"
716	               lastUpdated="2008-11-01T01:00:00Z"
717	               expires="2008-11-01T01:00:00Z"/>
718	       </sync:notDeleted>
719	   </errors>

721	                    Figure 12: Example <errors> Message

723	6.  Transport

725	   LoST Sync needs an underlying protocol transport mechanism to carry
726	   requests and responses.  This document uses HTTPS as a transport to
727	   exchange XML documents.  No fallback to HTTP is provided.

729	   When using HTTP-over-TLS [RFC2818], LoST Sync messages use the POST
730	   method.  Request MUST use the Cache-Control response directive "no-
731	   cache".

733	   All LoST Sync responses, including those indicating a LoST warning or
734	   error, are carried in 2xx responses, typically 200 (OK). 3xx, 4xx and
735	   5xx HTTP response codes indicates that the request itself failed or
736	   was redirected; these responses do not contain any LoST Sync XML
737	   elements.

739	7.  RelaxNG

741	   Note: In order to avoid copying pattern definitions from the LoST
742	   Relax NG schema [RFC5222] to this document we include it as
743	   "lost.rng" (XML syntax) in the Relax NG schema below.

745	   <?xml version="1.0" encoding="utf-8"?>

747	        <grammar ns="urn:ietf:params:xml:ns:lostsync1"
748	        xmlns="http://relaxng.org/ns/structure/1.0"
749	        xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
750	        datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">

752	            <include href="lost.rng"/>

754	            <start combine="choice">

756	             <a:documentation> Location-to-Service Translation (LoST)
757	               Synchronization Protocol</a:documentation>

759	                <choice>
760	                    <ref name="pushMappings"/>
761	                    <ref name="pushMappingsResponse"/>
762	                    <ref name="getMappingsRequest"/>
763	                    <ref name="getMappingsResponse"/>
764	                </choice>
765	            </start>

767	            <define name="pushMappings">
768	                <element name="pushMappings">
769	                        <oneOrMore>
770	                            <ref name="mapping"/>
771	                        </oneOrMore>

773	                    <ref name="extensionPoint"/>
774	                </element>
775	            </define>

777	            <define name="pushMappingsResponse">
778	                <element name="pushMappingsResponse">
779	                    <ref name="extensionPoint"/>
780	                </element>
781	            </define>

783	             <define name="getMappingsRequest">
784	                  <element name="getMappingsRequest">
785	                    <choice>
786	                         <ref name="exists"></ref>
787	                         <ref name="extensionPoint"/>
788	                    </choice>
789	                </element>
790	            </define>

792	             <define name="exists">
793	                  <element name="exists">
794	                       <oneOrMore>
795	                            <element name="mapping-fingerprint">
796	                                 <attribute name="source">
797	                                      <data type="token"/>
798	                                 </attribute>
799	                                 <attribute name="sourceId">
800	                                      <data type="token"/>
801	                                 </attribute>
802	                                 <attribute name="lastUpdated">
803	                                      <data type="dateTime"/>
804	                                 </attribute>
805	                                 <ref name="extensionPoint"/>
806	                            </element>
807	                       </oneOrMore>
808	                  </element>
809	             </define>

811	            <define name="getMappingsResponse">
812	                <element name="getMappingsResponse">
813	                        <oneOrMore>
814	                            <ref name="mapping"/>
815	                        </oneOrMore>
816	                    <ref name="extensionPoint"/>
817	                </element>
818	            </define>

820	             <!-- error messages -->

822	             <define name="notDeleted">
823	                  <element name="notDeleted">
824	                       <ref name="basicException"/>
825	                       <oneOrMore>
826	                            <ref name="mapping"/>
827	                       </oneOrMore>
828	                  </element>
829	             </define>
830	        </grammar>

832	8.  Operational Considerations

834	   When different LoST servers use the mechanism described in this
835	   document to synchronize their mapping data then it is important to
836	   ensure that loops are avoided.  The example shown in Figure 13 with
837	   three LoST servers A, B and C (each of them acts as a sync source and
838	   a sync destination) illustrates the challenge in more detail.  A and
839	   B synchronize data between each other; the same is true for A and C,
840	   and B and C, respectively.

842	        A -------- B
843	         \        /
844	          \      /
845	           \    /
846	            \  /
847	             C

849	             Figure 13: Synchronization Configuration Example

851	   Now, imagine that server A adds a new mapping.  This mapping is
852	   uniquely identified by the combination of "source", "sourceid" and
853	   "last updated".  Assume that A would push this new mapping to B and
854	   C. When B obtained this new mapping it would find out that it has to
855	   distribute it to its peer C. C would also want to distribute the
856	   mapping to B. If the original mapping with the "source", "sourceid"
857	   and "last updated" is not modified by either B or C then these two
858	   servers would recognize that they already possess the mapping and can
859	   ignore the update.

861	   It is important that implementations MUST NOT modify mappings they
862	   receive.  An entity acting maliciously would, however, intentially
863	   modify mappings or inject bogus mappings.  To avoid the possibility
864	   of an untrustworthy member claiming a coverage region that it is not
865	   authorized for, authoritative mapping server MUST sign mappings they
866	   distribute using an XML digital signature
867	   [W3C.REC-xmldsig-core-20020212].  A recipient MUST verify that the
868	   signing entity is indeed authorized to speak for that region.  In
869	   many cases, this will require an out-of-band agreement to be in place
870	   to agree on specific entities to take on this role.  Determining who
871	   can speak for a particular region is inherently difficult unless
872	   there is a small set of authorizing entities that participants in the
873	   mapping architecture can trust.  Receiving systems should be
874	   particularly suspicious if an existing coverage region is replaced by
875	   a new one that contains a different value in the <uri> element.  When
876	   mappings are digitially signed, they cannot be modified by
877	   intermediate LoST servers.

879	9.  Security Considerations

881	   This document defines a protocol for exchange of authoritative
882	   mapping information between two entities.  Hence, the protocol
883	   operations described in this document require authentication of
884	   neighboring nodes.

886	   The LoST Sync client and servers MUST implement TLS and use TLS.
887	   Which version(s) ought to be implemented will vary over time, and
888	   depend on the widespread deployment and known security
889	   vulnerabilities at the time of implementation.  At the time of this
890	   writing, TLS version 1.2 [RFC5246] is the most recent version, but
891	   has very limited actual deployment, and might not be readily
892	   available in implementation toolkits.  TLS version 1.0 [RFC2246] is
893	   the most widely deployed version, and will give the broadest
894	   interoperability.

896	   Mutual authentication between the LoST Sync source and the LoST Sync
897	   destination is not necessarily required in all deployments unless an
898	   emergency service authority wants to enforce access control prior to
899	   the distribution of their mapping elements.  This may, for example,
900	   be the case when certain emergency services network internal mappings
901	   are not meant for public distribution.

903	   An additional threat is caused by compromised or misconfigured LoST
904	   servers.  A denial of service could be the consequence of an injected
905	   mapping.  If the mapping data contains an URL that does not exist
906	   then emergency services for the indicated area are not reachable.  If
907	   all mapping data contains URLs that point to a single PSAP (rather
908	   than a large number of PSAPs) then this PSAP is likely to experience
909	   overload conditions.  If the mapping data contains a URL that points
910	   to a server controlled by the adversary itself then it might
911	   impersonate PSAPs.

913	   Section 8 discusses this security threat and mandates signed
914	   mappings.  For unusal changes to the mapping database approval by a
915	   system administrator of the emergency services infrastructure (or a
916	   similar expert) may be required before any mappings are installed.

918	10.  IANA Considerations

920	10.1.  Media Type Registration

922	   This specification requests the registration of a new media type
923	   according to the procedures of RFC 4288 [RFC4288] and guidelines in
924	   RFC 3023 [RFC3023].

926	   Type name:  application

928	   Subtype name:  lostsync+xml

930	   Required parameters:  none

932	   Optional parameters:  charset

934	      Same as charset parameter of application/xml as specified in RFC
935	      3023 [RFC3023].

937	   Encoding considerations:  Identical to those of "application/xml" as
938	      described in [RFC3023], Section 3.2.

940	   Security considerations:  This content type is designed to carry LoST
941	      Synchronization protocol payloads and the security considerations
942	      section of RFCXXXX is applicable.  In addition, as this media type
943	      uses the "+xml" convention, it shares the same security
944	      considerations as described in [RFC3023], Section 10.  [NOTE TO
945	      IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this
946	      specification.]

948	   Interoperability considerations:  None

950	   Published specification:  RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please
951	      replace XXXX with the RFC number of this specification.]

953	   Applications which use this media type:  Emergency and Location-based
954	      Systems

956	   Additional information:

958	      Magic number(s):  None

960	      File extension(s):  .lostsyncxml

962	      Macintosh file type code(s):  'TEXT'

964	   Person & email address to contact for further information:  Hannes
965	      Tschofenig <Hannes.Tschofenig@gmx.net>

967	   Intended usage:  LIMITED USE

969	   Restrictions on usage:  None

971	   Author:  Hannes Tschofenig <Hannes.Tschofenig@gmx.net>

973	   Change controller:

975	      This specification is a work item of the IETF ECRIT working group,
976	      with mailing list address <ecrit@ietf.org>.

978	   Change controller:

980	      The IESG <iesg@ietf.org>

982	10.2.  LoST Sync Relax NG Schema Registration

984	   Please register the schema defined in this document under the XML
985	   schema registry at
986	   http://www.iana.org/assignments/xml-registry/schema.html

988	   URI:  urn:ietf:params:xml:schema:lostsync1

990	   Registrant Contact:  IETF ECRIT Working Group, Hannes Tschofenig
991	      (Hannes.Tschofenig@gmx.net).

993	   Relax NG Schema:  The Relax NG schema to be registered is contained
994	      in Section 7.

996	10.3.  LoST Synchronization Namespace Registration

998	   Please register the namespace defined in this document under the XML
999	   namespace registry at
1000	   http://www.iana.org/assignments/xml-registry/ns.html

1002	   URI:  urn:ietf:params:xml:ns:lostsync1

1004	   Registrant Contact:  IETF ECRIT Working Group, Hannes Tschofenig
1005	      (Hannes.Tschofenig@gmx.net).

1007	   XML:

1009	   BEGIN
1010	   <?xml version="1.0"?>
1011	   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
1012	     "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
1013	   <html xmlns="http://www.w3.org/1999/xhtml">
1014	   <head>
1015	     <meta http-equiv="content-type"
1016	           content="text/html;charset=iso-8859-1"/>
1017	     <title>LoST Synchronization Namespace</title>
1018	   </head>
1019	   <body>
1020	     <h1>Namespace for LoST server synchronization</h1>
1021	     <h2>urn:ietf:params:xml:ns:lostsync1</h2>
1022	   <p>See <a href="[URL of published RFC]">RFCXXXX
1023	       [NOTE TO IANA/RFC-EDITOR:
1024	        Please replace XXXX with the RFC number of this
1025	       specification.]</a>.</p>
1026	   </body>
1027	   </html>
1028	   END

1030	11.  Acknowledgments

1032	   Robins George, Cullen Jennings, Karl Heinz Wolf, Richard Barnes,
1033	   Mayutan Arumaithurai, Alexander Mayrhofer, and Andrew Newton provided
1034	   helpful input.  Jari Urpalainen assisted with the Relax NG schema.
1035	   We would also like to thank our document shepherd Roger Marshall for
1036	   his help with the document.

1038	   We would like to particularly thank Andrew Newton for his timely and
1039	   valuable review of the XML-related content.

1041	   We would like to thank Robert Sparks, Barry Leiba, Stephen Farrell,
1042	   Brian Haberman, Pete Resnick, and Sean Turner for their AD reviews.
1043	   We would also like to thank Bjoern Hoehrmann for his media type
1044	   review, Julian Reschke and Martin Duerst for their applications area
1045	   reviews, and Wassim Haddad for his Gen-ART review.

1047	12.  References

1049	12.1.  Normative References

1051	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1052	              Requirement Levels", BCP 14, RFC 2119, March 1997.

1054	   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
1055	              RFC 2246, January 1999.

1057	   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1058	              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1059	              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

1061	   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
1062	              Leach, P., Luotonen, A., and L. Stewart, "HTTP
1063	              Authentication: Basic and Digest Access Authentication",
1064	              RFC 2617, June 1999.

1066	   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

1068	   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
1069	              Types", RFC 3023, January 2001.

1071	   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
1072	              Registration Procedures", BCP 13, RFC 4288, December 2005.

1074	   [RFC5222]  Hardie, T., Newton, A., Schulzrinne, H., and H.
1075	              Tschofenig, "LoST: A Location-to-Service Translation
1076	              Protocol", RFC 5222, August 2008.

1078	   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
1079	              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

1081	   [W3C.REC-xmldsig-core-20020212]
1082	              Eastlake, D., Reagle, J., Solo, D., Hirsch, F., and T.
1083	              Roessler, "XML-Signature Syntax and Processing", World
1084	              Wide Web Consortium Second Edition REC-xmldsig-core-
1085	              20020212, June 2008.

1087	12.2.  Informative References

1089	   [RFC5582]  Schulzrinne, H., "Location-to-URL Mapping Architecture and
1090	              Framework", RFC 5582, September 2009.

1092	Authors' Addresses

1094	   Henning Schulzrinne
1095	   Columbia University
1096	   Department of Computer Science
1097	   450 Computer Science Building
1098	   New York, NY  10027
1099	   US

1101	   Phone: +1 212 939 7004
1102	   Email: hgs+ecrit@cs.columbia.edu
1103	   URI:   http://www.cs.columbia.edu

1105	   Hannes Tschofenig
1106	   Nokia Siemens Networks
1107	   Linnoitustie 6
1108	   Espoo  02600
1109	   Finland

1111	   Phone: +358 (50) 4871445
1112	   Email: Hannes.Tschofenig@gmx.net
1113	   URI:   http://www.tschofenig.priv.at