idnits 2.17.1 draft-ietf-ecrit-lost-sync-04.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 : ---------------------------------------------------------------------------- No issues found here. 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 (March 7, 2009) is 5528 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 (~~), 1 warning (==), 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: September 8, 2009 Nokia Siemens Networks 6 March 7, 2009 8 Synchronizing Location-to-Service Translation (LoST) Protocol based 9 Service Boundaries and Mapping Elements 10 draft-ietf-ecrit-lost-sync-04.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 September 8, 2009. 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 can be used for bulk exchange of 62 elements between two entities. As such, this document can 63 also be used without the LoST protocol. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3. Querying for Mappings with a / 70 Exchange . . . . . . . . . . . . . . . . 8 71 3.1. LoST Sync Client's Behavior . . . . . . . . . . . . . . . 8 72 3.2. LoST Sync Server's Behavior . . . . . . . . . . . . . . . 8 73 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 4. Pushing Mappings via and 75 . . . . . . . . . . . . . . . . . . . . 11 76 4.1. LoST Sync Client's Behavior . . . . . . . . . . . . . . . 11 77 4.2. LoST Sync Server's Behavior . . . . . . . . . . . . . . . 11 78 4.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 5. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 6. RelaxNG . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 83 8.1. Content-type registration for 84 'application/lostsync+xml' . . . . . . . . . . . . . . . . 19 85 8.2. LoST Sync Relax NG Schema Registration . . . . . . . . . . 20 86 8.3. LoST Synchronization Namespace Registration . . . . . . . 20 87 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 89 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 90 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 93 1. Introduction 95 The LoST (Location-to-Service Translation) protocol [RFC5222] maps 96 service identifiers and geodetic or civic location information to 97 service URIs. The main data structure, the element, used 98 for encapsulating information about service boundaries is defined in 99 the LoST protocol specification and circumscribes the region within 100 which all locations map to the same service Uniform Resource 101 Identifier (URI) or set of URIs for a given service. 103 This document enables a bulk exchange of elements between 104 two entities (the LoST Sync client and the LoST Sync server). 106 The LoST Sync mechanism can, for example, be used in the LoST 107 architecture, as specified in the [I-D.ietf-ecrit-mapping-arch]. 108 There, LoST servers act in different roles that cooperate to 109 provide an ubiquitous, globally scalable and resilient mapping 110 service. In the LoST mapping architecture, servers can peer, 111 i.e., have an on-going data exchange relationship. Peering 112 relationships are set up manually, based on local policies. A 113 server can peer with any number of other servers. Forest guides 114 peer with other forest guides; resolvers peer with forest guides 115 and other resolvers (in the same cluster); authoritative mapping 116 servers peer with forest guides and other authoritative servers, 117 either in the same cluster or above or below them in the tree. 118 Authoritative mapping servers push coverage regions "up" the tree, 119 i.e., from child nodes to parent nodes. The child informs the 120 parent of the geospatial or civic region that it covers for a 121 specific service. 123 This document defines two types of exchanges and those are best 124 described by the exchange between two nodes as shown in Figure 1 and 125 Figure 2. The protocol exchange always runs between a LoST Sync 126 client and a LoST Sync server even through the roles are reversed for 127 the two available exchanges and logically the two nodes might often 128 be peers rather than in a client-server relationship. Node A in the 129 example of Figure 1 and Figure 2 has mappings that Node B is going to 130 retrieve. 132 The and exchange allows a 133 LoST Sync client to request mappings from a LoST Sync server. 135 +---------+ +---------+ 136 | Node B | | Node A | 137 | acting | | acting | 138 | as | | as | 139 | LoST | | LoST | 140 | Sync | | Sync | 141 | Client | | Server | 142 +---------+ +---------+ 143 | | 144 | | 145 | | 146 | | 147 |----------------------------->| 148 | | 149 | | 150 |<-----------------------------| 151 | | 152 | | 153 | | 155 Figure 1: Querying for Mappings with a Message 157 The and exchange allows 158 a LoST Sync client to push mappings to LoST Sync server. The 159 assumption is being made that Node A and B have previously been 160 configured in a way that they push mappings in such a fashion and 161 that Node A maintains state about the mappings that have to be pushed 162 to Node B. No subscribe mechanism is defined in this document that 163 would allow Node B to tell Node A about what mappings it is 164 interested. 166 +---------+ +---------+ 167 | Node A | | Node B | 168 | acting | | acting | 169 | as | | as | 170 | LoST | | LoST | 171 | Sync | | Sync | 172 | Client | | Server | 173 +---------+ +---------+ 174 | | 175 | | 176 | | 177 | | 178 |----------------------------->| 179 | | 180 | | 181 |<-----------------------------| 182 | | 183 | | 184 | | 186 Figure 2: Pushing Mappings with a Message 188 2. Terminology 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 192 document are to be interpreted as described in RFC 2119 [RFC2119]. 194 This document reuses terminology introduced by the mapping 195 architecture document [I-D.ietf-ecrit-mapping-arch]. 197 Throughout this document we use the term LoST Sync client and LoST 198 Sync server to denote the protocol end points of the exchange. The 199 protocol is referred as LoST Sync within the text. 201 3. Querying for Mappings with a / 202 Exchange 204 3.1. LoST Sync Client's Behavior 206 A LoST Sync client has two ways to retrieve mapping elements from a 207 LoST Sync server node. 209 1. A mechanisms that is suitable when no mappings are available on 210 the client side is to submit an empty 211 message, as shown in Figure 3. The intent by the LoST Sync 212 client thereby is to retrieve all mappings from the LoST Sync 213 server. Note that the request does not propagate further to 214 other nodes. 216 2. A client that has already obtained mappings in previous exchanges 217 may want to check whether these mappings have been updated in the 218 meanwhile. The policy when to poll for updated mapping 219 information is outside the scope of this document. The 220 message with one or multiple child 221 element(s) allows to reduce the number of returned mappings to 222 those that have been updated and also to those that are missing. 224 In response to the message the client waits for 225 the message. In case of a successful response 226 the client stores the received mappings and determines which mappings 227 to replace. 229 3.2. LoST Sync Server's Behavior 231 When a LoST Sync server receives an empty 232 message then all locally available mappings MUST be returned 233 (assuming that the client has been properly authenticated and 234 authorized). 236 When a LoST Sync server receives a message with 237 one or multiple child element(s) then it MUST consult with 238 the local mapping database to determine whether any of the mappings 239 of the client is stale and whether there are mappings locally that 240 the client does not yet have. The former can be determined by 241 finding mappings corresponding to the 'source' and 'sourceID' 242 attribut where a mapping with a more recent lastUpdated date exists. 244 Processing a message MAY lead to a successful 245 response in the form of a or an 246 message. Only the , , , 247 errors, defined in [RFC5222], are utilized by this 248 specification. Neither the nor the messages 249 are reused by this message. 251 3.3. Examples 253 The first examples show the simplest message. 255 256 258 Figure 3: Example of empty message 260 An further example request is shown in Figure 4, the corresponding 261 response in Figure 5. In this example a LoST node requests a 262 specific mapping for source="authoritative.bar.example" and 263 sourceId="7e3f40b098c711dbb6060800200c9a66" that is fresher than 264 "2006-11-01T01:00:00Z". 266 267 268 269 272 273 274 276 Figure 4: Example Message 278 The response is shown in Figure 5. A more recent mapping was 279 available with the identification of 280 source="authoritative.bar.example" and 281 sourceId="7e3f40b098c711dbb6060800200c9a66". Only one mapping that 282 matched source="authoritative.foo.example" was found and returned. 284 285 290 294 295 Leonia Police Department 296 297 urn:service:sos.police 298 300 302 US 303 NJ 304 Leonia 305 07605 306 307 308 sip:police@leonianj2.example.org 309 911 310 312 316 317 New York City Police Department 318 319 urn:service:sos.police 320 321 322 323 324 37.775 -122.4194 325 37.555 -122.4194 326 37.555 -122.4264 327 37.775 -122.4264 328 37.775 -122.4194 329 330 331 332 333 sip:nypd@example.com 334 xmpp:nypd@example.com 335 911 336 338 340 Figure 5: Example Message 342 4. Pushing Mappings via and 344 4.1. LoST Sync Client's Behavior 346 When a LoST Sync node obtains new information that is of interest to 347 its peers, it MAY push the new mappings to its peers. Configuration 348 settings at both peers decide whether this functionality is used. 349 New mappings may arrive through non-LoST means, such as a manual 350 addition to the local mappings database, or through the interaction 351 with other LoST nodes. Mappings may also be deleted and this may 352 trigger events. 354 A sending node keeps track with which recipient it has exchanged 355 mapping elements with. As discussed in Section 5.1 of [RFC5222], 356 mapping elements are identified by the 'source', 'sourceID' and 357 'lastUpdated' attributes. A mapping is considered the same if these 358 three attributes match. It is RECOMMENDED not to push the same 359 information to the same peer more than once. 361 A LoST Sync client MUST send a request containing one 362 or more elements. 364 To delete a mapping, the content of the mapping is left empty. The 365 node can delete the mapping from its internal mapping database, but 366 has to remember which peers it has distributed this update to. The 367 'expires' attribute is required, but ignored. If an attempt is made 368 to delete a non-existent mapping, the request is silently ignored. 370 4.2. LoST Sync Server's Behavior 372 When a LoST Sync Server receives a message then 373 a newly received mapping M' MUST replace an existing mapping M if all 374 of the following conditions hold: 376 1. M'.source equals M.source 378 2. M'.sourceID' equals M.sourceID 380 3. M'.lastUpdated greater than M.lastUpdated 382 If the received mapping M' does not update any existing mapping M 383 then it MUST be added to the local cache as an independent mapping. 385 If a message with an empty element is 386 received then a corresponding mapping has to be determined based on 387 the 'source', 'sourceID' and 'lastUpdated' attributes. If a mapping 388 has been found then it MUST be deleted. If no mapping can be 389 identified then an response MUST be returned that contains 390 the child element. The element MAY carry a 391 element and MUST contain the element(s) that 392 caused the error. 394 The response to a request is a 395 message. With this specification, a 396 successful response message returns no additional elements, whereas 397 an response is returned in the response message, if the 398 request failed. Only the , , 399 or errors defined in Section 13.1 of [RFC5222], are 400 used. The and messages are not used for this 401 query/response. 403 If the set of nodes that are synchronizing their data does not form a 404 tree, it is possible that the same information arrives through 405 several other nodes. This is unavoidable, but generally only imposes 406 a modest overhead. (It would be possible to create a spanning tree 407 in the same fashion as IP multicast, but the complexity does not seem 408 warranted, given the relatively low volume of data.) 410 4.3. Example 412 An example is shown in Figure 6. Image a LoST node that obtained two 413 new mappings identified as follows: 415 o source="authoritative.example" 416 sourceId="7e3f40b098c711dbb6060800200c9a66" lastUpdated="2008-11- 417 26T01:00:00Z" 419 o source="authoritative.example" 420 sourceId="7e3f40b098c711dbb606011111111111" lastUpdated="2008-11- 421 01T01:00:00Z" 423 These two mappings have to be added to the peer's mapping database. 425 Additionally, the following mapping has to be deleted: 427 o source="nj.us.example" sourceId="123" lastUpdated="2008-11- 428 01T01:00:00Z" 430 431 436 440 441 Leonia Police Department 442 443 urn:service:sos.police 444 446 448 US 449 NJ 450 Leonia 451 07605 452 453 454 sip:police@leonianj.example.org 455 911 456 458 462 463 New York City Police Department 464 465 urn:service:sos.police 466 467 468 469 470 37.775 -122.4194 471 37.555 -122.4194 472 37.555 -122.4264 473 37.775 -122.4264 474 37.775 -122.4194 475 476 477 478 479 sip:nypd@example.com 480 xmpp:nypd@example.com 481 911 482 484 489 491 Figure 6: Example Message 493 In response, the peer performs the necessary operation and updates 494 its mapping database. In particular, it will check whether the other 495 peer is authorized to perform the update and whether the elements and 496 attributes contain values that it understands. In our example, a 497 positive response is returned as shown in Figure 7. 499 500 502 Figure 7: Example 504 In case that a mapping could not be deleted as requested the 505 following error response might be returned instead. 507 508 512 516 521 522 524 Figure 8: Example Message 526 5. Transport 528 LoST Sync needs an underlying protocol transport mechanism to carry 529 requests and responses. This document defines the use of LoST Sync 530 over HTTP and LoST over HTTP-over-TLS. Client and server developers 531 are reminded that full support of RFC 2616 HTTP facilities is 532 expected. If LoST Sync clients or servers re-implement HTTP, rather 533 than using available servers or client code as a base, careful 534 attention must be paid to full interoperability. Other transport 535 mechanisms are left to future documents. The available transport 536 mechanisms are determined through the use of the LoST U-NAPTR 537 application. In protocols that support content type indication, LoST 538 Sync uses the media type application/lostsync+xml. 540 When using HTTP [RFC2616] and HTTP-over-TLS [RFC2818], LoST Sync 541 messages use the HTTP POST method. The HTTP request MUST use the 542 Cache-Control response directive "no-cache" to HTTP-level caching 543 even by caches that have been configured to return stale responses to 544 client requests. 546 All LoST Sync responses, including those indicating a LoST warning or 547 error, are carried in 2xx responses, typically 200 (OK). Other 2xx 548 responses, in particular 203 (Non-authoritative information) may be 549 returned by HTTP caches that disregard the caching instructions. 3xx, 550 4xx and 5xx HTTP response codes indicates that the HTTP request 551 itself failed or was redirected; these responses do not contain any 552 LoST Sync XML elements. 554 The HTTP URL is derived from the LoST Sync server name via U-NAPTR 555 application. 557 6. RelaxNG 559 561 566 568 570 Location-to-Service Translation (LoST) 571 Synchronization Protocol 573 574 575 576 577 578 579 581 582 583 584 585 587 588 589 591 592 593 594 595 597 598 599 600 601 602 604 605 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 626 627 628 629 630 631 632 633 635 637 638 639 640 641 642 643 644 645 647 7. Security Considerations 649 The LoST security considerations are discussed in [RFC5222]. The 650 operations described in this document involve mutually-trusting LoST 651 nodes. These nodes need to authenticate each other, using mechanisms 652 such as HTTP Digest [RFC2617], HTTP Basic [RFC2617] over TLS 653 [RFC5246] or TLS client and server certificates. 655 8. IANA Considerations 657 8.1. Content-type registration for 'application/lostsync+xml' 659 This specification requests the registration of a new MIME type 660 according to the procedures of RFC 4288 [RFC4288] and guidelines in 661 RFC 3023 [RFC3023]. 663 MIME media type name: application 665 MIME subtype name: lostsync+xml 667 Mandatory parameters: none 669 Optional parameters: charset 671 Indicates the character encoding of enclosed XML. 673 Encoding considerations: Uses XML, which can employ 8-bit 674 characters, depending on the character encoding used. See RFC 675 3023 [RFC3023], Section 3.2. 677 Security considerations: This content type is designed to carry LoST 678 Syncronization protocol payloads. 680 Interoperability considerations: None 682 Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please 683 replace XXXX with the RFC number of this specification.] 685 Applications which use this media type: Emergency and Location-based 686 Systems 688 Additional information: 690 Magic Number: None 692 File Extension: .lostsyncxml 694 Macintosh file type code: 'TEXT' 696 Personal and email address for further information: Hannes 697 Tschofenig, Hannes.Tschofenig@nsn.com 699 Intended usage: LIMITED USE 701 Author: 703 This specification is a work item of the IETF ECRIT working group, 704 with mailing list address . 706 Change controller: 708 The IESG 710 8.2. LoST Sync Relax NG Schema Registration 712 URI: urn:ietf:params:xml:schema:lostsync1 714 Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig 715 (Hannes.Tschofenig@nsn.com). 717 Relax NG Schema: The Relax NG schema to be registered is contained 718 in Section 6. Its first line is 720 default namespace = "urn:ietf:params:xml:ns:lost1" 722 and its last line is 724 } 726 8.3. LoST Synchronization Namespace Registration 727 URI: urn:ietf:params:xml:ns:lostsync1 729 Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig 730 (Hannes.Tschofenig@nsn.com). 732 XML: 734 BEGIN 735 736 738 739 740 742 LoST Synchronization Namespace 743 744 745

Namespace for LoST server synchronization

746

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

747

See RFCXXXX 748 [NOTE TO IANA/RFC-EDITOR: 749 Please replace XXXX with the RFC number of this 750 specification.].

751 752 753 END 755 9. Acknowledgments 757 Robins George, Cullen Jennings, Karl Heinz Wolf, Richard Barnes and 758 Andrew Newton provided helpful input. Jari Urpalainen assisted with 759 the Relax NG schema. We would also like to thank our PROTO shepherd 760 Roger Marshall for his help with the document. 762 10. References 764 10.1. Normative References 766 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 767 Requirement Levels", BCP 14, RFC 2119, March 1997. 769 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 770 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 771 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 773 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 774 Leach, P., Luotonen, A., and L. Stewart, "HTTP 775 Authentication: Basic and Digest Access Authentication", 776 RFC 2617, June 1999. 778 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 780 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 781 Types", RFC 3023, January 2001. 783 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 784 Registration Procedures", BCP 13, RFC 4288, December 2005. 786 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 787 Tschofenig, "LoST: A Location-to-Service Translation 788 Protocol", RFC 5222, August 2008. 790 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 791 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 793 10.2. Informative References 795 [I-D.ietf-ecrit-mapping-arch] 796 Schulzrinne, H., "Location-to-URL Mapping Architecture and 797 Framework", draft-ietf-ecrit-mapping-arch-04 (work in 798 progress), March 2009. 800 Authors' Addresses 802 Henning Schulzrinne 803 Columbia University 804 Department of Computer Science 805 450 Computer Science Building 806 New York, NY 10027 807 US 809 Phone: +1 212 939 7004 810 Email: hgs+ecrit@cs.columbia.edu 811 URI: http://www.cs.columbia.edu 813 Hannes Tschofenig 814 Nokia Siemens Networks 815 Linnoitustie 6 816 Espoo 02600 817 Finland 819 Phone: +358 (50) 4871445 820 Email: Hannes.Tschofenig@gmx.net 821 URI: http://www.tschofenig.priv.at