idnits 2.17.00 (12 Aug 2021)

/tmp/idnits47306/draft-ietf-ecrit-lost-sync-17.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 (March 11, 2012) is 3723 days in the past.  Is this
     intentional?


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

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

  == Unused Reference: 'RFC2617' is defined on line 1024, 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 3023 (Obsoleted by RFC 7303)

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

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


     Summary: 6 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: September 12, 2012                       Nokia Siemens Networks
6	                                                          March 11, 2012

8	  Synchronizing Location-to-Service Translation (LoST) Protocol based
9	                Service Boundaries and Mapping Elements
10	                   draft-ietf-ecrit-lost-sync-17.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 main data structure, the <mapping> element, used for
21	   encapsulating information about service boundaries is defined in the
22	   LoST protocol specification and circumscribes the region within which
23	   all locations map to the same service Uniform Resource Identifier
24	   (URI) or set of URIs for a given 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 September 12, 2012.

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  . . . . . . . . . . . . . . . . . . . . . . . . . 10
69	   3.  Querying for Mappings with a <getMappingsRequest> /
70	       <getMappingsResponse> Exchange . . . . . . . . . . . . . . . . 11
71	     3.1.  Behavior of the LoST Sync Destination  . . . . . . . . . . 11
72	     3.2.  Behavior of the LoST Sync Source . . . . . . . . . . . . . 11
73	     3.3.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . 12
74	   4.  Pushing Mappings via <pushMappings> and
75	       <pushMappingsResponse> . . . . . . . . . . . . . . . . . . . . 14
76	     4.1.  Behavior of the LoST Sync Source . . . . . . . . . . . . . 14
77	     4.2.  Behavior of the LoST Sync Destination  . . . . . . . . . . 14
78	     4.3.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . 15
79	   5.  Transport  . . . . . . . . . . . . . . . . . . . . . . . . . . 19
80	   6.  RelaxNG  . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
81	   7.  Operational Considerations . . . . . . . . . . . . . . . . . . 22
82	   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
83	   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24
84	     9.1.  Content-type registration for
85	           'application/lostsync+xml' . . . . . . . . . . . . . . . . 24
86	     9.2.  LoST Sync Relax NG Schema Registration . . . . . . . . . . 25
87	     9.3.  LoST Synchronization Namespace Registration  . . . . . . . 26
88	   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 27
89	   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
90	     11.1. Normative References . . . . . . . . . . . . . . . . . . . 28
91	     11.2. Informative References . . . . . . . . . . . . . . . . . . 28
92	   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29

94	1.  Introduction

96	   The LoST (Location-to-Service Translation) protocol [RFC5222] maps
97	   service identifiers and geodetic or civic location information to
98	   service URIs.  The main data structure, the <mapping> element, used
99	   for encapsulating information about service boundaries is defined in
100	   the LoST protocol specification and circumscribes the region within
101	   which all locations map to the same service Uniform Resource
102	   Identifier (URI) or set of URIs for a given service.

104	   This mechanism is designed for the exchange of authoritative
105	   <mapping> elements between two entities (the LoST Sync source and the
106	   LoST Sync destination).

108	   The LoST Sync mechanism can, for example, be used in the LoST
109	   architecture, as specified in the [RFC5582].  There, LoST servers act
110	   in different roles that cooperate to provide an ubiquitous, globally
111	   scalable and resilient mapping service.  In the LoST mapping
112	   architecture, LoST servers can peer, i.e., have an on-going data
113	   exchange relationship.  Peering relationships are set up manually,
114	   based on local policies.  A LoST server may peer with any number of
115	   other LoST servers.  Forest guides peer with other forest guides;
116	   authoritative mapping servers peer with forest guides and other
117	   authoritative servers, either in the same cluster or above or below
118	   them in the tree.  Authoritative mapping servers push coverage
119	   regions "up" the tree, i.e., from child nodes to parent nodes.  The
120	   child informs the parent of the geospatial or civic region that it
121	   covers for a specific service.

123	   Consider a hypothetical deployent of LoST in two countries, for
124	   example Austria and Finland.  Austria, in our example, runs three
125	   authoritative mapping servers labeled as 'East', 'West' and 'Vienna'
126	   whereby the former two cover the entire country expect for Vienna,
127	   which is covered by a separate LoST server.  There may be other
128	   caching LoST servers run by ISPs, universities, and VSPs but they are
129	   not relevant for this illustration.  Finland, on the other hand,
130	   decided to only deploy a single LoST server that also acts as a
131	   Forest Guide.  For this simplistic illustration we assume that only
132	   one service is available, namely 'urn:service:sos' since otherwise
133	   the number of stored mappings would have to be multiplied by the
134	   number of used services.

136	   Figure 1 shows the example deployment.

138	                      +---LoST-Sync-->\\     //<--LoST-Sync----+
139	                      |                 -----                  |
140	                      |                                        |
141	                      \/                                       \/
142	                    -----                                     -----
143	                  //     \\                                 //     \\
144	                 /         \                               /         \
145	                |  Forest   |                             |   Forest  |
146	                |  Guide    |                             |   Guide   |
147	                |  Austria  |                             |   Finland
148	                 \         /                               \         /
149	       +--------->\\     //<--------+                       \\     //
150	       |            -----           |                         -----
151	       |             /\             |                           |
152	     LoST            |             LoST                     //------\\
153	     Sync           LoST           Sync                    |Co-Located|
154	       |            Sync            |                      |   LoST   |
155	       \/            |              \/                     | Server   |
156	    //----\\         \/          //----\\                   \\------//
157	   |  LoST  |     //----\\      |  LoST  |
158	   | Server |    |  LoST  |     | Server |
159	   | (East) |    | Server |     |(Vienna)|
160	    \\----//     | (West) |      \\----//
161	                  \\----//

163	                     Figure 1: LoST Deployment Example

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

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

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

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

182	   <mapping
183	       xmlns="urn:ietf:params:xml:ns:lost1"
184	       xmlns:gml="http://www.opengis.net/gml"
185	       expires="2009-01-01T01:44:33Z"
186	       lastUpdated="2009-12-01T01:00:00Z"
187	       source="east-austria.lost-example.com"
188	       sourceId="e8b05a41d8d1415b80f2cdbb96ccf109">
189	       <displayName xml:lang="en">LoST Server 'East'</displayName>
190	       <service>urn:service:sos</service>
191	       <serviceBoundary profile="geodetic-2d">
192	           <gml:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
193	               <gml:exterior>
194	                   <gml:LinearRing>
195	                       <gml:pos> ... </gml:pos>
196	                       ..... list of coordinates for
197	                       boundary of LoST server 'East'
198	                       <gml:pos> ... </gml:pos>
199	                   </gml:LinearRing>
200	               </gml:exterior>
201	           </gml:Polygon>
202	       </serviceBoundary>
203	       <uri/>
204	   </mapping>

206	              Figure 2: Forest Guide Austria Mapping XML Snippet

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

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

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

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

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

230	   <mapping xmlns="urn:ietf:params:xml:ns:lost1"
231	       expires="2007-01-01T01:44:33Z"
232	       lastUpdated="2006-11-01T01:00:00Z"
233	       source="finland.lost-example.com"
234	       sourceId="7e3f40b098c711dbb6060800200c9a66">
235	       <displayName xml:lang="en">Finland ESRP</displayName>
236	       <service>urn:service:sos</service>
237	       <serviceBoundary profile="civic">
238	           <civicAddress
239	               xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
240	               <country>FI</country>
241	           </civicAddress>
242	       </serviceBoundary>
243	       <uri/>
244	   </mapping>

246	              Figure 3: Forest Guide Finland Mapping XML Snippet

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

251	   <mapping xmlns="urn:ietf:params:xml:ns:lost1"
252	       expires="2007-01-01T01:44:33Z"
253	       lastUpdated="2006-11-01T01:00:00Z"
254	       source="finland.lost-example.com"
255	       sourceId="7e3f40b098c711dbb6060800200c9a66">
256	       <displayName xml:lang="en">Finland ESRP</displayName>
257	       <service>urn:service:sos</service>
258	       <serviceBoundary profile="civic">
259	           <civicAddress
260	               xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
261	               <country>FI</country>
262	           </civicAddress>
263	       </serviceBoundary>
264	       <uri>sip:esrp@finland-example.com</uri>
265	       <uri>xmpp:esrp@finland-example.com</uri>
266	       <serviceNumber>112</serviceNumber>
267	   </mapping>

269	       Figure 4: Forest Guide Finland / Co-Located LoST Server Mapping
270	                                 XML Snippet

272	   The LoST sync mechanism described in this document could be run
273	   between the two Forest Guides.  Thereby, the three mappings stored in
274	   the Austria FG are sent to the FG Finland and a single mapping in the
275	   FG Finland is sent to the FG Austria.  Additionally, the three
276	   Austrian LoST servers could utilize LoST sync to inform the Austrian
277	   FG about their boundaries.  These three authoritative mapping servers
278	   in Austria would be responsible to maintain their own mapping
279	   information.  Since the amount of data being exchanged is small and
280	   the expected rate of change is low the nodes are configured to always
281	   exchange all their mapping information whenever a change happens.

283	   This document defines two types of exchanges and those are best
284	   described by the exchange between two nodes as shown in Figure 5 and
285	   Figure 6.  The protocol exchange always runs between a LoST Sync
286	   source and a LoST Sync destination.  Node A in the examples of
287	   Figure 5 and Figure 6 has mappings that Node B is going to retrieve.
288	   Node A acts as the source for the data and Node B is the destination.

290	   The <getMappingsRequest> request allows a LoST Sync source to request
291	   mappings from a LoST Sync destination.

293	      +---------+                   +---------+
294	      | Node B  |                   | Node A  |
295	      | acting  |                   | acting  |
296	      | as      |                   | as      |
297	      | LoST    |                   | LoST    |
298	      | Sync    |                   | Sync    |
299	      | Dest.   |                   | Source  |
300	      +---------+                   +---------+
301	          |                              |
302	          |                              |
303	          |                              |
304	          | <getMappingsRequest>         |
305	          |----------------------------->|
306	          |                              |
307	          | <getMappingsResponse>        |
308	          |<-----------------------------|
309	          |                              |
310	          |                              |
311	          |                              |

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

315	   Note that in the exchange illustrated in Figure 5 Node B is issuing
316	   the first request and plays the role of the HTTPS client and Node A
317	   plays the role of the HTTPS server.

319	   The <pushMappingsRequest> exchange allows a LoST Sync source to push
320	   mappings to LoST Sync destination.  The assumption is being made that
321	   Node A and B have previously been configured in a way that they push
322	   mappings in such a fashion and that Node A maintains state about the
323	   mappings have to be pushed to Node B. No subscribe mechanism is
324	   defined in this document that would allow Node B to tell Node A about
325	   what mappings it is interested nor a mechanism for learning to which
326	   entities mappings have to be pushed.

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

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

350	   Note that in the exchange illustrated in Figure 6 Node A issuing the
351	   first request and plays the role of the HTTPS client and Node B plays
352	   the role of the HTTPS server.

354	2.  Terminology

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

360	   This document reuses terminology introduced by the mapping
361	   architecture document [RFC5582], such as 'coverage region', 'forest
362	   guide', 'mapping', 'authoritative mapping server', etc..

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

368	3.  Querying for Mappings with a <getMappingsRequest> /
369	    <getMappingsResponse> Exchange

371	3.1.  Behavior of the LoST Sync Destination

373	   A LoST Sync destination has two ways to retrieve mapping elements
374	   from a LoST Sync source.

376	   1.  A mechanisms that is suitable when no mappings are available on
377	       the LoST Sync destination is to submit an empty
378	       <getMappingsRequest> message, as shown in Figure 7.  The intent
379	       by the LoST Sync destination thereby is to retrieve all mappings
380	       from the LoST Sync source.  Note that the request does not
381	       propagate further to other nodes.

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

392	   In response to the <getMappingsRequest> message the LoST Sync
393	   destination waits for the <getMappingsResponse> message.  In case of
394	   a successful response the LoST Sync destination stores the received
395	   mappings and determines which mappings to update.

397	3.2.  Behavior of the LoST Sync Source

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

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

410	   Processing a <getMappingsRequest> message MAY lead to a successful
411	   response in the form of a <getMappingsResponse> or an <errors>
412	   message.  Only the <badRequest>, <forbidden>, <internalError>,
413	   <serverTimeout> errors, defined in [RFC5222], are utilized by this
414	   specification.  Neither the <redirect> nor the <warnings> messages
415	   are reused by this message.

417	3.3.  Examples

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

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

425	          Figure 7: Example of empty <getMappingsRequest> message

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

436	   <?xml version="1.0" encoding="UTF-8"?>
437	   <getMappingsRequest xmlns="urn:ietf:params:xml:ns:lostsync1">
438	       <exists>
439	           <mapping-fingerprint source="authoritative.bar.example"
440	           sourceId="7e3f40b098c711dbb6060800200c9a66"
441	           lastUpdated="2006-11-01T01:00:00Z">
442	           </mapping-fingerprint>
443	       </exists>
444	   </getMappingsRequest>

446	              Figure 8: Example <getMappingsRequest> Message

448	   The response to the above request is shown in Figure 9.  A more
449	   recent mapping was available with the identification of
450	   source="authoritative.bar.example" and
451	   sourceId="7e3f40b098c711dbb6060800200c9a66".  Only one mapping that
452	   matched source="authoritative.foo.example" was found and returned.

454	  <?xml version="1.0" encoding="UTF-8"?>
455	  <sync:getMappingsResponse
456	      xmlns:sync="urn:ietf:params:xml:ns:lostsync1"
457	      xmlns="urn:ietf:params:xml:ns:lost1"
458	      xmlns:gml="http://www.opengis.net/gml">

460	          <mapping source="authoritative.bar.example"
461	              sourceId="7e3f40b098c711dbb6060800200c9a66"
462	              lastUpdated="2008-11-26T01:00:00Z"
463	              expires="2009-12-26T01:00:00Z">
464	              <displayName xml:lang="en">Leonia Police Department
465	              </displayName>
466	              <service>urn:service:sos.police</service>
467	              <serviceBoundary
468	  profile="urn:ietf:params:lost:location-profile:basic-civic">
469	                  <civicAddress
470	  xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
471	                      <country>US</country>
472	                      <A1>NJ</A1>
473	                      <A3>Leonia</A3>
474	                      <PC>07605</PC>
475	                  </civicAddress>
476	              </serviceBoundary>
477	              <uri>sip:police@leonianj2.example.org</uri>
478	              <serviceNumber>911</serviceNumber>
479	          </mapping>

481	          <mapping expires="2009-01-01T01:44:33Z"
482	              lastUpdated="2008-11-01T01:00:00Z"
483	              source="authoritative.foo.example"
484	              sourceId="7e3f40b098c711dbb606011111111111">
485	              <displayName xml:lang="en">New York City Police Department
486	              </displayName>
487	              <service>urn:service:sos.police</service>
488	              <serviceBoundary profile="geodetic-2d">
489	                  <gml:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
490	                      <gml:exterior>
491	                          <gml:LinearRing>
492	                              <gml:pos>37.775 -122.4194</gml:pos>
493	                              <gml:pos>37.555 -122.4194</gml:pos>
494	                              <gml:pos>37.555 -122.4264</gml:pos>
495	                              <gml:pos>37.775 -122.4264</gml:pos>
496	                              <gml:pos>37.775 -122.4194</gml:pos>
497	                          </gml:LinearRing>
498	                      </gml:exterior>
499	                  </gml:Polygon>
500	              </serviceBoundary>
501	              <uri>sip:nypd@example.com</uri>
502	              <uri>xmpp:nypd@example.com</uri>
503	              <serviceNumber>911</serviceNumber>
504	          </mapping>

506	  </sync:getMappingsResponse>

508	              Figure 9: Example <getMappingsResponse> Message

510	4.  Pushing Mappings via <pushMappings> and <pushMappingsResponse>

512	4.1.  Behavior of the LoST Sync Source

514	   When a LoST Sync source obtains new information that is of interest
515	   to its peers, it may push the new mappings to its peers.
516	   Configuration settings at both peers decide whether this
517	   functionality is used and what mappings are pushed to which other
518	   peers.  New mappings may arrive through various means, such as a
519	   manual addition to the local mapping database, or through the
520	   interaction with other entities.  Deleting mappings may also trigger
521	   a protocol interaction.

523	   The LoST Sync source SHOULD keep track to which LoST Sync destination
524	   it has pushed mapping elements.  If it does not keep state
525	   information then it always has to push the complete data set.  As
526	   discussed in Section 5.1 of [RFC5222], mapping elements are
527	   identified by the 'source', 'sourceID' and 'lastUpdated' attributes.
528	   A mapping is considered the same if these three attributes match.  It
529	   is RECOMMENDED not to push the same information to the same peer more
530	   than once.

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

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

547	4.2.  Behavior of the LoST Sync Destination

549	   When a LoST Sync destination receives a <pushMappingsRequest> message
550	   then the cache with the existing mappings is inspected to determine
551	   whether the received mapping should lead to an update of an already
552	   existing mapping, should create a new mapping in the cache, or should
553	   be discarded.

555	   A newly received mapping MUST update an existing one having the same
556	   'source' and 'sourceId' and a more recent time in 'lastUpdated'.

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

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

566	   If no mapping can be identified then an <errors> response MUST be
567	   returned that contains the <notDeleted> child element.  The
568	   <notDeleted> element MAY contain a 'message' attribute with an error
569	   description used for debugging purposes.  The <notDeleted> element
570	   MUST contain the <mapping> element(s) that caused the error.

572	   The response to a <pushMappingsRequest> request is a
573	   <pushMappingsResponse> message.  With this specification, a
574	   successful response message returns no additional elements, whereas
575	   an <errors> response is returned in the response message, if the
576	   request failed.  Only the <badRequest>, <forbidden>, <internalError>
577	   or <serverTimeout> errors defined in Section 13.1 of [RFC5222], are
578	   used.  The <redirect> and <warnings> messages are not used for this
579	   query/response.

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

588	4.3.  Example

590	   An example is shown in Figure 10.  Image a LoST node that obtained
591	   two new mappings identified as follows:

593	   o

595	   source="authoritative.example"
596	   sourceId="7e3f40b098c711dbb6060800200c9a66"
597	   lastUpdated="2008-11-26T01:00:00Z"

599	   o

601	   source="authoritative.example"
602	   sourceId="7e3f40b098c711dbb606011111111111"
603	   lastUpdated="2008-11-01T01:00:00Z"

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

607	   Additionally, the following mapping has to be deleted:

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

612	  <?xml version="1.0" encoding="UTF-8"?>
613	  <sync:pushMappings
614	      xmlns:sync="urn:ietf:params:xml:ns:lostsync1"
615	      xmlns="urn:ietf:params:xml:ns:lost1"
616	      xmlns:gml="http://www.opengis.net/gml">

618	          <mapping source="authoritative.example"
619	              sourceId="7e3f40b098c711dbb6060800200c9a66"
620	              lastUpdated="2008-11-26T01:00:00Z"
621	              expires="2009-12-26T01:00:00Z">
622	              <displayName xml:lang="en">Leonia Police Department
623	              </displayName>
624	              <service>urn:service:sos.police</service>
625	              <serviceBoundary
626	       profile="urn:ietf:params:lost:location-profile:basic-civic">
627	                  <civicAddress
628	       xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
629	                      <country>US</country>
630	                      <A1>NJ</A1>
631	                      <A3>Leonia</A3>
632	                      <PC>07605</PC>
633	                  </civicAddress>
634	              </serviceBoundary>
635	              <uri>sip:police@leonianj.example.org</uri>
636	              <serviceNumber>911</serviceNumber>
637	          </mapping>

639	          <mapping expires="2009-01-01T01:44:33Z"
640	              lastUpdated="2008-11-01T01:00:00Z"
641	              source="authoritative.example"
642	              sourceId="7e3f40b098c711dbb606011111111111">
643	              <displayName xml:lang="en">New York City Police Department
644	              </displayName>
645	              <service>urn:service:sos.police</service>
646	              <serviceBoundary profile="geodetic-2d">
647	                  <gml:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
648	                      <gml:exterior>
649	                          <gml:LinearRing>
650	                              <gml:pos>37.775 -122.4194</gml:pos>
651	                              <gml:pos>37.555 -122.4194</gml:pos>
652	                              <gml:pos>37.555 -122.4264</gml:pos>
653	                              <gml:pos>37.775 -122.4264</gml:pos>
654	                              <gml:pos>37.775 -122.4194</gml:pos>
655	                          </gml:LinearRing>
656	                      </gml:exterior>
657	                  </gml:Polygon>
658	              </serviceBoundary>
659	              <uri>sip:nypd@example.com</uri>
660	              <uri>xmpp:nypd@example.com</uri>
661	              <serviceNumber>911</serviceNumber>
662	          </mapping>

664	          <mapping source="nj.us.example"
665	              sourceId="123"
666	              lastUpdated="2008-11-01T01:00:00Z"
667	              expires="2008-11-01T01:00:00Z"/>

669	  </sync:pushMappings>

671	             Figure 10: Example <pushMappingsRequest> Message

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

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

682	                 Figure 11: Example <pushMappingsResponse>

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

687	   <?xml version="1.0" encoding="UTF-8"?>
688	   <errors xmlns="urn:ietf:params:xml:ns:lost1"
689	       xmlns:sync="urn:ietf:params:xml:ns:lostsync1"
690	       source="nodeA.example.com">

692	       <sync:notDeleted
693	           message="Could not delete the indicated mapping."
694	           xml:lang="en">

696	           <mapping source="nj.us.example"
697	               sourceId="123"
698	               lastUpdated="2008-11-01T01:00:00Z"
699	               expires="2008-11-01T01:00:00Z"/>
700	       </sync:notDeleted>
701	   </errors>

703	                    Figure 12: Example <errors> Message

705	5.  Transport

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

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

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

721	6.  RelaxNG

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

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

729	        <grammar ns="urn:ietf:params:xml:ns:lostsync1"
730	        xmlns="http://relaxng.org/ns/structure/1.0"
731	        xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
732	        datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">

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

736	            <start combine="choice">

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

741	                <choice>
742	                    <ref name="pushMappings"/>
743	                    <ref name="pushMappingsResponse"/>
744	                    <ref name="getMappingsRequest"/>
745	                    <ref name="getMappingsResponse"/>
746	                </choice>
747	            </start>

749	            <define name="pushMappings">
750	                <element name="pushMappings">
751	                        <oneOrMore>
752	                            <ref name="mapping"/>
753	                        </oneOrMore>

755	                    <ref name="extensionPoint"/>
756	                </element>
757	            </define>

759	            <define name="pushMappingsResponse">
760	                <element name="pushMappingsResponse">
761	                    <ref name="extensionPoint"/>
762	                </element>
763	            </define>

765	             <define name="getMappingsRequest">
766	                  <element name="getMappingsRequest">
767	                    <choice>
768	                         <ref name="exists"></ref>
769	                         <ref name="extensionPoint"/>
770	                    </choice>
771	                </element>
772	            </define>

774	             <define name="exists">
775	                  <element name="exists">
776	                       <oneOrMore>
777	                            <element name="mapping-fingerprint">
778	                                 <attribute name="source">
779	                                      <data type="token"/>
780	                                 </attribute>
781	                                 <attribute name="sourceId">
782	                                      <data type="token"/>
783	                                 </attribute>
784	                                 <attribute name="lastUpdated">
785	                                      <data type="dateTime"/>
786	                                 </attribute>
787	                                 <ref name="extensionPoint"/>
788	                            </element>
789	                       </oneOrMore>
790	                  </element>
791	             </define>

793	            <define name="getMappingsResponse">
794	                <element name="getMappingsResponse">
795	                        <oneOrMore>
796	                            <ref name="mapping"/>
797	                        </oneOrMore>
798	                    <ref name="extensionPoint"/>
799	                </element>
800	            </define>

802	             <!-- error messages -->

804	             <define name="notDeleted">
805	                  <element name="notDeleted">
806	                       <ref name="basicException"/>
807	                       <oneOrMore>
808	                            <ref name="mapping"/>
809	                       </oneOrMore>
810	                  </element>
811	             </define>
812	        </grammar>

814	7.  Operational Considerations

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

824	        A -------- B
825	         \        /
826	          \      /
827	           \    /
828	            \  /
829	             C

831	             Figure 13: Synchronization Configuration Example

833	   Now, imagine that server A adds a new mapping.  This mapping is
834	   uniquely identified by the combination of "source", "sourceid" and
835	   "last updated".  Assume that A would push this new mapping to B and
836	   C. When B obtained this new mapping it would find out that it has to
837	   distribute it to its peer C. C would also want to distribute the
838	   mapping to B. If the original mapping with the "source", "sourceid"
839	   and "last updated" is not modified by either B or C then these two
840	   servers would recognize that they already possess the mapping and can
841	   ignore the update.

843	   It is important that implementations MUST NOT modify mappings they
844	   receive.  An entity acting maliciously would, however, intentially
845	   modify mappings or inject bogus mappings.  To avoid the possibility
846	   of an untrustworthy member claiming a coverage region that it is not
847	   authorized for, authoritative mapping server MUST sign mappings they
848	   distribute using an XML digital signature
849	   [W3C.REC-xmldsig-core-20020212].  A recipient MUST verify that the
850	   signing entity is indeed authorized to speak for that region.  In
851	   many cases, this will require an out-of-band agreement to be in place
852	   to agree on specific entities to take on this role.  Determining who
853	   can speak for a particular region is inherently difficult unless
854	   there is a small set of authorizing entities that participants in the
855	   mapping architecture can trust.  Receiving systems should be
856	   particularly suspicious if an existing coverage region is replaced by
857	   a new one that contains a different value in the <uri> element.  With
858	   digitially singed mappings mappings cannot be modified by
859	   intermediate LoST servers.

861	8.  Security Considerations

863	   This document defines a protocol for exchange of mapping information
864	   between two entities.  Hence, the protocol operations described in
865	   this document require authentication of neighboring nodes.

867	   The LoST Sync client and servers MUST implement TLS and use TLS.
868	   Which version(s) ought to be implemented will vary over time, and
869	   depend on the widespread deployment and known security
870	   vulnerabilities at the time of implementation.  At the time of this
871	   writing, TLS version 1.2 [RFC5246] is the most recent version, but
872	   has very limited actual deployment, and might not be readily
873	   available in implementation toolkits.  TLS version 1.0 [RFC2246] is
874	   the most widely deployed version, and will give the broadest
875	   interoperability.

877	   An additional threat is caused by compromised or misconfigured LoST
878	   servers.  A denial of service could be the consequence of an injected
879	   mapping.  If the mapping data contains an URL that does not exist
880	   then emergency services for the indicated area are not reachable.  If
881	   all mapping data contains URLs that point to a single PSAP (rather
882	   than a large number of PSAPs) then this PSAP is likely to experience
883	   overload conditions.  If the mapping data contains a URL that points
884	   to a server controlled by the adversary itself then it might
885	   impersonate PSAPs.

887	   Section 7 discusses this security threat and mandates signed
888	   mappings.  For unusal changes to the mapping database approval by a
889	   system administrator of the emergency services infrastructure (or a
890	   similar expert) may be required before any mappings are installed.

892	9.  IANA Considerations

894	9.1.  Content-type registration for 'application/lostsync+xml'

896	   This specification requests the registration of a new MIME type
897	   according to the procedures of RFC 4288 [RFC4288] and guidelines in
898	   RFC 3023 [RFC3023].

900	   Type name:  application

902	   Subtype name:  lostsync+xml

904	   Required parameters:  none

906	   Optional parameters:  charset

908	      Indicates the character encoding of enclosed XML.

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

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

921	   Interoperability considerations:  None

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

926	   Applications which use this media type:  Emergency and Location-based
927	      Systems

929	   Additional information:

931	      Magic number(s):  None

933	      File extension(s):  .lostsyncxml

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

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

940	   Intended usage:  LIMITED USE

942	   Restrictions on usage:  None

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

946	   Change controller:

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

951	   Change controller:

953	      The IESG <iesg@ietf.org>

955	9.2.  LoST Sync Relax NG Schema Registration

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

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

962	   Relax NG Schema:  The Relax NG schema to be registered is contained
963	      in Section 6.

965	9.3.  LoST Synchronization Namespace Registration

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

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

972	   XML:

974	   BEGIN
975	   <?xml version="1.0"?>
976	   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
977	     "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
978	   <html xmlns="http://www.w3.org/1999/xhtml">
979	   <head>
980	     <meta http-equiv="content-type"
981	           content="text/html;charset=iso-8859-1"/>
982	     <title>LoST Synchronization Namespace</title>
983	   </head>
984	   <body>
985	     <h1>Namespace for LoST server synchronization</h1>
986	     <h2>urn:ietf:params:xml:ns:lostsync1</h2>
987	   <p>See <a href="[URL of published RFC]">RFCXXXX
988	       [NOTE TO IANA/RFC-EDITOR:
989	        Please replace XXXX with the RFC number of this
990	       specification.]</a>.</p>
991	   </body>
992	   </html>
993	   END

995	10.  Acknowledgments

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

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

1006	   We would like to thank Robert Sparks for his AD review feedback,
1007	   Bjoern Hoehrmann for his media type review, and Julian Reschke and
1008	   Martin Duerst for their applications area reviews.

1010	11.  References

1012	11.1.  Normative References

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

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

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

1024	   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
1025	              Leach, P., Luotonen, A., and L. Stewart, "HTTP
1026	              Authentication: Basic and Digest Access Authentication",
1027	              RFC 2617, June 1999.

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

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

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

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

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

1044	   [W3C.REC-xmldsig-core-20020212]
1045	              Eastlake, D., Reagle, J., Solo, D., Hirsch, F., and T.
1046	              Roessler, "XML-Signature Syntax and Processing", World
1047	              Wide Web Consortium Second Edition REC-xmldsig-core-
1048	              20020212, June 2008.

1050	11.2.  Informative References

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

1055	Authors' Addresses

1057	   Henning Schulzrinne
1058	   Columbia University
1059	   Department of Computer Science
1060	   450 Computer Science Building
1061	   New York, NY  10027
1062	   US

1064	   Phone: +1 212 939 7004
1065	   Email: hgs+ecrit@cs.columbia.edu
1066	   URI:   http://www.cs.columbia.edu

1068	   Hannes Tschofenig
1069	   Nokia Siemens Networks
1070	   Linnoitustie 6
1071	   Espoo  02600
1072	   Finland

1074	   Phone: +358 (50) 4871445
1075	   Email: Hannes.Tschofenig@gmx.net
1076	   URI:   http://www.tschofenig.priv.at