idnits 2.17.1 

draft-ietf-ecrit-lost-sync-15.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 (January 11, 2012) is 4483 days in the past.  Is this
     intentional?


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

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

  ** 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: 6 errors (**), 0 flaws (~~), 3 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: July 14, 2012                            Nokia Siemens Networks
6	                                                        January 11, 2012

8	  Synchronizing Location-to-Service Translation (LoST) Protocol based
9	                Service Boundaries and Mapping Elements
10	                   draft-ietf-ecrit-lost-sync-15.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 July 14, 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, we call
124	   them 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	   <?xml version="1.0" encoding="UTF-8"?>
183	   <mapping
184	       xmlns="urn:ietf:params:xml:ns:lost1"
185	       xmlns:gml="http://www.opengis.net/gml"
186	       expires="2009-01-01T01:44:33Z"
187	       lastUpdated="2009-12-01T01:00:00Z"
188	       source="east-austria.lost-example.com"
189	       sourceId="e8b05a41d8d1415b80f2cdbb96ccf109">
190	       <displayName xml:lang="en">LoST Server 'East'</displayName>
191	       <service>urn:service:sos</service>
192	       <serviceBoundary profile="geodetic-2d">
193	           <gml:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
194	               <gml:exterior>
195	                   <gml:LinearRing>
196	                       <gml:pos> ... </gml:pos>
197	                       ..... list of coordinates for
198	                       boundary of LoST server 'East'
199	                       <gml:pos> ... </gml:pos>
200	                   </gml:LinearRing>
201	               </gml:exterior>
202	           </gml:Polygon>
203	       </serviceBoundary>
204	       <uri/>
205	   </mapping>

207	              Figure 2: Forest Guide Austria Mapping XML Snippet

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

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

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

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

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

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

248	                Figure 3: Forest Guide Finland Mapping Example

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

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

272	       Figure 4: Forest Guide Finland / Co-Located LoST Server Mapping
273	                                   Example

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

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

293	   The <getMappingsRequest> request allows a LoST Sync source to request
294	   mappings from a LoST Sync destination.

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

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

318	   Note that in the exchange illustrated in Figure 5 Node B issuing the
319	   first request and plays the role of the HTTPS client (with HTTP as
320	   selected transport) and Node A plays the role of the HTTPS server.

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

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

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

353	   Note that in the exchange illustrated in Figure 6 Node A issuing the
354	   first request and plays the role of the HTTPS client (with HTTP as
355	   selected transport) and Node B plays the role of the HTTPS server.

357	2.  Terminology

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

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

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

371	3.  Querying for Mappings with a <getMappingsRequest> /
372	    <getMappingsResponse> Exchange

374	3.1.  Behavior of the LoST Sync Destination

376	   A LoST Sync destination has two ways to retrieve mapping elements
377	   from a LoST Sync source.

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

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

395	   In response to the <getMappingsRequest> message the LoST Sync
396	   destination waits for the <getMappingsResponse> message.  In case of
397	   a successful response the LoST Sync destination stores the received
398	   mappings and determines which mappings to replace.

400	3.2.  Behavior of the LoST Sync Source

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

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

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

420	3.3.  Examples

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

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

428	          Figure 7: Example of empty <getMappingsRequest> message

430	   A further example request is shown in Figure 8 and the corresponding
431	   response is depicted in Figure 9.  In this example a request is made
432	   for a specific mapping (with source="authoritative.bar.example" and
433	   sourceId="7e3f40b098c711dbb6060800200c9a66") that is more recent than
434	   "2006-11-01T01:00:00Z" 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 a newly received mapping M' MUST replace an existing mapping M
551	   if all of the following conditions hold:

553	   1.  M'.source equals M.source

555	   2.  M'.sourceID' equals M.sourceID
556	   3.  M'.lastUpdated is greater than M.lastUpdated

558	   If the received mapping M' does not update any existing mapping M
559	   then it MUST be added to the local cache as an independent mapping.

561	   If a <pushMappingsRequest> message with an empty <mapping> element is
562	   received then a corresponding mapping has to be determined based on
563	   the 'source', 'sourceID' and 'lastUpdated' attributes.  If a mapping
564	   has been found then it MUST be deleted.  If no mapping can be
565	   identified then an <errors> response MUST be returned that contains
566	   the <notDeleted> child element.  The <notDeleted> element MAY carry a
567	   <message> element and MUST contain the <mapping> element(s) that
568	   caused the error.

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

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

586	4.3.  Example

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

591	   o  source="authoritative.example"
592	      sourceId="7e3f40b098c711dbb6060800200c9a66" lastUpdated="2008-11-
593	      26T01:00:00Z"

595	   o  source="authoritative.example"
596	      sourceId="7e3f40b098c711dbb606011111111111" lastUpdated="2008-11-
597	      01T01:00:00Z"

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

601	   Additionally, the following mapping has to be deleted:

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

606	  <?xml version="1.0" encoding="UTF-8"?>
607	  <sync:pushMappings
608	      xmlns:sync="urn:ietf:params:xml:ns:lostsync1"
609	      xmlns="urn:ietf:params:xml:ns:lost1"
610	      xmlns:gml="http://www.opengis.net/gml">

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

633	          <mapping expires="2009-01-01T01:44:33Z"
634	              lastUpdated="2008-11-01T01:00:00Z"
635	              source="authoritative.example"
636	              sourceId="7e3f40b098c711dbb606011111111111">
637	              <displayName xml:lang="en">New York City Police Department
638	              </displayName>
639	              <service>urn:service:sos.police</service>
640	              <serviceBoundary profile="geodetic-2d">
641	                  <gml:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
642	                      <gml:exterior>
643	                          <gml:LinearRing>
644	                              <gml:pos>37.775 -122.4194</gml:pos>
645	                              <gml:pos>37.555 -122.4194</gml:pos>
646	                              <gml:pos>37.555 -122.4264</gml:pos>
647	                              <gml:pos>37.775 -122.4264</gml:pos>
648	                              <gml:pos>37.775 -122.4194</gml:pos>
649	                          </gml:LinearRing>

651	                      </gml:exterior>
652	                  </gml:Polygon>
653	              </serviceBoundary>
654	              <uri>sip:nypd@example.com</uri>
655	              <uri>xmpp:nypd@example.com</uri>
656	              <serviceNumber>911</serviceNumber>
657	          </mapping>

659	          <mapping source="nj.us.example"
660	              sourceId="123"
661	              lastUpdated="2008-11-01T01:00:00Z"
662	              expires="2008-11-01T01:00:00Z"/>

664	  </sync:pushMappings>

666	             Figure 10: Example <pushMappingsRequest> Message

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

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

677	                 Figure 11: Example <pushMappingsResponse>

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

682	   <?xml version="1.0" encoding="UTF-8"?>
683	   <errors xmlns="urn:ietf:params:xml:ns:lost1"
684	       xmlns:sync="urn:ietf:params:xml:ns:lostsync1"
685	       source="nodeA.example.com">

687	       <sync:notDeleted
688	           message="Could not delete the indicated mapping."
689	           xml:lang="en">

691	           <mapping source="nj.us.example"
692	               sourceId="123"
693	               lastUpdated="2008-11-01T01:00:00Z"
694	               expires="2008-11-01T01:00:00Z"/>
695	       </sync:notDeleted>
696	   </errors>
697	                    Figure 12: Example <errors> Message

699	5.  Transport

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

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

709	   All LoST Sync responses, including those indicating a LoST warning or
710	   error, are carried in 2xx responses, typically 200 (OK).  Other 2xx
711	   responses, in particular 203 (Non-authoritative information) may be
712	   returned by HTTP caches that disregard the caching instructions. 3xx,
713	   4xx and 5xx HTTP response codes indicates that the HTTP request
714	   itself failed or was redirected; these responses do not contain any
715	   LoST Sync XML elements.

717	6.  RelaxNG

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

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

725	        <grammar ns="urn:ietf:params:xml:ns:lostsync1"
726	        xmlns="http://relaxng.org/ns/structure/1.0"
727	        xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
728	        datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">

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

732	            <start combine="choice">

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

737	                <choice>
738	                    <ref name="pushMappings"/>
739	                    <ref name="pushMappingsResponse"/>
740	                    <ref name="getMappingsRequest"/>
741	                    <ref name="getMappingsResponse"/>
742	                </choice>
743	            </start>

745	            <define name="pushMappings">
746	                <element name="pushMappings">
747	                        <oneOrMore>
748	                            <ref name="mapping"/>
749	                        </oneOrMore>

751	                    <ref name="extensionPoint"/>
752	                </element>
753	            </define>

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

761	             <define name="getMappingsRequest">
762	                  <element name="getMappingsRequest">
763	                    <choice>
764	                         <ref name="exists"></ref>
765	                         <ref name="extensionPoint"/>
766	                    </choice>
767	                </element>
768	            </define>

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

789	            <define name="getMappingsResponse">
790	                <element name="getMappingsResponse">
791	                        <oneOrMore>
792	                            <ref name="mapping"/>
793	                        </oneOrMore>
794	                    <ref name="extensionPoint"/>
795	                </element>
796	            </define>

798	             <!-- error messages -->

800	             <define name="notDeleted">
801	                  <element name="notDeleted">
802	                       <ref name="basicException"/>
803	                       <oneOrMore>
804	                            <ref name="mapping"/>
805	                       </oneOrMore>
806	                  </element>
807	             </define>
808	        </grammar>

810	7.  Operational Considerations

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

820	        A -------- B
821	         \        /
822	          \      /
823	           \    /
824	            \  /
825	             C

827	             Figure 13: Synchronization Configuration Example

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

839	   It is important that implementations MUST NOT modify mappings they
840	   receive.  An entity acting maliciously would, however, intentially
841	   modify mappings or inject bogus mappings.  To avoid the possibility
842	   of an untrustworthy member claiming a coverage region that it is not
843	   authorized for, any node introducing a new service boundary MUST sign
844	   the object by protecting the data with an XML digital signature
845	   [W3C.REC-xmldsig-core-20020212].  A recipient MUST verify that the
846	   signing entity is indeed authorized to speak for that region.
847	   Determining who can speak for a particular region is inherently
848	   difficult unless there is a small set of authorizing entities that
849	   participants in the mapping architecture can trust.  Receiving
850	   systems should be particularly suspicious if an existing coverage
851	   region is replaced with a new one with a new mapping address.  With
852	   this mechanism it is also possible to avoid the distribution of
853	   mappings that have been modified by servers forwarding mappings as
854	   part of the synchronization procedure.

856	8.  Security Considerations

858	   This document defines a protocol for exchange of mapping information
859	   between two entities.  Hence, the operations described in this
860	   document involve mutually-trusting LoST nodes.  These nodes MUST
861	   authenticate each other, using mechanisms such as HTTP Digest
862	   [RFC2617] over TLS, HTTP Basic [RFC2617] over TLS [RFC5246] or TLS
863	   client and server certificates.  Manual configuration for the setup
864	   of the peering relationships is required and hence the choice of the
865	   security mechanisms used between the two entities is a deployment
866	   specific decision.  In any case, TLS MUST be implemented and used.
867	   TLS provides a secure communication channel, an integrity and
868	   confidentiality protected exchange of data with the help of the TLS
869	   Record Layer, and prevents intermediaries to injecting bogus
870	   mappings.

872	   An additional threat is caused by compromised or misconfigured LoST
873	   servers.  A denial of service could be the consequence of an injected
874	   mapping.  If the mapping data contains an URL that does not exist
875	   then emergency services for the indicated area are not reachable.  If
876	   all mapping data contains URLs that point to a single PSAP (rather
877	   than a large number of PSAPs) then this PSAP is likely to experience
878	   overload conditions.  If the mapping data contains a URL that points
879	   to a server controlled by the adversary itself then it might
880	   impersonate PSAPs.  Section 7 discusses this issue and recommends
881	   individually signed mappings.  For unusal changes to the mapping
882	   database approval by an expert may be required before any mappings
883	   are installed.

885	9.  IANA Considerations

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

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

893	   Type name:  application

895	   Subtype name:  lostsync+xml

897	   Required parameters:  none

899	   Optional parameters:  charset

901	      Indicates the character encoding of enclosed XML.

903	   Encoding considerations:  Identical to those of "application/xml" as
904	      described in RFC 3023 [RFC3023], Section 3.2.

906	   Security considerations:  This content type is designed to carry LoST
907	      Synchronization protocol payloads described in RFCXXXX.  The
908	      security considerations section of RFCXXXX is applicable.  In
909	      addition, as this media type uses the "+xml" convention, it shares
910	      the same security considerations as described in RFC 3023
911	      [RFC3023], Section 10.  [NOTE TO IANA/RFC-EDITOR: Please replace
912	      XXXX with the RFC number of this specification.]

914	   Interoperability considerations:  None

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

919	   Applications which use this media type:  Emergency and Location-based
920	      Systems

922	   Additional information:

924	      Magic number(s):  None

926	      File extension(s):  .lostsyncxml

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

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

933	   Intended usage:  LIMITED USE

935	   Restrictions on usage:  None

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

939	   Change controller:

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

944	   Change controller:

946	      The IESG <iesg@ietf.org>

948	9.2.  LoST Sync Relax NG Schema Registration

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

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

955	   Relax NG Schema:  The Relax NG schema to be registered is contained
956	      in Section 6.

958	9.3.  LoST Synchronization Namespace Registration

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

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

965	   XML:

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

988	10.  Acknowledgments

990	   Robins George, Cullen Jennings, Karl Heinz Wolf, Richard Barnes,
991	   Mayutan Arumaithurai, Alexander Mayrhofer, and Andrew Newton provided
992	   helpful input.  Jari Urpalainen assisted with the Relax NG schema.
993	   We would also like to thank our PROTO shepherd Roger Marshall for his
994	   help with the document.

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

999	   We would like to thank Robert Sparks for his AD review feedback,
1000	   Bjoern Hoehrmann for his media type review, and Julian Reschke for
1001	   his applications area review.

1003	11.  References

1005	11.1.  Normative References

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

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

1014	   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
1015	              Leach, P., Luotonen, A., and L. Stewart, "HTTP
1016	              Authentication: Basic and Digest Access Authentication",
1017	              RFC 2617, June 1999.

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

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

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

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

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

1034	   [W3C.REC-xmldsig-core-20020212]
1035	              Eastlake, D., Reagle, J., Solo, D., Hirsch, F., and T.
1036	              Roessler, "XML-Signature Syntax and Processing", World
1037	              Wide Web Consortium Second Edition REC-xmldsig-core-
1038	              20020212, June 2008.

1040	11.2.  Informative References

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

1045	Authors' Addresses

1047	   Henning Schulzrinne
1048	   Columbia University
1049	   Department of Computer Science
1050	   450 Computer Science Building
1051	   New York, NY  10027
1052	   US

1054	   Phone: +1 212 939 7004
1055	   Email: hgs+ecrit@cs.columbia.edu
1056	   URI:   http://www.cs.columbia.edu

1058	   Hannes Tschofenig
1059	   Nokia Siemens Networks
1060	   Linnoitustie 6
1061	   Espoo  02600
1062	   Finland

1064	   Phone: +358 (50) 4871445
1065	   Email: Hannes.Tschofenig@gmx.net
1066	   URI:   http://www.tschofenig.priv.at