idnits 2.17.1 

draft-ietf-ecrit-lost-sync-12.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 (August 17, 2011) is 4636 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: February 18, 2012                        Nokia Siemens Networks
6	                                                         August 17, 2011

8	  Synchronizing Location-to-Service Translation (LoST) Protocol based
9	                Service Boundaries and Mapping Elements
10	                   draft-ietf-ecrit-lost-sync-12.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 February 18, 2012.

50	Copyright Notice

52	   Copyright (c) 2011 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  . . . . . . . . . . . . . . . . . . . . . . . . . . 18
80	   6.  RelaxNG  . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
81	   7.  Operational Considerations . . . . . . . . . . . . . . . . . . 21
82	   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
83	   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
84	     9.1.  Content-type registration for
85	           'application/lostsync+xml' . . . . . . . . . . . . . . . . 23
86	     9.2.  LoST Sync Relax NG Schema Registration . . . . . . . . . . 24
87	     9.3.  LoST Synchronization Namespace Registration  . . . . . . . 24
88	   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 26
89	   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
90	     11.1. Normative References . . . . . . . . . . . . . . . . . . . 27
91	     11.2. Informative References . . . . . . . . . . . . . . . . . . 27
92	   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28

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.  The
537	   node can delete the mapping from its internal mapping database, but
538	   has to remember which peers it has distributed this update to.  The
539	   'expires' attribute is required, but ignored.  If an attempt is made
540	   to delete a non-existent mapping, the request is silently ignored.

542	4.2.  Behavior of the LoST Sync Destination

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

548	   1.  M'.source equals M.source

550	   2.  M'.sourceID' equals M.sourceID

552	   3.  M'.lastUpdated is greater than M.lastUpdated

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

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

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

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

582	4.3.  Example

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

587	   o  source="authoritative.example"
588	      sourceId="7e3f40b098c711dbb6060800200c9a66" lastUpdated="2008-11-
589	      26T01:00:00Z"

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

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

597	   Additionally, the following mapping has to be deleted:

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

602	   <?xml version="1.0" encoding="UTF-8"?>
603	   <sync:pushMappings
604	       xmlns:sync="urn:ietf:params:xml:ns:lostsync1"
605	       xmlns="urn:ietf:params:xml:ns:lost1"
606	       xmlns:gml="http://www.opengis.net/gml">

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

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

655	           </mapping>

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

662	   </sync:pushMappings>

664	             Figure 10: Example <pushMappingsRequest> Message

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

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

675	                 Figure 11: Example <pushMappingsResponse>

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

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

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

689	           <mapping source="nj.us.example"
690	               sourceId="123"
691	               lastUpdated="2008-11-01T01:00:00Z"
692	               expires="2008-11-01T01:00:00Z"/>
693	       </sync:notDeleted>
694	   </errors>

696	                    Figure 12: Example <errors> Message

698	5.  Transport

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

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

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

727	6.  RelaxNG

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

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

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

738	            <start combine="choice">

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

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

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

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

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

767	             <define name="getMappingsRequest">
768	                  <element name="getMappingsRequest">
769	                    <choice>
770	                         <ref name="exists"></ref>
771	                         <ref name="extensionPoint"/>
772	                    </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 (and vice versa).  If the originally mapping with the
842	   "source", "sourceid" and "last updated" is not modified by either B
843	   or C then these two servers would recognize that they already possess
844	   the mapping and can 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, any node introducing a new service boundary MUST sign
851	   the object by protecting the data with 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.
854	   Determining who can speak for a particular region is inherently
855	   difficult unless there is a small set of authorizing entities that
856	   participants in the mapping architecture can trust.  Receiving
857	   systems should be particularly suspicious if an existing coverage
858	   region is replaced with a new one with a new mapping address.  With
859	   this mechanism it is also possible to avoid the distribution of
860	   mappings that have been modified by servers forwarding mappings as
861	   part of the synchronization procedure.

863	8.  Security Considerations

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

886	9.  IANA Considerations

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

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

894	   MIME media type name:  application

896	   MIME subtype name:  lostsync+xml

898	   Mandatory parameters:  none

900	   Optional parameters:  charset

902	      Indicates the character encoding of enclosed XML.

904	   Encoding considerations:  Uses XML, which can employ 8-bit
905	      characters, depending on the character encoding used.  See RFC
906	      3023 [RFC3023], Section 3.2.

908	   Security considerations:  This content type is designed to carry LoST
909	      Syncronization protocol payloads.

911	   Interoperability considerations:  None

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

916	   Applications which use this media type:  Emergency and Location-based
917	      Systems

919	   Additional information:

921	      Magic Number:  None

923	      File Extension:  .lostsyncxml

925	      Macintosh file type code:  'TEXT'

927	   Personal and email address for further information:  Hannes
928	      Tschofenig, Hannes.Tschofenig@nsn.com

930	   Intended usage:  LIMITED USE

932	   Author:

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

937	   Change controller:

939	      The IESG <iesg@ietf.org>

941	9.2.  LoST Sync Relax NG Schema Registration

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

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

948	   Relax NG Schema:  The Relax NG schema to be registered is contained
949	      in Section 6.

951	9.3.  LoST Synchronization Namespace Registration

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

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

958	   XML:

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

981	10.  Acknowledgments

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

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

992	11.  References

994	11.1.  Normative References

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

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

1003	   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
1004	              Leach, P., Luotonen, A., and L. Stewart, "HTTP
1005	              Authentication: Basic and Digest Access Authentication",
1006	              RFC 2617, June 1999.

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

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

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

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

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

1023	   [W3C.REC-xmldsig-core-20020212]
1024	              Solo, D., Eastlake, D., and J. Reagle, "XML-Signature
1025	              Syntax and Processing", World Wide Web Consortium
1026	              FirstEdition REC-xmldsig-core-20020212, February 2002,
1027	              <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212>.

1029	11.2.  Informative References

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

1034	Authors' Addresses

1036	   Henning Schulzrinne
1037	   Columbia University
1038	   Department of Computer Science
1039	   450 Computer Science Building
1040	   New York, NY  10027
1041	   US

1043	   Phone: +1 212 939 7004
1044	   Email: hgs+ecrit@cs.columbia.edu
1045	   URI:   http://www.cs.columbia.edu

1047	   Hannes Tschofenig
1048	   Nokia Siemens Networks
1049	   Linnoitustie 6
1050	   Espoo  02600
1051	   Finland

1053	   Phone: +358 (50) 4871445
1054	   Email: Hannes.Tschofenig@gmx.net
1055	   URI:   http://www.tschofenig.priv.at