idnits 2.17.1 draft-ietf-ecrit-lost-sync-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (October 26, 2009) is 5288 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: 7 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: April 29, 2010 Nokia Siemens Networks 6 October 26, 2009 8 Synchronizing Location-to-Service Translation (LoST) Protocol based 9 Service Boundaries and Mapping Elements 10 draft-ietf-ecrit-lost-sync-08.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 29, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 The Location-to-Service Translation (LoST) protocol is an XML-based 49 protocol for mapping service identifiers and geodetic or civic 50 location information to service URIs and service boundaries. In 51 particular, it can be used to determine the location-appropriate 52 Public Safety Answering Point (PSAP) for emergency services. 54 The main data structure, the element, used for 55 encapsulating information about service boundaries is defined in the 56 LoST protocol specification and circumscribes the region within which 57 all locations map to the same service Uniform Resource Identifier 58 (URI) or set of URIs for a given service. 60 This document defines an XML protocol to exchange these mappings 61 between two nodes. This mechanism is designed for the exchange of 62 authoritative elements between two entities. Exchanging 63 cached elements, i.e. non-authoritative elements, is 64 possible but not envisioned. In any case, this document can also be 65 used without the LoST protocol even though the format of the 66 element is re-used from the LoST specification. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 3. Querying for Mappings with a / 73 Exchange . . . . . . . . . . . . . . . . 11 74 3.1. Behavior of the LoST Sync Source . . . . . . . . . . . . . 11 75 3.2. Behavior of the LoST Sync Source . . . . . . . . . . . . . 11 76 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 4. Pushing Mappings via and 78 . . . . . . . . . . . . . . . . . . . . 14 79 4.1. Behavior of the LoST Sync Source . . . . . . . . . . . . . 14 80 4.2. Behavior of the LoST Sync Destination . . . . . . . . . . 14 81 4.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 5. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 6. RelaxNG . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 86 8.1. Content-type registration for 87 'application/lostsync+xml' . . . . . . . . . . . . . . . . 22 88 8.2. LoST Sync Relax NG Schema Registration . . . . . . . . . . 23 89 8.3. LoST Synchronization Namespace Registration . . . . . . . 23 90 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 92 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 93 10.2. Informative References . . . . . . . . . . . . . . . . . . 26 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 96 1. Introduction 98 The LoST (Location-to-Service Translation) protocol [RFC5222] maps 99 service identifiers and geodetic or civic location information to 100 service URIs. The main data structure, the element, used 101 for encapsulating information about service boundaries is defined in 102 the LoST protocol specification and circumscribes the region within 103 which all locations map to the same service Uniform Resource 104 Identifier (URI) or set of URIs for a given service. 106 This mechanism is designed for the exchange of authoritative 107 elements between two entities (the LoST Sync source and the 108 LoST Sync destination). 110 The LoST Sync mechanism can, for example, be used in the LoST 111 architecture, as specified in the [RFC5582]. There, LoST servers act 112 in different roles that cooperate to provide an ubiquitous, globally 113 scalable and resilient mapping service. In the LoST mapping 114 architecture, LoST servers can peer, i.e., have an on-going data 115 exchange relationship. Peering relationships are set up manually, 116 based on local policies. A server can peer with any number of other 117 servers. Forest guides peer with other forest guides; resolvers peer 118 with forest guides and other resolvers (in the same cluster); 119 authoritative mapping servers peer with forest guides and other 120 authoritative servers, either in the same cluster or above or below 121 them in the tree. Authoritative mapping servers push coverage 122 regions "up" the tree, i.e., from child nodes to parent nodes. The 123 child informs the parent of the geospatial or civic region that it 124 covers for a specific service. 126 Consider a hypothetical deployent of LoST in two countries, we call 127 them Austria and Finland. Austria, in our example, runs three 128 authoritative LoST servers labeled as 'East', 'West' and 'Vienna' 129 whereby the former two cover the entire country expect for Vienna, 130 which is covered by a separate LoST server. There may be other 131 caching LoST servers run by ISPs, universities, and VSPs but they are 132 not relevant for this illustration. Finland, on the other hand, 133 decided to only deploy a single LoST server that also acts as a 134 Forest Guide. For this simplistic illustration we assume that only 135 one service is available, namely 'urn:service:sos' since otherwise 136 the number of stored mappings would have to be multiplied by the 137 number of used services. 139 Figure 1 shows the example deployment. 141 +---LoST-Sync-->\\ //<--LoST-Sync----+ 142 | ----- | 143 | | 144 \/ \/ 145 ----- ----- 146 // \\ // \\ 147 / \ / \ 148 | Forest | | Forest | 149 | Guide | | Guide | 150 | Austria | | Finland 151 \ / \ / 152 +--------->\\ //<--------+ \\ // 153 | ----- | ----- 154 | /\ | | 155 LoST | LoST //------\\ 156 Sync LoST Sync |Co-Located| 157 | Sync | | LoST | 158 \/ | \/ | Server | 159 //----\\ \/ //----\\ \\------// 160 | LoST | //----\\ | LoST | 161 | Server | | LoST | | Server | 162 | (East) | | Server | |(Vienna)| 163 \\----// | (West) | \\----// 164 \\----// 166 Figure 1: LoST Deployment Example 168 The configuration of these nodes would therefore be as follows: 170 Forest Guide Austria: This forest guide would contain mappings for 171 the three authoritative LoST servers (East, West and Vienna) 172 describing what area they are responsible for. Note that each 173 mapping would contain a service URN and these mappings point to 174 LoST servers rather than to PSAPs or ESRPs. 176 LoST Server 'East': This LoST server would contain all the mappings 177 to PSAPs covering one half of the country. 179 Additionally, the LoST server aggregates all the information it 180 has and provides an abstracted view towards the Forest Guide 181 indicating that it is responsible for a certain area (for a given 182 service, and for a given location profile). Such a mapping would 183 have the following structure: 185 190 LoST Server 'East' 191 urn:service:sos 192 193 194 195 196 ... 197 ..... list of coordinates for 198 boundary of LoST server 'East' 199 ... 200 201 202 203 204 205 207 Figure 2: Forest Guide Austria Mapping Example 209 As it can be seen in this example there the 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 234 Finland ESRP 235 urn:service:sos 236 237 239 FI 240 241 242 243 245 Figure 3: Forest Guide Finland Mapping Example 247 An example mapping stored at the co-located LoST server is shown 248 in Figure 4. 250 255 Finland ESRP 256 urn:service:sos 257 258 260 FI 261 262 263 sip:esrp@finland-example.com 264 xmpp:esrp@finland-example.com 265 112 266 268 Figure 4: Forest Guide Finland / Co-Located LoST Server Mapping 269 Example 271 The LoST sync mechanism described in this document could be run 272 between the two Forest Guides. Thereby, the three mappings stored in 273 the Austria FG are sent to the FG Finland and a single mapping in the 274 FG Finland is sent to the FG Austria. Additionally, the three 275 Austrian LoST servers could utilize LoST sync to inform the Austrian 276 FG about their boundaries. These three authoritative LoST servers in 277 Austria would be responsible to maintain their own mapping 278 information. Since the amount of data being exchanged is small and 279 the expected rate of change is low the nodes are configured to always 280 exchange all their mapping information whenever a change happens. 282 This document defines two types of exchanges and those are best 283 described by the exchange between two nodes as shown in Figure 5 and 284 Figure 6. The protocol exchange always runs between a LoST Sync 285 source and a LoST Sync destination. Node A in the examples of 286 Figure 5 and Figure 6 has mappings that Node B is going to retrieve. 287 Node A acts as the source for the data and Node B is the destination. 289 The request allows a LoST Sync source to request 290 mappings from a LoST Sync destination. 292 +---------+ +---------+ 293 | Node B | | Node A | 294 | acting | | acting | 295 | as | | as | 296 | LoST | | LoST | 297 | Sync | | Sync | 298 | Dest. | | Source | 299 +---------+ +---------+ 300 | | 301 | | 302 | | 303 | | 304 |----------------------------->| 305 | | 306 | | 307 |<-----------------------------| 308 | | 309 | | 310 | | 312 Figure 5: Querying for Mappings with a Message 314 Note that in the exchange illustrated in Figure 5 Node B issuing the 315 first request and plays the role of the HTTP/HTTPS client (with HTTP 316 as selected transport) and Node A plays the role of the HTTP/HTTPS 317 server. 319 The exchange allows a LoST Sync source to push 320 mappings to LoST Sync destination. The assumption is being made that 321 Node A and B have previously been configured in a way that they push 322 mappings in such a fashion and that Node A maintains state about the 323 mappings have to be pushed to Node B. No subscribe mechanism is 324 defined in this document that would allow Node B to tell Node A about 325 what mappings it is interested nor a mechanism for learning to which 326 entities mappings have to be pushed. 328 +---------+ +---------+ 329 | Node A | | Node B | 330 | acting | | acting | 331 | as | | as | 332 | LoST | | LoST | 333 | Sync | | Sync | 334 | Source | | Dest. | 335 +---------+ +---------+ 336 | | 337 | | 338 | | 339 | | 340 |----------------------------->| 341 | | 342 | | 343 |<-----------------------------| 344 | | 345 | | 346 | | 348 Figure 6: Pushing Mappings with a Message 350 Note that in the exchange illustrated in Figure 6 Node A issuing the 351 first request and plays the role of the HTTP/HTTPS client (with HTTP 352 as selected transport) and Node B plays the role of the HTTP/HTTPS 353 server. 355 2. Terminology 357 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 358 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 359 document are to be interpreted as described in RFC 2119 [RFC2119]. 361 This document reuses terminology introduced by the mapping 362 architecture document [RFC5582]. 364 Throughout this document we use the term LoST Sync source and LoST 365 Sync destination to denote the protocol end points of the exchange. 366 The protocol is referred as LoST Sync within the text. 368 3. Querying for Mappings with a / 369 Exchange 371 3.1. Behavior of the LoST Sync Source 373 A LoST Sync destination has two ways to retrieve mapping elements 374 from a LoST Sync source. 376 1. A mechanisms that is suitable when no mappings are available on 377 the LoST Sync destination is to submit an empty 378 message, as shown in Figure 7. The intent 379 by the LoST Sync destination thereby is to retrieve all mappings 380 from the LoST Sync source. Note that the request does not 381 propagate further to other nodes. 383 2. In case a LoST Sync destination node has already obtained 384 mappings in previous exchanges then it may want to check whether 385 these mappings have been updated in the meanwhile. The policy 386 when to poll for updated mapping information is outside the scope 387 of this document. The message with one or 388 multiple child element(s) allows to reduce the number of 389 returned mappings to those that have been updated and also to 390 those that are missing. 392 In response to the message the LoST Sync 393 destination waits for the message. In case of 394 a successful response the LoST Sync destination stores the received 395 mappings and determines which mappings to replace. 397 3.2. Behavior of the LoST Sync Source 399 When a LoST Sync source receives an empty 400 message then all locally available mappings MUST be returned. 402 When a LoST Sync source receives a message with 403 one or multiple child element(s) then it MUST consult with 404 the local mapping database to determine whether any of the mappings 405 of the client is stale and whether there are mappings locally that 406 the client does not yet have. The former can be determined by 407 finding mappings corresponding to the 'source' and 'sourceID' 408 attribut where a mapping with a more recent lastUpdated date exists. 410 Processing a message MAY lead to a successful 411 response in the form of a or an 412 message. Only the , , , 413 errors, defined in [RFC5222], are utilized by this 414 specification. Neither the nor the messages 415 are reused by this message. 417 3.3. Examples 419 The first example shows an empty message that 420 would retrieve all locally stored mappings at the LoST Sync source. 422 423 425 Figure 7: Example of empty message 427 A further example request is shown in Figure 8 and the corresponding 428 response is depicted in Figure 9. In this example a request is made 429 for a specific mapping (with source="authoritative.bar.example" and 430 sourceId="7e3f40b098c711dbb6060800200c9a66") that is more recent than 431 "2006-11-01T01:00:00Z". 433 434 435 436 439 440 441 443 Figure 8: Example Message 445 The response to the above request is shown in Figure 9. A more 446 recent mapping was available with the identification of 447 source="authoritative.bar.example" and 448 sourceId="7e3f40b098c711dbb6060800200c9a66". Only one mapping that 449 matched source="authoritative.foo.example" was found and returned. 451 452 457 461 462 Leonia Police Department 463 464 urn:service:sos.police 465 467 469 US 470 NJ 471 Leonia 472 07605 473 474 475 sip:police@leonianj2.example.org 476 911 477 479 483 484 New York City Police Department 485 486 urn:service:sos.police 487 488 489 490 491 37.775 -122.4194 492 37.555 -122.4194 493 37.555 -122.4264 494 37.775 -122.4264 495 37.775 -122.4194 496 497 498 499 500 sip:nypd@example.com 501 xmpp:nypd@example.com 502 911 503 505 507 Figure 9: Example Message 509 4. Pushing Mappings via and 511 4.1. Behavior of the LoST Sync Source 513 When a LoST Sync source obtains new information that is of interest 514 to its peers, it may push the new mappings to its peers. 515 Configuration settings at both peers decide whether this 516 functionality is used and what mappings are pushed to which other 517 peers. New mappings may arrive through various means, such as a 518 manual addition to the local mapping database, or through the 519 interaction with other entities. Deleting mappings may also trigger 520 a protocol interaction. 522 The LoST Sync source SHOULD keep track to which LoST Sync destination 523 it has pushed mapping elements. If it does not keep state 524 information then it always has to push the complete data set. As 525 discussed in Section 5.1 of [RFC5222], mapping elements are 526 identified by the 'source', 'sourceID' and 'lastUpdated' attributes. 527 A mapping is considered the same if these three attributes match. It 528 is RECOMMENDED not to push the same information to the same peer more 529 than once. 531 A request sent by a LoST Sync source MUST containing 532 one or more elements. 534 To delete a mapping, the content of the mapping is left empty. The 535 node can delete the mapping from its internal mapping database, but 536 has to remember which peers it has distributed this update to. The 537 'expires' attribute is required, but ignored. If an attempt is made 538 to delete a non-existent mapping, the request is silently ignored. 540 4.2. Behavior of the LoST Sync Destination 542 When a LoST Sync destination receives a message 543 then a newly received mapping M' MUST replace an existing mapping M 544 if all of the following conditions hold: 546 1. M'.source equals M.source 548 2. M'.sourceID' equals M.sourceID 550 3. M'.lastUpdated is greater than M.lastUpdated 552 If the received mapping M' does not update any existing mapping M 553 then it MUST be added to the local cache as an independent mapping. 555 If a message with an empty element is 556 received then a corresponding mapping has to be determined based on 557 the 'source', 'sourceID' and 'lastUpdated' attributes. If a mapping 558 has been found then it MUST be deleted. If no mapping can be 559 identified then an response MUST be returned that contains 560 the child element. The element MAY carry a 561 element and MUST contain the element(s) that 562 caused the error. 564 The response to a request is a 565 message. With this specification, a 566 successful response message returns no additional elements, whereas 567 an response is returned in the response message, if the 568 request failed. Only the , , 569 or errors defined in Section 13.1 of [RFC5222], are 570 used. The and messages are not used for this 571 query/response. 573 If the set of nodes that are synchronizing their data does not form a 574 tree, it is possible that the same information arrives through 575 several other nodes. This is unavoidable, but generally only imposes 576 a modest overhead. (It would be possible to create a spanning tree 577 in the same fashion as IP multicast, but the complexity does not seem 578 warranted, given the relatively low volume of data.) 580 4.3. Example 582 An example is shown in Figure 10. Image a LoST node that obtained 583 two new mappings identified as follows: 585 o source="authoritative.example" 586 sourceId="7e3f40b098c711dbb6060800200c9a66" lastUpdated="2008-11- 587 26T01:00:00Z" 589 o source="authoritative.example" 590 sourceId="7e3f40b098c711dbb606011111111111" lastUpdated="2008-11- 591 01T01:00:00Z" 593 These two mappings have to be added to the peer's mapping database. 595 Additionally, the following mapping has to be deleted: 597 o source="nj.us.example" sourceId="123" lastUpdated="2008-11- 598 01T01:00:00Z" 600 601 606 610 611 Leonia Police Department 612 613 urn:service:sos.police 614 616 618 US 619 NJ 620 Leonia 621 07605 622 623 624 sip:police@leonianj.example.org 625 911 626 628 632 633 New York City Police Department 634 635 urn:service:sos.police 636 637 638 639 640 37.775 -122.4194 641 37.555 -122.4194 642 37.555 -122.4264 643 37.775 -122.4264 644 37.775 -122.4194 645 646 647 648 649 sip:nypd@example.com 650 xmpp:nypd@example.com 651 911 653 655 660 662 Figure 10: Example Message 664 In response, the peer performs the necessary operation and updates 665 its mapping database. In particular, it will check whether the other 666 peer is authorized to perform the update and whether the elements and 667 attributes contain values that it understands. In our example, a 668 positive response is returned as shown in Figure 11. 670 671 673 Figure 11: Example 675 In case that a mapping could not be deleted as requested the 676 following error response might be returned instead. 678 679 683 687 692 693 695 Figure 12: Example Message 697 5. Transport 699 LoST Sync needs an underlying protocol transport mechanism to carry 700 requests and responses. This document defines an XML protocol over 701 HTTP and over HTTP-over-TLS. Client and server developers are 702 reminded that full support of RFC 2616 HTTP facilities is expected. 703 If clients or servers re-implement HTTP, rather than using available 704 servers or client code as a base, careful attention must be paid to 705 full interoperability. Other transport mechanisms are left to future 706 documents. The selection of the transport mechanism will in most 707 cases be determined through manual configuration although the usage 708 of the U-NAPTR application defined in the LoST specification is 709 possible. In protocols that support content type indication, LoST 710 Sync uses the media type application/lostsync+xml. 712 When using HTTP [RFC2616] and HTTP-over-TLS [RFC2818], LoST Sync 713 messages use the HTTP POST method. The HTTP request MUST use the 714 Cache-Control response directive "no-cache" to HTTP-level caching 715 even by caches that have been configured to return stale responses to 716 client requests. 718 All LoST Sync responses, including those indicating a LoST warning or 719 error, are carried in 2xx responses, typically 200 (OK). Other 2xx 720 responses, in particular 203 (Non-authoritative information) may be 721 returned by HTTP caches that disregard the caching instructions. 3xx, 722 4xx and 5xx HTTP response codes indicates that the HTTP request 723 itself failed or was redirected; these responses do not contain any 724 LoST Sync XML elements. 726 6. RelaxNG 728 730 735 737 739 Location-to-Service Translation (LoST) 740 Synchronization Protocol 742 743 744 745 746 747 748 750 751 752 753 754 756 757 758 760 761 762 763 764 766 767 768 769 770 771 773 774 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 795 796 797 798 799 800 801 802 804 806 807 808 809 810 811 812 813 814 816 7. Security Considerations 818 This document defines a protocol for exchange of mapping information 819 between two entities. Hence, the operations described in this 820 document involve mutually-trusting LoST nodes. These nodes need to 821 authenticate each other, using mechanisms such as HTTP Digest 822 [RFC2617], HTTP Basic [RFC2617] over TLS [RFC5246] or TLS client and 823 server certificates. Manual configuration for the setup of the 824 peering relationships is required and hence the choice of the 825 security mechanisms used between the two entities is a deployment 826 specific decision. In any case, it MUST be ensured that the two end 827 points are authenticated and that a secure communication channel 828 (i.e., an integrity protected exchange of data with the help of the 829 TLS Record Layer) is setup to avoid the possibility of injecting 830 bogus mappings. If an adversary manages to inject false mappings 831 then this could lead to denial of service attacks. If the mapping 832 data contains a URL that does not exist then emergency services for 833 the indicated area are not reachable. If all mapping data contains 834 URLs that point to a single PSAP (rather than a large number) then 835 this PSAP is likely to experience overload conditions. If the 836 mapping data contains a URL that points to a server controlled by the 837 adversary itself then it might impersonate PSAPs. 839 8. IANA Considerations 841 8.1. Content-type registration for 'application/lostsync+xml' 843 This specification requests the registration of a new MIME type 844 according to the procedures of RFC 4288 [RFC4288] and guidelines in 845 RFC 3023 [RFC3023]. 847 MIME media type name: application 849 MIME subtype name: lostsync+xml 851 Mandatory parameters: none 853 Optional parameters: charset 855 Indicates the character encoding of enclosed XML. 857 Encoding considerations: Uses XML, which can employ 8-bit 858 characters, depending on the character encoding used. See RFC 859 3023 [RFC3023], Section 3.2. 861 Security considerations: This content type is designed to carry LoST 862 Syncronization protocol payloads. 864 Interoperability considerations: None 866 Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please 867 replace XXXX with the RFC number of this specification.] 869 Applications which use this media type: Emergency and Location-based 870 Systems 872 Additional information: 874 Magic Number: None 876 File Extension: .lostsyncxml 878 Macintosh file type code: 'TEXT' 880 Personal and email address for further information: Hannes 881 Tschofenig, Hannes.Tschofenig@nsn.com 883 Intended usage: LIMITED USE 885 Author: 887 This specification is a work item of the IETF ECRIT working group, 888 with mailing list address . 890 Change controller: 892 The IESG 894 8.2. LoST Sync Relax NG Schema Registration 896 URI: urn:ietf:params:xml:schema:lostsync1 898 Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig 899 (Hannes.Tschofenig@gmx.net). 901 Relax NG Schema: The Relax NG schema to be registered is contained 902 in Section 6. 904 8.3. LoST Synchronization Namespace Registration 906 URI: urn:ietf:params:xml:ns:lostsync1 908 Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig 909 (Hannes.Tschofenig@gmx.net). 911 XML: 913 BEGIN 914 915 917 918 919 921 LoST Synchronization Namespace 922 923 924

Namespace for LoST server synchronization

925

urn:ietf:params:xml:ns:lost1:sync

926

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

930 931 932 END 934 9. Acknowledgments 936 Robins George, Cullen Jennings, Karl Heinz Wolf, Richard Barnes, 937 Mayutan Arumaithurai and Andrew Newton provided helpful input. Jari 938 Urpalainen assisted with the Relax NG schema. We would also like to 939 thank our PROTO shepherd Roger Marshall for his help with the 940 document. 942 10. References 944 10.1. Normative References 946 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 947 Requirement Levels", BCP 14, RFC 2119, March 1997. 949 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 950 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 951 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 953 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 954 Leach, P., Luotonen, A., and L. Stewart, "HTTP 955 Authentication: Basic and Digest Access Authentication", 956 RFC 2617, June 1999. 958 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 960 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 961 Types", RFC 3023, January 2001. 963 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 964 Registration Procedures", BCP 13, RFC 4288, December 2005. 966 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 967 Tschofenig, "LoST: A Location-to-Service Translation 968 Protocol", RFC 5222, August 2008. 970 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 971 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 973 10.2. Informative References 975 [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and 976 Framework", RFC 5582, September 2009. 978 Authors' Addresses 980 Henning Schulzrinne 981 Columbia University 982 Department of Computer Science 983 450 Computer Science Building 984 New York, NY 10027 985 US 987 Phone: +1 212 939 7004 988 Email: hgs+ecrit@cs.columbia.edu 989 URI: http://www.cs.columbia.edu 991 Hannes Tschofenig 992 Nokia Siemens Networks 993 Linnoitustie 6 994 Espoo 02600 995 Finland 997 Phone: +358 (50) 4871445 998 Email: Hannes.Tschofenig@gmx.net 999 URI: http://www.tschofenig.priv.at