idnits 2.17.1 

draft-ietf-ecrit-lost-sync-14.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
  ----------------------------------------------------------------------------

  ** 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 (~~), 2 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-14.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 LoST 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 LoST 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 would
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 Example

209	      As it can be seen in this example there the <uri> element is left
210	      empty and the 'source' attribute is used to indicate the identity
211	      of the LoST server, namely "east-austria.lost-example.com".

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

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

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

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

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

246	                Figure 3: Forest Guide Finland Mapping Example

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

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

270	       Figure 4: Forest Guide Finland / Co-Located LoST Server Mapping
271	                                   Example

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

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

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

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

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

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

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

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

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

352	   Note that in the exchange illustrated in Figure 6 Node A issuing the
353	   first request and plays the role of the HTTP/HTTPS client (with HTTP
354	   as selected transport) and Node B plays the role of the HTTP/HTTPS
355	   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].

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

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

373	3.1.  Behavior of the LoST Sync Destination

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

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

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

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

399	3.2.  Behavior of the LoST Sync Source

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

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

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

419	3.3.  Examples

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

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

427	          Figure 7: Example of empty <getMappingsRequest> message

429	   A further example request is shown in Figure 8 and the corresponding
430	   response is depicted in Figure 9.  In this example a request is made
431	   for a specific mapping (with source="authoritative.bar.example" and
432	   sourceId="7e3f40b098c711dbb6060800200c9a66") that is more recent than
433	   "2006-11-01T01:00:00Z" as well as any missing mapping.

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

445	              Figure 8: Example <getMappingsRequest> Message

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

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

459	           <mapping source="authoritative.bar.example"
460	               sourceId="7e3f40b098c711dbb6060800200c9a66"
461	               lastUpdated="2008-11-26T01:00:00Z"
462	               expires="2009-12-26T01:00:00Z">
463	               <displayName xml:lang="en">
464	                   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">
486	                   New York City Police Department
487	               </displayName>
488	               <service>urn:service:sos.police</service>
489	               <serviceBoundary profile="geodetic-2d">
490	                   <gml:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
491	                       <gml:exterior>
492	                           <gml:LinearRing>
493	                               <gml:pos>37.775 -122.4194</gml:pos>
494	                               <gml:pos>37.555 -122.4194</gml:pos>
495	                               <gml:pos>37.555 -122.4264</gml:pos>
496	                               <gml:pos>37.775 -122.4264</gml:pos>
497	                               <gml:pos>37.775 -122.4194</gml:pos>
498	                           </gml:LinearRing>
499	                       </gml:exterior>
500	                   </gml:Polygon>
501	               </serviceBoundary>
502	               <uri>sip:nypd@example.com</uri>
503	               <uri>xmpp:nypd@example.com</uri>
504	               <serviceNumber>911</serviceNumber>
505	           </mapping>

507	   </sync:getMappingsResponse>

509	              Figure 9: Example <getMappingsResponse> Message

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

513	4.1.  Behavior of the LoST Sync Source

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

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

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

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

548	4.2.  Behavior of the LoST Sync Destination

550	   When a LoST Sync destination receives a <pushMappingsRequest> message
551	   then a newly received mapping M' MUST replace an existing mapping M
552	   if all of the following conditions hold:

554	   1.  M'.source equals M.source

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

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

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

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

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

587	4.3.  Example

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

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

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

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

602	   Additionally, the following mapping has to be deleted:

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

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

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

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

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

666	   </sync:pushMappings>

668	             Figure 10: Example <pushMappingsRequest> Message

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

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

679	                 Figure 11: Example <pushMappingsResponse>

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

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

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

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

700	                    Figure 12: Example <errors> Message

702	5.  Transport

704	   LoST Sync needs an underlying protocol transport mechanism to carry
705	   requests and responses.  This document defines an XML protocol over
706	   HTTP and over HTTP-over-TLS.  Client and server developers are
707	   reminded that full support of RFC 2616 HTTP facilities is expected.
708	   If clients or servers re-implement HTTP, rather than using available
709	   servers or client code as a base, careful attention must be paid to
710	   full interoperability.  Other transport mechanisms are left to future
711	   documents.  The selection of the transport mechanism will in most
712	   cases be determined through manual configuration although the usage
713	   of the U-NAPTR application defined in the LoST specification is
714	   possible.  In protocols that support content type indication, LoST
715	   Sync uses the media type application/lostsync+xml.

717	   When using HTTP [RFC2616] and HTTP-over-TLS [RFC2818], LoST Sync
718	   messages use the HTTP POST method.  The HTTP request MUST use the
719	   Cache-Control response directive "no-cache" to HTTP-level caching
720	   even by caches that have been configured to return stale responses to
721	   client requests.

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

731	6.  RelaxNG

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

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

739	        <grammar ns="urn:ietf:params:xml:ns:lostsync1"
740	        xmlns="http://relaxng.org/ns/structure/1.0"
741	        xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
742	        datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">

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

746	            <start combine="choice">

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

751	                <choice>
752	                    <ref name="pushMappings"/>
753	                    <ref name="pushMappingsResponse"/>
754	                    <ref name="getMappingsRequest"/>
755	                    <ref name="getMappingsResponse"/>
756	                </choice>
757	            </start>

759	            <define name="pushMappings">
760	                <element name="pushMappings">
761	                        <oneOrMore>
762	                            <ref name="mapping"/>
763	                        </oneOrMore>

765	                    <ref name="extensionPoint"/>
766	                </element>
767	            </define>

769	            <define name="pushMappingsResponse">
770	                <element name="pushMappingsResponse">
771	                    <ref name="extensionPoint"/>
772	                </element>
773	            </define>

775	             <define name="getMappingsRequest">
776	                  <element name="getMappingsRequest">
777	                    <choice>
778	                         <ref name="exists"></ref>
779	                         <ref name="extensionPoint"/>
780	                    </choice>
781	                </element>
782	            </define>

784	             <define name="exists">
785	                  <element name="exists">
786	                       <oneOrMore>
787	                            <element name="mapping-fingerprint">
788	                                 <attribute name="source">
789	                                      <data type="token"/>
790	                                 </attribute>
791	                                 <attribute name="sourceId">
792	                                      <data type="token"/>
793	                                 </attribute>
794	                                 <attribute name="lastUpdated">
795	                                      <data type="dateTime"/>
796	                                 </attribute>
797	                                 <ref name="extensionPoint"/>
798	                            </element>
799	                       </oneOrMore>
800	                  </element>
801	             </define>

803	            <define name="getMappingsResponse">
804	                <element name="getMappingsResponse">
805	                        <oneOrMore>
806	                            <ref name="mapping"/>
807	                        </oneOrMore>
808	                    <ref name="extensionPoint"/>
809	                </element>
810	            </define>

812	             <!-- error messages -->

814	             <define name="notDeleted">
815	                  <element name="notDeleted">
816	                       <ref name="basicException"/>
817	                       <oneOrMore>
818	                            <ref name="mapping"/>
819	                       </oneOrMore>
820	                  </element>
821	             </define>
822	        </grammar>

824	7.  Operational Considerations

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

834	        A -------- B
835	         \        /
836	          \      /
837	           \    /
838	            \  /
839	             C

841	             Figure 13: Synchronization Configuration Example

843	   Now, imagine that server A adds a new mapping.  This mapping is
844	   uniquely identified by the combination of "source", "sourceid" and
845	   "last updated".  Assume that A would push this new mapping to B and
846	   C. When B obtained this new mapping it would find out that it has to
847	   distribute it to its peer C. C would also want to distribute the
848	   mapping to B (and vice versa).  If the originally mapping with the
849	   "source", "sourceid" and "last updated" is not modified by either B
850	   or C then these two servers would recognize that they already possess
851	   the mapping and can ignore the update.

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

870	8.  Security Considerations

872	   This document defines a protocol for exchange of mapping information
873	   between two entities.  Hence, the operations described in this
874	   document involve mutually-trusting LoST nodes.  These nodes need to
875	   authenticate each other, using mechanisms such as HTTP Digest
876	   [RFC2617], HTTP Basic [RFC2617] over TLS [RFC5246] or TLS client and
877	   server certificates.  Manual configuration for the setup of the
878	   peering relationships is required and hence the choice of the
879	   security mechanisms used between the two entities is a deployment
880	   specific decision.  In any case, it MUST be ensured that the two end
881	   points are authenticated and that a secure communication channel
882	   (i.e., an integrity protected exchange of data with the help of the
883	   TLS Record Layer) is setup to avoid the possibility of injecting
884	   bogus mappings.  If an adversary manages to inject false mappings
885	   then this could lead to denial of service attacks.  If the mapping
886	   data contains a URL that does not exist then emergency services for
887	   the indicated area are not reachable.  If all mapping data contains
888	   URLs that point to a single PSAP (rather than a large number) then
889	   this PSAP is likely to experience overload conditions.  If the
890	   mapping data contains a URL that points to a server controlled by the
891	   adversary itself then it might impersonate PSAPs.

893	9.  IANA Considerations

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

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

901	   Type name:  application

903	   Subtype name:  lostsync+xml

905	   Required parameters:  none

907	   Optional parameters:  charset

909	      Indicates the character encoding of enclosed XML.

911	   Encoding considerations:  Uses XML, which can employ 8-bit
912	      characters, depending on the character encoding used.  See RFC
913	      3023 [RFC3023], Section 7.1.

915	   Security considerations:  This content type is designed to carry LoST
916	      Syncronization protocol payloads described in RFCXXXX.  [NOTE TO
917	      IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this
918	      specification.]

920	   Interoperability considerations:  None

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

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

928	   Additional information:

930	      Magic number(s):  None

932	      File extension(s):  .lostsyncxml

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

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

939	   Intended usage:  LIMITED USE

941	   Restrictions on usage:  None

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

945	   Change controller:

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

950	   Change controller:

952	      The IESG <iesg@ietf.org>

954	9.2.  LoST Sync Relax NG Schema Registration

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

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

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

964	9.3.  LoST Synchronization Namespace Registration

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

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

971	   XML:

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

994	10.  Acknowledgments

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

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

1005	   We would like to thank Robert Sparks for his AD review feedback, and
1006	   Bjoern Hoehrmann for his media type review.

1008	11.  References

1010	11.1.  Normative References

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

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

1019	   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
1020	              Leach, P., Luotonen, A., and L. Stewart, "HTTP
1021	              Authentication: Basic and Digest Access Authentication",
1022	              RFC 2617, June 1999.

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

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

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

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

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

1039	   [W3C.REC-xmldsig-core-20020212]
1040	              Eastlake, D., Reagle, J., Solo, D., Hirsch, F., and T.
1041	              Roessler, "XML-Signature Syntax and Processing", World
1042	              Wide Web Consortium Second Edition REC-xmldsig-core-
1043	              20020212, June 2008.

1045	11.2.  Informative References

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

1050	Authors' Addresses

1052	   Henning Schulzrinne
1053	   Columbia University
1054	   Department of Computer Science
1055	   450 Computer Science Building
1056	   New York, NY  10027
1057	   US

1059	   Phone: +1 212 939 7004
1060	   Email: hgs+ecrit@cs.columbia.edu
1061	   URI:   http://www.cs.columbia.edu

1063	   Hannes Tschofenig
1064	   Nokia Siemens Networks
1065	   Linnoitustie 6
1066	   Espoo  02600
1067	   Finland

1069	   Phone: +358 (50) 4871445
1070	   Email: Hannes.Tschofenig@gmx.net
1071	   URI:   http://www.tschofenig.priv.at