idnits 2.17.1 

draft-ietf-ecrit-lost-sync-16.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 13, 2012) is 4480 days in the past.  Is this
     intentional?


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

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

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

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

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

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

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

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

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

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


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

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

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


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

8	  Synchronizing Location-to-Service Translation (LoST) Protocol based
9	                Service Boundaries and Mapping Elements
10	                   draft-ietf-ecrit-lost-sync-16.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 16, 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	   <?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 is issuing
319	   the first request and plays the role of the HTTPS client and Node A
320	   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 and Node B plays
355	   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 update.

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 the
432	   <getMappingsRequest> element contains information about the mapping
433	   that is locally available to the client inside the <mapping-
434	   fingerprint> element (with source="authoritative.bar.example",
435	   sourceId="7e3f40b098c711dbb6060800200c9a66", and lastUpdated="2006-
436	   11-01T01:00:00Z").  The query asks for mappings that are more recent
437	   than the available one as well as any missing mapping.

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

449	              Figure 8: Example <getMappingsRequest> Message

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

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

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

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

509	  </sync:getMappingsResponse>

511	              Figure 9: Example <getMappingsResponse> Message

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

515	4.1.  Behavior of the LoST Sync Source

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

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

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

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

550	4.2.  Behavior of the LoST Sync Destination

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

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

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

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

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

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

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

591	4.3.  Example

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

596	   o

598	   source="authoritative.example"
599	   sourceId="7e3f40b098c711dbb6060800200c9a66"
600	   lastUpdated="2008-11-26T01:00:00Z"

602	   o

604	   source="authoritative.example"
605	   sourceId="7e3f40b098c711dbb606011111111111"
606	   lastUpdated="2008-11-01T01:00:00Z"

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

610	   Additionally, the following mapping has to be deleted:

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

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

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

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

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

672	  </sync:pushMappings>

674	             Figure 10: Example <pushMappingsRequest> Message

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

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

685	                 Figure 11: Example <pushMappingsResponse>

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

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

695	       <sync:notDeleted
696	           message="Could not delete the indicated mapping."
697	           xml:lang="en">

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

706	                    Figure 12: Example <errors> Message

708	5.  Transport

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

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

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

724	6.  RelaxNG

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

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

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

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

739	            <start combine="choice">

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

744	                <choice>
745	                    <ref name="pushMappings"/>
746	                    <ref name="pushMappingsResponse"/>
747	                    <ref name="getMappingsRequest"/>
748	                    <ref name="getMappingsResponse"/>
749	                </choice>
750	            </start>

752	            <define name="pushMappings">
753	                <element name="pushMappings">
754	                        <oneOrMore>
755	                            <ref name="mapping"/>
756	                        </oneOrMore>

758	                    <ref name="extensionPoint"/>
759	                </element>
760	            </define>

762	            <define name="pushMappingsResponse">
763	                <element name="pushMappingsResponse">
764	                    <ref name="extensionPoint"/>
765	                </element>
766	            </define>

768	             <define name="getMappingsRequest">
769	                  <element name="getMappingsRequest">
770	                    <choice>
771	                         <ref name="exists"></ref>
772	                         <ref name="extensionPoint"/>
773	                    </choice>
774	                </element>
775	            </define>

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

796	            <define name="getMappingsResponse">
797	                <element name="getMappingsResponse">
798	                        <oneOrMore>
799	                            <ref name="mapping"/>
800	                        </oneOrMore>
801	                    <ref name="extensionPoint"/>
802	                </element>
803	            </define>

805	             <!-- error messages -->

807	             <define name="notDeleted">
808	                  <element name="notDeleted">
809	                       <ref name="basicException"/>
810	                       <oneOrMore>
811	                            <ref name="mapping"/>
812	                       </oneOrMore>
813	                  </element>
814	             </define>
815	        </grammar>

817	7.  Operational Considerations

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

827	        A -------- B
828	         \        /
829	          \      /
830	           \    /
831	            \  /
832	             C

834	             Figure 13: Synchronization Configuration Example

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

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

864	8.  Security Considerations

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

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

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

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

895	9.  IANA Considerations

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

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

903	   Type name:  application

905	   Subtype name:  lostsync+xml

907	   Required parameters:  none

909	   Optional parameters:  charset

911	      Indicates the character encoding of enclosed XML.

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

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

924	   Interoperability considerations:  None

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

929	   Applications which use this media type:  Emergency and Location-based
930	      Systems

932	   Additional information:

934	      Magic number(s):  None

936	      File extension(s):  .lostsyncxml

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

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

943	   Intended usage:  LIMITED USE

945	   Restrictions on usage:  None

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

949	   Change controller:

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

954	   Change controller:

956	      The IESG <iesg@ietf.org>

958	9.2.  LoST Sync Relax NG Schema Registration

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

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

965	   Relax NG Schema:  The Relax NG schema to be registered is contained
966	      in Section 6.

968	9.3.  LoST Synchronization Namespace Registration

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

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

975	   XML:

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

998	10.  Acknowledgments

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

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

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

1013	11.  References

1015	11.1.  Normative References

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

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

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

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

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

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

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

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

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

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

1053	11.2.  Informative References

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

1058	Authors' Addresses

1060	   Henning Schulzrinne
1061	   Columbia University
1062	   Department of Computer Science
1063	   450 Computer Science Building
1064	   New York, NY  10027
1065	   US

1067	   Phone: +1 212 939 7004
1068	   Email: hgs+ecrit@cs.columbia.edu
1069	   URI:   http://www.cs.columbia.edu

1071	   Hannes Tschofenig
1072	   Nokia Siemens Networks
1073	   Linnoitustie 6
1074	   Espoo  02600
1075	   Finland

1077	   Phone: +358 (50) 4871445
1078	   Email: Hannes.Tschofenig@gmx.net
1079	   URI:   http://www.tschofenig.priv.at