idnits 2.17.1 draft-forte-lost-extensions-08.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 : ---------------------------------------------------------------------------- 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 date (September 7, 2011) is 4577 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Forte 3 Internet-Draft AT&T 4 Intended status: Experimental H. Schulzrinne 5 Expires: March 10, 2012 Columbia University 6 September 7, 2011 8 Location-to-Service Translation (LoST) Protocol Extensions 9 draft-forte-lost-extensions-08.txt 11 Abstract 13 An important class of location-based services answer the question 14 "What instances of this service are closest to me?" Examples include 15 finding restaurants, gas stations, stores, automated teller machines, 16 wireless access points (hot spots) or parking spaces. Currently, the 17 Location-to-Service Translation (LoST) protocol only supports mapping 18 locations to a single service based on service regions. This 19 document describes an extension that allows queries of the type "N 20 nearest", "within distance X" and "served by". 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 10, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 58 3. Service Regions . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. New Query Types: "N nearest", "within 60 distance X" and "served by" . . . . . . . . . . . . . . . . . 5 61 5. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . 5 62 5.1. New Use of Shapes in Queries . . . . . . . . . . . . . . . 5 63 5.2. Queries Based on Service Regions . . . . . . . . . . . . . 8 64 5.3. Difference Between "within distance X" and "served by" 65 Queries . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 5.4. Limiting the Number of Returned Service URIs . . . . . . . 11 67 5.5. The Element in Responses . . . . . . . . 13 68 6. Emergency Services . . . . . . . . . . . . . . . . . . . . . . 16 69 7. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 17 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 72 9.1. LoST Extensions Relax NG Schema Registration . . . . . . . 19 73 9.2. LoST Extensions Namespace Registration . . . . . . . . . . 20 74 10. Non-Normative RELAX NG Schema in XML Syntax . . . . . . . . . 20 75 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 76 12. Normative References . . . . . . . . . . . . . . . . . . . . . 23 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 79 1. Introduction 81 The Location-to-Service Translation (LoST) protocol [RFC5222] maps 82 service identifiers (URNs) and civic or geospatial information to 83 service URIs, based on service regions. While motivated by mapping 84 locations to the public safety answering point (PSAP) serving that 85 location, the protocol has been designed to generalize to other 86 location mapping services. 88 However, the current LoST query model assumes that each service URI 89 has a service region and that service regions do not overlap. This 90 fits the emergency services model, where the service region of a PSAP 91 is given by jurisdictional boundaries, but does not work as well for 92 other services that do not have clearly defined boundaries. For 93 example, any given location is likely served by a number of different 94 restaurants, depending on how far the prospective customer is willing 95 to travel. 97 We extend LoST with three additional query types, 98 giving the protocol the ability to find the N nearest instances of a 99 particular service, all services within a given distance and all 100 services whose service region includes the client's current location. 102 2. Requirements Notation 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 3. Service Regions 110 Generally speaking, service regions apply only to a subset of 111 services. 113 In Section 1 of [RFC5222] a service region is defined as follows: 115 "To minimize round trips and to provide robustness against network 116 failures, LoST supports caching of individual mappings and indicates 117 the region for which the same answer would be returned ("service 118 region")." 120 and in Section 5.5 of [RFC5222]: 122 "A response MAY indicate the region for which the service URL 123 returned would be the same as in the actual query, the so-called 124 service region." 125 For emergency services, service region and service area, as defined 126 in [RFC5222], represent the same geographical area. This is due to 127 the fact that each PSAP serves its own area without overlapping with 128 the service area of any other PSAP. For as long as the client is 129 located in the service area of a PSAP, the same PSAP is returned by 130 the LoST server that is, the service region does not change. A 131 service region is the service area of a PSAP. 133 For non-emergency services different points of service may have 134 different overlapping service areas. This means that one service 135 region will probably include a large number of service areas. Since 136 for each query we can get a large number of service URIs, a service 137 region as per definition above would be the region within which a 138 user would get the same set of service URIs. If one or more of the 139 URIs in the set changes, the set of URIs changes that is, the service 140 region changes. Therefore, for non-emergency services a service 141 region as defined in [RFC5222] would change very frequently, making 142 the use of service regions as described in [RFC5222] not that useful. 144 Generally speaking, we can divide location-based services into two 145 main categories. 147 Services based on: 149 o how far they are from the user (e.g., ATM machines, takeout) 151 o whether or not their service area includes the client's current 152 location (e.g., pizza delivery, NG9-1-1) 154 For services included in the first category service areas and 155 therefore service regions are not relevant while they are important 156 for services included in the second category. This distinction 157 becomes obvious if we consider the difference between takeout (first 158 category) and delivery (second category), for example. In the case 159 of takeout, the user wants to go to a particular restaurant and buy 160 dinner regardless of his location falling in the restaurant service 161 area or not. For delivery, the user cares about the restaurant 162 service area as the restaurant will deliver food to him only if the 163 user's location falls within the restaurant service area. 165 There is a clear distinction between services that require service 166 areas and services that do not. The LoST extensions defined in this 167 document take this into account by using the service classification 168 mentioned above. 170 4. New Query Types: "N nearest", "within distance X" and 171 "served by" 173 We introduce three new types of queries that is, "N 174 nearest", "within distance X" and "served by". The first query 175 returns the N points of interest closest to the client's physical 176 location, the second query discovers all those points of interest 177 located within a given distance from the client's physical location, 178 the third query returns all those points of interest whose service 179 area includes the client's current location. 181 5. LoST Extensions 183 For queries "within distance X", the LoST client needs to specify to 184 the server the range within which instances of a particular service 185 should be searched. In order to do this, we make use of various 186 shapes [RFC5491] in LoST queries. 188 For queries "served by", the LoST client needs to let the server know 189 that it MUST return only those services whose service area includes 190 the client's current location. In order to do this we introduce the 191 element in queries. Service region boundaries 192 MAY be returned in a LoST as described in 193 [RFC5222]. 195 For queries "N nearest", the LoST client needs to let the server know 196 N, that is, the maximum number of service URIs to be returned in a 197 response. In order to specify this, we introduce the element 198 in queries. 200 Also, we introduce a new element in LoST responses, namely 201 . This new element is used by the server to 202 indicate to the client the physical location of points of interest. 203 In doing so, the client can compute the distance and other metrics 204 between its current location and the points of interest. 206 The new elements , and are defined 207 in the "lost-ext" namespace. This new namespace is defined in 208 Section 6. 210 5.1. New Use of Shapes in Queries 212 In [RFC5491] different shapes are defined in order to represent a 213 point and an area of uncertainty within which the user might be 214 situated. While this remains true for "served by" queries, for 215 "within distance X" queries such shapes can be interpreted as the 216 area within which we want to find a service. In particular, I want 217 to search for points of service within that area because my location 218 is within that area with a certain probability. We can think of the 219 area of uncertainty in a shape as the probability that a user might 220 be within that area and so we want to look for services within that 221 area. All we are doing with a "within distance X" query is to 222 manually set the uncertainty level in user location to a value of X. 224 For example, Figure 1 shows a "within distance X" 225 geodetic query using the circular shape. With the query shown in 226 Figure 1, we are asking the LoST server to send us a list of service 227 URIs for pizza places within 200 meters from our approximate position 228 specified in . 230 Aside from the circular shape, other shapes are also useful. In 231 particular, there are situations in which it is useful to query for 232 services in a certain direction of movement rather than in an exact 233 physical location. For example, if a user is driving North from New 234 York City to Boston, it would be useful for this user to be able to 235 query for services North of where he currently is that is, not at his 236 current physical location nor at his final destination. 238 In order to do this, we use shapes such as an ellipse. The ellipse 239 has a major and a minor dimension thus allowing for defining a 240 "privileged" direction by having the major dimension in the direction 241 of movement. In the present context the circular shape allows a 242 device to search for services in any direction surrounding its 243 physical location while shapes such as the ellipse allow the device 244 to search for services in a more specific direction. Figure 2 shows 245 a "within distance X" geodetic query using the 246 elliptical shape. The ellipse shape is defined in Section 5.2.4 of 247 [RFC5491]. 249 250 257 false 258 259 260 37.775 -122.422 261 262 200 263 264 265 266 urn:service:food.pizza 267 269 Figure 1: A 'within distance X' geodetic query using 270 the circular shape (a hypothetical service URN of 271 "urn:service:food.pizza" is used) 272 273 280 false 281 282 283 42.5463 -73.2512 284 285 1235 286 287 288 660 289 290 291 41.2 292 293 294 295 urn:service:food.pizza 296 298 Figure 2: A 'within distance X' geodetic query using 299 the elliptical shape (a hypothetical service URN of 300 "urn:service:food.pizza" is used) 302 5.2. Queries Based on Service Regions 304 As mentioned in Section 1, we can divide location-based services into 305 two main categories. 307 Services based on: 309 o how far they are from the user 311 o whether or not their service area includes the user's current 312 location 314 A "within distance X" query addresses services included in the first 315 category while a "served by" query addresses services included in the 316 second category. 318 __________________________ 319 \ ***** \ 320 ,===============***====, *** \ 321 / ** \ / ** \ 322 / POI 1 ** \ / ** \ 323 / o ** X ** \ 324 / ** / \ USER ** \ 325 / ** / \ 0 ** \ 326 / ** / \ POI 3 ** \ 327 / ** / \ o ** \ 328 / ,--------**-/---------\----------**--, \ 329 `=====================** \________**___|___________\ 330 | ** ** | 331 | o *** *** | 332 | POI 2 ***** | 333 `------------------------------------' 335 Figure 3: LoST client location (circle) overlapping three service 336 areas of three different points of interest (POI 1, POI 2, POI 3) 338 When querying LoST regarding a specific service, we need to specify 339 if such service belongs to either the first or the second category. 340 This is necessary since depending on the category the service belongs 341 to, the LoST server has to follow a different metric in selecting the 342 results to include in the response. 344 For example, Figure 3 shows three points of interest with their 345 service areas. The user location that is, the LoST client location, 346 is represented by a circular shape (e.g., GPS). If POI 1, POI 2 and 347 POI 3 belong to the first category of service ("within distance X" 348 query), their service area is irrelevant, what it matters is how far 349 they are from the user. For such services the shape representing the 350 user location represents the distance within which the user wants to 351 search for services (see Section 5.1). In the example shown in 352 Figure 3 the LoST server returns only POI 3 as POI 3 is the only 353 point of interest falling within the user location represented by the 354 circle that is, the area within which the user wants to search for 355 services. On the other hand, if the three points of service belong 356 to the second category ("served by" query) then what it matters is 357 their service area. In this second scenario, since the circle 358 representing the user location overlaps with all three service areas, 359 it means that all three POIs can serve the location of the user and 360 the LoST server has to return all three POIs that is, POI 1, POI 2 361 and POI 3. 363 In order for the client to specify which of the two categories the 364 service belongs to, we introduce the element. This new 365 element is of type boolean. When its value is false, the LoST server 366 MUST perform a search based on the distance between the user and the 367 points of service ("within distance X" query). When its value is 368 either true or the element is missing (see Section 5.3), it 369 means that the requested service belongs to the second category and a 370 search based on service areas MUST be performed by the LoST server 371 ("served by" query). When present, the element MUST be 372 conveyed inside the element defined in [RFC5222]. 374 For a search based on service regions the LoST server MUST return 375 only those services whose service area includes the client's current 376 location. Service region boundaries MAY be returned in a LoST 377 as described in [RFC5222]. 379 380 386 true 387 388 389 37.775 -122.422 390 391 200 392 393 394 395 urn:service:food.pizza 396 398 Figure 4 A 'served by' geodetic query with the new 399 element (a hypothetical service URN of 400 "urn:service:food.pizza" is used) 402 5.3. Difference Between "within distance X" and "served by" Queries 404 Figures 1 and 4 show an example of a "within distance X" query and a 405 "served by" query, respectively. The two types of queries although 406 very similar have three important differences. 408 o A "served by" query can support all the shapes a "within distance 409 X" query can support plus the point shape. The point shape does 410 not make sense for a "within distance X" query and SHOULD NOT be 411 used for such query as it would be equivalent to a within-zero- 412 meters search. 414 o In a "within distance X" query we manually set to X the 415 uncertainty level in user location and we search for services 416 within such area. In all other types of queries including a 417 "served by" query, the level of uncertainty in user location 418 cannot be changed by the user and search based on service areas is 419 performed. 421 o In a "within distance X" query the value of the element 422 MUST be set to false. A "served by" query SHALL have the value of 423 the element set to true. If the element is not 424 present, its value MUST be assumed to be equal to true and the 425 query will be a "served by" query. This behavior is consistent 426 with [RFC5222]. 428 5.4. Limiting the Number of Returned Service URIs 430 Limiting the number of results is helpful, particularly for mobile 431 devices with limited bandwidth. For "N nearest" queries, the client 432 needs to be able to tell the server to return no more than N service 433 URIs. In order to specify such limit we introduce a new element, 434 namely . This new element is OPTIONAL but when present, it 435 MUST be conveyed inside the element defined in 436 [RFC5222]. 438 Figures 5, 6 and 7 show a geodetic query where the 439 client asks the server to return no more than 20 service URIs. In 440 particular, Figure 5 shows a 'N nearest' query, Figure 6 shows a 441 query which is a combination of 'N nearest' and 'within distance X' 442 while Figure 7 shows a query which is a combination of 'N nearest' 443 and 'served by'. When receiving such queries, the LoST server will 444 return a list of no more than 20 points of interest. 446 If the available points of interest are more than N, the server has 447 to identify, among those, the N points of interest closest to the 448 client's physical location and MUST return those in the response. 450 When the element is not present in a query then 451 all available points of interest for the requested type of service 452 SHOULD be returned by the LoST server. This behavior is consistent 453 with [RFC5222]. 455 456 461 20 462 463 464 40.7128 -74.0092 465 466 467 urn:service:food.pizza 468 470 Figure 5: A 'N nearest' geodetic query with the new 471 element (a hypothetical service URN of 472 "urn:service:food.pizza" is used) 474 475 482 false 483 20 484 485 486 37.775 -122.422 487 488 200 489 490 491 492 urn:service:food.pizza 493 495 Figure 6: A geodetic query with the new and 496 elements. This query is a combination of 'N nearest' and 497 'within distance X' queries (a hypothetical service URN of 498 "urn:service:food.pizza" is used) 499 500 507 true 508 20 509 510 511 37.775 -122.422 512 513 100 514 515 516 517 urn:service:food.pizza 518 520 Figure 7: A geodetic query with the new and 521 elements. This query is a combination of 'N nearest' and 522 'served by' queries (a hypothetical service URN of 523 "urn:service:food.pizza" is used) 525 5.5. The Element in Responses 527 It is important for the LoST client to know the location of a point 528 of interest so that distance, route and other metrics can be 529 computed. We introduce a new element, namely . The 530 element contains the location of a point of 531 service. When it is used, it MUST be contained in a 532 element. In responses such as [RFC5222], a 533 list of service URIs, each with its own element, 534 SHOULD be returned. The order of service URIs in the list is not 535 relevant. 537 The element has one single attribute, 'profile', in 538 order to specify the profile used. Both civic and geodetic profiles 539 can be used. The geodetic profiles SHOULD be used in order to 540 compute distance, route and other metrics as at some point computing 541 such metrics would require geocoding of the civic address in geodetic 542 coordinates. Because of this, the position specified in 543 with a geodetic profile SHOULD be represented by 544 using the element. The element is described in 545 Section 12.2 of [RFC5222] and in Section 5.2.1 of [RFC5491]. Figure 546 8 shows a answer containing two location-to- 547 service-URI mappings. 549 [NOTE: The element cannot be extended for this purpose 550 as it is defined outside of the element. In particular, in 551 a response the element is always one, while the number 552 of service URIs is typically more than one.] 554 There are situations, however, in which it is helpful to include a 555 civic address together with the geodetic coordinates of a point of 556 service. Usually, databases already contain the civic address of 557 points of interest and for devices with limited capabilities it is 558 not always possible to perform decoding of geocoordinates in order to 559 determine the civic address. Because of this, including also the 560 civic address in a response can be useful. In order to do this, we 561 use a civic profile for the element and specify the 562 POI civic address in a element contained in the 563 element. The basic civic location profile is 564 defined in Section 12.3 of [RFC5222]. 566 As per [RFC5139] it is RECOMMENDED to use multiple 567 elements when multiple forms of service location are available and 568 also, it is RECOMMENDED to provide a geodetic form whenever possible. 569 When multiple elements are present for one POI, all 570 of them MUST be contained in the same element that is, the 571 element for that POI. Figure 8 shows a 572 answer with both geodetic and civic locations. 574 575 579 584 585 Che bella pizza e all' anima da' pizza da Toto' 586 587 urn:service:food.pizza 588 sip:chebella@example.com 589 xmpp:chebella@example.com 590 2129397040 591 592 593 33.665 -112.432 594 595 596 597 599 US 600 New York 601 New York 602 Broadway 603 321 604 10027 605 606 607 608 613 614 King Mario's Pizza 615 616 urn:service:food.pizza 617 sip:marios@example.com 618 xmpp:marios@example.com 619 2129397157 620 621 622 33.683 -112.412 623 624 625 626 628 US 629 New York 630 New York 631 Amsterdam Avenue 632 123 633 10027 634 635 636 637 638 639 640 641 642 644 Figure 8: A answer 646 6. Emergency Services 648 The LoST extensions defined in this document SHOULD NOT be used when 649 routing emergency sessions as there may be LoST servers that do not 650 support these extensions. 652 Figure 9 shows a query for emergency services as 653 defined in [RFC5222]. As we can see, in such query both the 654 element and the element are missing. According to the LoST 655 extensions defined in this document, when the element is 656 missing its value defaults to true and the query is a "served by" 657 query (see Section 5.3). When the element is missing it 658 means that no limit is specified that is, the LoST server can return 659 any number of results (see Section 5.4). This behavior is consistent 660 with [RFC5222] so that PSAPs are selected according to their service 661 area and when user location overlaps multiple service areas, the LoST 662 server MAY return multiple PSAPs. 664 The LoST extensions defined in this document are consistent with the 665 behavior defined in [RFC5222] and as such they do not modify LoST 666 behavior for emergency services. 668 669 675 676 677 37.775 -122.422 678 679 680 urn:service:sos.police 682 684 Figure 9: A geodetic query for emergency services 686 Unlike emergency services, where information such as service 687 boundaries of PSAPs and locations of fire stations does not change 688 very often, if at all, non-emergency services have information that 689 may become inaccurate quickly. This is something implementers should 690 take into account when designing applications for non-emergency 691 location-based services. 693 7. Relax NG Schema 695 This section provides the Relax NG schema of LoST extensions in the 696 compact form. The verbose form is included in Section 9. 698 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 699 default namespace ns1 = "urn:ietf:params:xml:ns:lost-ext" 701 ## 702 ## Extensions to the Location-to-Service Translation (LoST) 703 ## Protocol 705 ## 706 ## LoST Extensions define three new elements: limit, region and 707 ## serviceLocation. 708 ## 709 start = 710 limit 711 | region 712 | serviceLocation 714 ## 715 ## A limit to the number of returned results. 716 ## 717 div { 718 limit= 719 element limit { 720 xsd:positiveInteger 721 } 722 } 724 ## 725 ## A boolean variable to request a search 726 ## based on either service areas or distance. 727 ## 728 ## NOTE: The W3C XML Schema has two different 729 ## lexical representations for boolean: 731 ## '1' or 'true' vs. '0' or 'false'. 732 ## 733 div { 734 region= 735 element region { 736 xsd:boolean 737 } 738 } 740 ## 741 ## Location Information 742 ## 743 div { 744 locationInformation = 745 extensionPoint+, 746 attribute profile { xsd:NMTOKEN }? 747 } 749 ## 750 ## Location Information about the returned point 751 ## of service. 752 ## 753 div { 754 serviceLocation= 755 element serviceLocation { locationInformation }+ 756 } 758 ## 759 ## Patterns for inclusion of elements from schemas in 760 ## other namespaces. 761 ## 762 div { 764 ## 765 ## Any element not in the LoST Extensions 766 ## namespace. 767 ## 768 notLostExt = element * - (ns1:* | ns1:*) { anyElement } 770 ## 771 ## A wildcard pattern for including any element 772 ## from any other namespace. 773 ## 774 anyElement = 775 (element * { anyElement } 776 | attribute * { text } 777 | text)* 779 ## 780 ## A point where future extensions 781 ## (elements from other namespaces) 782 ## can be added. 783 ## 784 extensionPoint = notLostExt* 785 } 787 8. Security Considerations 789 The overall LoST architecture and framework are defined in [RFC5582]. 790 All LoST queries for both emergency and non-emergency services, if 791 not cached, are sent from the LoST client to a first-hop LoST server. 792 In [RFC5582] terminology, a LoST client is called Seeker and the 793 first-hop LoST server is called Resolver (for more rigorous 794 definitions please refer to [RFC5582]). The Resolver will contact 795 other LoST servers and eventually an authoritative LoST server will 796 be found. A response will then be sent back to the Seeker. 798 When considering both emergency and non-emergency services there is 799 the possibility of the Resolver getting overloaded by non-emergency 800 services queries, thus being unable to process emergency-service 801 queries. Such a situation can be addressed in more than one way. 803 The obvious way to address this problem is to properly dimension the 804 LoST servers so to take into account also traffic for non-emergency 805 services. Given that the LoST server is an enhanced HTTP server, 806 properly dimensioning a deployment of LoST servers should not be very 807 difficult to accomplish. 809 The same security considerations as in [RFC5222] apply. In 810 particular, in order to maintain integrity and confidentiality of 811 requests and responses, Transport Layer Security (TLS) MUST be 812 implemented and SHOULD be used as described in Sections 1, 14 and 18 813 of [RFC5222]. 815 9. IANA Considerations 817 9.1. LoST Extensions Relax NG Schema Registration 819 URI: urn:ietf:params:xml:schema:lost-ext 821 Registrant Contact: Andrea G. Forte, forte@att.com; Henning 822 Schulzrinne, hgs@cs.columbia.edu 823 Relax NG Schema: The Relax NG schema to be registered is contained in 824 Section 6. Its first line is 826 default namespace ns1 = "urn:ietf:params:xml:ns:lost-ext" 828 and its last line is 830 } 832 9.2. LoST Extensions Namespace Registration 834 URI: urn:ietf:params:xml:ns:lost-ext 836 Registrant Contact: Andrea G. Forte, forte@att.com; Henning 837 Schulzrinne, hgs@cs.columbia.edu 839 XML: 841 BEGIN 842 843 845 846 847 849 LoST Extensions Namespace 850 851 852

Namespace for LoST Extensions

853

urn:ietf:params:xml:ns:lost-ext

854

See 855 RFCXXXX.

856 857 858 861 END 863 10. Non-Normative RELAX NG Schema in XML Syntax 865 866 871 872 873 Extensions to the Location-to-Service Translation (LoST) 874 Protocol. 875 LoST Extensions define three new elements: limit, region and 876 serviceLocation. 877 878 879 880 881 882 883 885
886 887 A limit to the number of returned results. 888 890 891 892 893 894 895
897
898 899 A boolean variable to request a search 900 based on either service areas or distance. 901 903 904 905 906 907 908
910
911 912 Location Information 913 915 916 917 918 919 920 921 922 923 924 925
927
928 929 Location Information about the returned point of service. 930 932 933 934 935 936 937
939
940 941 Patterns for inclusion of elements from schemas in 942 other namespaces. 943 945 946 947 Any element not in the LoST Extensions namespace. 948 949 950 951 952 953 954 955 956 957 958 960 961 962 A wildcard pattern for including any element 963 from any other namespace. 965 966 967 968 969 970 971 972 973 974 975 976 977 978 980 981 982 A point where future extensions 983 (elements from other namespaces) 984 can be added. 985 986 987 988 989 990
992
994 11. Acknowledgments 996 We would like to thank Shida Schubert for reviewing an early version 997 of the LoST Extensions document. Also, we would like to thank some 998 of the members of the ECRIT working group. In particular, we thank 999 Martin Thomson, Richard L. Barnes and Robert Sparks for the overall 1000 feedback and for their comments on how non-emergency services may 1001 affect the provisioning of emergency services. 1003 12. Normative References 1005 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1006 Requirement Levels", BCP 14, RFC 2119, March 1997. 1008 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 1009 Tschofenig, "LoST: A Location-to-Service Translation 1010 Protocol", RFC 5222, August 2008. 1012 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 1013 Format for Presence Information Data Format Location 1014 Object (PIDF-LO)", RFC 5139, February 2008. 1016 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 1017 Presence Information Data Format Location Object (PIDF-LO) 1018 Usage Clarification, Considerations, and Recommendations", 1019 RFC 5491, March 2009. 1021 [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and 1022 Framework", RFC 5582, September 2009. 1024 Authors' Addresses 1026 Andrea G. Forte 1027 AT&T 1028 Security Research Center 1029 33 Thomas Street 1030 New York, NY 10007 1031 USA 1033 Email: forte@att.com 1035 Henning Schulzrinne 1036 Columbia University 1037 Department of Computer Science 1038 1214 Amsterdam Avenue, MC 0401 1039 New York, NY 10027 1040 USA 1042 Email: hgs@cs.columbia.edu