idnits 2.17.1 draft-forte-lost-extensions-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 13, 2010) is 4946 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: 2 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 H. Schulzrinne 4 Intended status: Experimental Columbia University 5 Expires: March 17, 2011 September 13, 2010 7 Location-to-Service Translation Protocol (LoST) Extensions 8 draft-forte-lost-extensions-02.txt 10 Abstract 12 An important class of location-based services answer the question 13 "What instances of this service are closest to me?" Examples include 14 finding restaurants, gas stations, stores, automated teller machines, 15 wireless access points (hot spots) or parking spaces. Currently, the 16 Location-to-Service Translation (LoST) protocol only supports mapping 17 locations to a single service based on service regions. This 18 document describes an extension that allows queries of the type "N 19 nearest", "within distance X" and "served by". 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on March 17, 2011. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 63 3. Service Regions . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. New Query Types: "N nearest", "within distance X" and 65 "served by" . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . 5 67 5.1. New Use of Shapes in Queries . . . . . . . . . . . . . . . 5 68 5.2. Queries Based on Service Regions . . . . . . . . . . . . . 6 69 5.3. Difference Between "within distance X" and "served by" 70 Queries . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5.4. Limiting the Number of Returned Service URIs . . . . . . . 8 72 5.5. The Element in Responses . . . . . . . . 10 73 6. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 12 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 8.1. LoST Extensions Relax NG Schema Registration . . . . . . . 14 77 8.2. LoST Extensions Namespace Registration . . . . . . . . . . 15 78 9. Non-Normative RELAX NG Schema in XML Syntax . . . . . . . . . 15 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 82 1. Introduction 84 The Location-to-Service Translation (LoST) protocol [RFC5222] maps 85 service identifiers (URNs) and civic or geospatial information to 86 service URIs, based on service regions. While motivated by mapping 87 locations to the public safety answering point (PSAP) serving that 88 location, the protocol has been designed to generalize to other 89 location mapping services. 91 However, the current LoST query model assumes that each service URI 92 has a service region and that service regions do not overlap. This 93 fits the emergency services model, where the service region of a PSAP 94 is given by jurisdictional boundaries, but does not work as well for 95 other services that do not have clearly defined boundaries. For 96 example, any given location is likely served by a number of different 97 restaurants, depending on how far the prospective customer is willing 98 to walk or drive. 100 We extend LoST with three additional queries, giving the protocol the 101 ability to find the N nearest instances of a particular service, all 102 services within a given radius and all services whose service region 103 includes the client's current location. 105 The LoST extensions defined in this document do not apply to 106 emergency services. 108 2. Requirements Notation 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 3. Service Regions 116 Generally speaking, service regions apply only to a subset of 117 services. 119 In Section 1 of [RFC5222] a service region is defined as follows: 121 "To minimize round trips and to provide robustness against network 122 failures, LoST supports caching of individual mappings and indicates 123 the region for which the same answer would be returned ("service 124 region")." 126 and in Section 5.5 of [RFC5222]: 128 "A response MAY indicate the region for which the service URL 129 returned would be the same as in the actual query, the so-called 130 service region." 132 Given that for non-emergency services for each query we could get a 133 large number of service URLs, a service region as per definition 134 above would be the region within which a user would get the same set 135 of service URLs. If one or more of the URLs in the set changes, the 136 set of URLs changes that is, the service region changes. Therefore, 137 for non-emergency services we can distinguish two types of service 138 regions. One is the region served by the single POI (e.g., pizza 139 delivery), the other one is according to the definition in [RFC5222] 140 the region within which the client would always get the same set of 141 service URLs. The second type of service region includes multiple 142 service regions of the first type. Because of this, the service 143 region as defined in [RFC5222] would change very frequently, making 144 the use of service regions as described in [RFC5222] not that useful. 146 This difference between emergency and non-emergency services is due 147 to the fact that PSAPs have service regions that do not overlap 148 significantly with one another and one service region is served by a 149 single PSAP. As explained above, this is not the case for non- 150 emergency services. 152 Generally speaking, we can divide location-based services into two 153 main categories. 155 Services based on: 156 o how far they are from the user (e.g., ATM machines, takeout) 157 o whether or not their service region includes the client's current 158 location (e.g., pizza delivery, NG9-1-1) 160 For services included in the first category service regions are not 161 relevant while they are important for services included in the second 162 category. This distinction becomes obvious if we consider the 163 difference between takeout (first category) and delivery (second 164 category), for example. In the case of takeout, the user wants to go 165 to a particular restaurant and buy dinner regardless of his location 166 falling in the restaurant service region or not. For delivery the 167 user cares about the restaurant service region as the restaurant will 168 deliver food to him only if the user's location falls within the 169 restaurant service region. 171 There is a clear distinction between services that require service 172 regions and services that do not. The LoST extensions defined in 173 this document take this into account by using the service 174 classification mentioned above. 176 4. New Query Types: "N nearest", "within distance X" and "served by" 178 We introduce three new types of queries, "N nearest", "within 179 distance X" and "served by". The first query returns the N points of 180 interest closest to the client's physical location, the second query 181 discovers all those points of interest located within a given 182 distance from the client's physical location, the third query returns 183 all those points of interest whose service region includes the 184 client's current location. 186 5. LoST Extensions 188 For queries "within distance X", the LoST client needs to specify to 189 the server the range within which instances of a particular service 190 should be searched. In order to do this, we make use of various 191 shapes [PIDF-LO] in LoST queries. 193 For queries "served by", the LoST client needs to let the server know 194 that it MUST return only those services whose service region includes 195 the client's current location. In order to do this we introduce the 196 element in queries. Service region boundaries 197 MAY be returned in a LoST as described in 198 [RFC5222]. 200 For queries "N nearest", the LoST client needs to let the server know 201 N, that is, the maximum number of service URIs to be returned in a 202 response. In order to specify this, we introduce the element 203 in queries. 205 Also, we introduce a new element in LoST responses, namely 206 . This new element is used by the server to 207 indicate to the client the physical location of points of interest. 208 In doing so, the client can compute the distance and other metrics 209 between its current location and the points of interest. 211 The new elements , and are defined in 212 the "lostNe" namespace. This new namespace is defined in Section 6. 214 5.1. New Use of Shapes in Queries 216 In [PIDF-LO] different shapes are defined in order to represent a 217 point and an area of uncertainty within which the user might be 218 situated. While this remains true for "served by" queries, for 219 "within distance X" queries such shapes represent the area within 220 which we want to find a service. 222 For example, Figure 1 shows a geodetic query using the 223 circular shape. In particular, with the query shown in Figure 1, we 224 are asking the LoST server to send us a list of service URNs for 225 pizza places within 200 meters from our approximate position 226 specified in . 228 Aside from the circular shape, other shapes are also useful. In 229 particular, there are situations in which it is useful to query for 230 services in a certain direction of movement rather than in an exact 231 physical location. For example, if a user is driving north from New 232 York City to Boston, it would be useful for this user to be able to 233 query for services north of where he currently is that is, not at his 234 current physical location nor at his final destination. 236 In order to do this, we use shapes such as an ellipse. The ellipse 237 has a major and a minor dimension thus allowing for defining a 238 "priviledged" direction by having the major dimension in the 239 direction of movement. In the present context the circular shape 240 allows a device to search for services in any direction sourrounding 241 its physical location while shapes such as the ellipse allow the 242 device to search for services in a more specific direction. The 243 ellipse shape is defined in [PIDF-LO]. 245 246 251 252 253 37.775 -122.422 254 255 200 256 257 258 259 urn:service:local.pizza 260 262 Figure 1: A 'within distance X' geodetic query using 263 the circular shape 265 5.2. Queries Based on Service Regions 267 As mentioned in Section 1, we can divide location-based services into 268 two main categories. 270 Services based on: 271 o how far they are from the user 272 o wether or not their service region includes the client's current 273 location 275 A "within distance X" query addresses services included in the first 276 category while a "served by" query addresses services included in the 277 second category. 279 When querying LoST regarding a specific service, we need to specify 280 if such service belongs to either the first or the second category. 281 This is necessary since depending on the category the service belongs 282 to, the LoST server has to follow a different metric in selecting the 283 results to include in the response. 285 In order for the client to specify which of the two categories the 286 service belongs to, we introduce the element. This new 287 element is of type boolean. When its value is true it means that the 288 requested service belongs to the second category and a search based 289 on service regions MUST be performed by the LoST server. When either 290 its value is false or the element is missing, the LoST 291 server MUST perform a search based on the distance between the user 292 and the points of service. 294 For a search based on service regions the LoST server MUST return 295 only those services whose service region includes the client's 296 current location. Service region boundaries MAY be returned in a 297 LoST as described in [RFC5222]. 299 300 305 true 306 307 308 37.775 -122.422 309 310 200 311 312 313 314 urn:service:local.pizza 315 317 Figure 2: A 'served by' geodetic query with the new 318 element 320 5.3. Difference Between "within distance X" and "served by" Queries 322 Figures 1 and 2 show an example of a "within distance X" query and a 323 "served by" query, respectively. The two types of queries although 324 very similar have three important differences. 325 o A "served by" query can support all the shapes a "within distance 326 X" query can support plus the point shape which does not make 327 sense for a "within distance X" query. 328 o In a "within distance X" query a shape represents the area within 329 which to search for points of service. In all other types of 330 queries including a "served by" query, a shape represents an 331 uncertainty in the location of the client. 332 o In a "within distance X" query the value of the element, 333 if present, MUST be false. If such element is not present, its 334 value MUST be assumed equal to false. A "served by" query SHALL 335 have the value of the element always set to true. 337 5.4. Limiting the Number of Returned Service URIs 339 Limiting the number of results is helpful, particularly for mobile 340 devices with limited bandwidth. For "N nearest" queries, the client 341 needs to be able to tell the server to return no more than N service 342 URIs. In order to specify such limit we introduce a new element, 343 namely . This new element is OPTIONAL but when present, it 344 MUST be conveyed inside the element defined in 345 [RFC5222]. 347 Figures 3, 4 and 5 show a geodetic query where the 348 client asks the server to return no more than 20 service URIs. In 349 particular, Figure 3 shows a 'N nearest' query, Figure 4 shows a 350 query which is a combination of 'N nearest' and 'within distance X' 351 while Figure 5 shows a query which is a combination of 'N nearest' 352 and 'served by'. When receiving such queries, the LoST server will 353 return a list of no more than 20 points of interest. 355 If the available points of interest are more than N, then the server 356 has to identify among the points of interest to return, the N points 357 of interest closest to the client's physical location and MUST return 358 those in the response. 360 When the element is not present in a query then 361 all available points of interest for the requested type of service 362 SHALL be returned by the LoST server. 364 365 369 20 370 371 372 40.7128 -74.0092 373 374 375 urn:service:food.pizza 376 378 Figure 3: A 'N nearest' geodetic query with the new 379 element 381 382 388 false 389 20 390 391 392 37.775 -122.422 393 394 200 395 396 397 398 urn:service:local.pizza 399 401 Figure 4: A geodetic query with the new and 402 elements. This query is a combination of 'N nearest' and 403 'within distance X' queries. 405 406 412 true 413 20 414 415 416 37.775 -122.422 417 418 100 419 420 421 422 urn:service:local.pizza 423 425 Figure 5: A geodetic query with the new and 426 elements. This query is a combination of 'N nearest' and 427 'served by' queries. 429 5.5. The Element in Responses 431 It is important for the LoST client to know the location of a point 432 of interest so that distance, route and other metrics can be 433 computed. We introduce a new element, namely . The 434 element contains the geodetic coordinates of a 435 point of service and SHOULD be used for all non-emergency services. 436 When it is used, it MUST be contained in a element. In 437 responses such as [RFC5222], a list of service 438 URIs, each with its own element, SHOULD be 439 returned. The order of service URIs in the list is not relevant. 441 The element has one single attribute, 'profile', in 442 order to specify the profile used. Only geodetic profiles SHOULD be 443 used as the computation of the distance, route and other metrics 444 would at some point require geocoding of the civic address in 445 geodetic coordinates. Because of this, the position specified in 446 SHOULD be represented by using the element. 447 The element is described in Section 12.2 of [RFC5222] and in 448 Section 5.2.1 of [PIDF-LO]. Figure 6 shows a 449 answer containing two location-to-service-URI mappings. 451 [NOTE: The element cannot be extended for this purpose 452 as it is defined outside of the element. In particular, in 453 a response the element is always one, while the number 454 of service URIs is typically more than one.] 456 There are situations, however, in which it is helpful to include a 457 civic address together with the geodetic coordinates of a point of 458 service. Usually, databases already contain the civic address of 459 points of interest and for devices with limited capabilities it is 460 not always possible to perform decoding of geocoordinates in order to 461 determine the civic address. Because of this, including also the 462 civic address in a response can be useful. In order to do this, it 463 is RECOMMENDED to include the element as defined in 464 [RFC5139] in each element. Figure 6 shows a 465 answer with the element. 467 468 471 476 477 Che bella pizza e all' anima da' pizza da Toto' 478 479 urn:service:local.pizza 480 sip:chebella@example.com 481 xmpp:chebella@example.com 482 2129397040 483 484 485 33.665 -112.432 486 487 488 490 US 491 New York 492 New York 493 Broadway 494 321 495 10027 496 497 498 503 504 King Mario's Pizza 505 506 urn:service:local.pizza 507 sip:marios@example.com 508 xmpp:marios@example.com 509 2129397157 510 511 512 33.683 -112.412 513 514 515 517 US 518 New York 519 New York 520 Amsterdam Avenue 521 123 522 10027 523 524 525 526 527 528 529 530 532 Figure 6: A answer 534 6. Relax NG Schema 536 This section provides the Relax NG schema of LoST extensions in the 537 compact form. The verbose form is included in Section 9. 539 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 540 default namespace ns1 = "urn:ietf:params:xml:ns:lostNe" 542 ## 543 ## Extensions to the Location-to-Service Translation (LoST) 544 ## Protocol 546 ## 547 ## LoST Extensions define three new elements: limit, region and 548 ## serviceLocation. 549 ## 550 start = 551 limit 552 | region 553 | serviceLocation 555 ## 556 ## A limit to the number of returned results. 557 ## 558 div { 559 limit= 560 element limit { 561 xsd:positiveInteger 562 } 563 } 565 ## 566 ## A boolean variable to request a search 567 ## based on either service regions or distance. 568 ## 569 div { 570 region= 571 element region { 572 xsd:boolean 573 } 574 } 576 ## 577 ## Location Information 578 ## 579 div { 580 locationInformation = 581 extensionPoint+, 582 attribute profile { xsd:NMTOKEN }? 583 } 585 ## 586 ## Location Information about the returned point 587 ## of service. 588 ## 589 div { 590 serviceLocation= 591 element serviceLocation { locationInformation }+ 593 } 595 ## 596 ## Patterns for inclusion of elements from schemas in 597 ## other namespaces. 598 ## 599 div { 601 ## 602 ## Any element not in the LoST Extensions 603 ## namespace. 604 ## 605 notLostExt = element * - (ns1:* | ns1:*) { anyElement } 607 ## 608 ## A wildcard pattern for including any element 609 ## from any other namespace. 610 ## 611 anyElement = 612 (element * { anyElement } 613 | attribute * { text } 614 | text)* 616 ## 617 ## A point where future extensions 618 ## (elements from other namespaces) 619 ## can be added. 620 ## 621 extensionPoint = notLostExt* 622 } 624 7. Security Considerations 626 The same security considerations as in [RFC5222] apply. 628 8. IANA Considerations 630 8.1. LoST Extensions Relax NG Schema Registration 632 URI: urn:ietf:params:xml:schema:lostNe 634 Registrant Contact: Andrea G. Forte, andreaf@cs.columbia.edu, Henning 635 Schulzrinne, hgs@cs.columbia.edu 637 Relax NG Schema: The Relax NG schema to be registered is contained in 638 Section 6. Its first line is 640 default namespace ns1 = "urn:ietf:params:xml:ns:lostNe" 642 and its last line is 644 } 646 8.2. LoST Extensions Namespace Registration 648 URI: urn:ietf:params:xml:ns:lost1:ext 650 Registrant Contact: Andrea G. Forte, andreaf@cs.columbia.edu, Henning 651 Schulzrinne, hgs@cs.columbia.edu 653 XML: 655 BEGIN 656 657 659 660 661 663 LoST Extensions Namespace 664 665 666

Namespace for LoST Extensions

667

urn:ietf:params:xml:ns:lostNe

668

See 669 RFCXXXX.

670 671 672 END 674 9. Non-Normative RELAX NG Schema in XML Syntax 676 677 682 684 685 Extensions to the Location-to-Service Translation (LoST) 686 Protocol. 687 LoST Extensions define three new elements: limit, region and 688 serviceLocation. 689 690 691 692 693 694 695 697
698 699 A limit to the number of returned results. 700 702 703 704 705 706 707
709
710 711 A boolean variable to request a search 712 based on either service regions or distance. 713 715 716 717 718 719 720
722
723 724 Location Information 725 727 728 729 730 731 732 733 734 735 736 737
739
740 741 Location Information about the returned point of service. 742 744 745 746 747 748 749
751
752 753 Patterns for inclusion of elements from schemas in 754 other namespaces. 755 757 758 759 Any element not in the LoST Extensions namespace. 760 761 762 763 764 765 766 767 768 769 770 772 773 774 A wildcard pattern for including any element 775 from any other namespace. 776 777 778 779 780 781 782 783 784 785 786 787 788 789 791 792 793 A point where future extensions 794 (elements from other namespaces) 795 can be added. 796 797 798 799 800 801
803
805 10. References 807 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 808 Requirement Levels", BCP 14, RFC 2119, March 1997. 810 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 811 Tschofenig, "LoST: A Location-to-Service Translation 812 Protocol", RFC 5222, August 2008. 814 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 815 Format for Presence Information Data Format Location 816 Object (PIDF-LO)", RFC 5139, February 2008. 818 [PIDF-LO] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 819 PIDF-LO Usage Clarification, Considerations and 820 Recommendations. IETF Internet Draft (Work in Progress)", 821 February 2008. 823 Authors' Addresses 825 Andrea G. Forte 826 Columbia University 827 Department of Computer Science 828 1214 Amsterdam Avenue, MC 0401 829 New York, NY 10027 830 USA 832 Email: andreaf@cs.columbia.edu 834 Henning Schulzrinne 835 Columbia University 836 Department of Computer Science 837 1214 Amsterdam Avenue, MC 0401 838 New York, NY 10027 839 USA 841 Email: hgs@cs.columbia.edu