idnits 2.17.1 draft-ietf-geopriv-pdif-lo-profile-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 845. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 822. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 829. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 835. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 55: '... GML that MUST be implemented by app...' RFC 2119 keyword, line 182: '... geopriv element MUST describe a discr...' RFC 2119 keyword, line 185: '...ocation description SHOULD reside in a...' RFC 2119 keyword, line 189: '... document (PIDF) MUST only be done if ...' RFC 2119 keyword, line 193: '... element SHOULD be avoided where ...' (19 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 645 has weird spacing: '... 153 element, and there may be one or more actual locations described 154 inside the element. 156 Graphically, the structure of the PIDF/PIDF-LO can be depicted as 157 follows: 159 PIDF document 160 tuple 1 161 status 162 geopriv 163 location-info 164 civicAddress 165 location 166 usage-rules 167 geopriv 2 168 geopriv 3 169 . 170 . 171 . 173 tuple 2 174 tuple 3 176 All of these potential sources and storage places for location lead 177 to confusion for the generators, conveyors and users of location 178 information. Practical experience within the United States National 179 Emergency Number Association (NENA) in trying to solve these 180 ambiguities led the following conventions being adopted: 182 Rule #1: A geopriv element MUST describe a discrete location. 184 Rule #2: Where a discrete location can be uniquely described in more 185 than one way, each location description SHOULD reside in a 186 separate tuple. 188 Rule #3: Providing more than one location in a single presence 189 document (PIDF) MUST only be done if all objects describe the same 190 location. 192 Rule #4: Providing more than one location in a single 193 element SHOULD be avoided where possible. 195 Rule #5: When providing more than one location in a single 196 element the locations MUST be provided by a common 197 source. 199 Rule #6: Providing more than one location in a single 200 element SHOULD only be done if they form a complex to describe the 201 same location. For example, a geodetic location describing a 202 point, and a civic location indicating the floor in a building. 204 Rule #7: Where a location complex is provided in a single 205 element, the macro locations MUST be provided 206 first. For example, a geodetic location describing an area, and a 207 civic location indicating the floor MUST be represented with the 208 area first followed by the civic location. 210 Rule #8: Where a PIDF document contains more than one tuple 211 containing a status element with a geopriv location element , the 212 priority of tuples SHOULD be based on tuple position within the 213 PIDF document. That is to say, the tuple with the highest 214 priority location occurs earliest in the PIDF document. Initial 215 priority SHOULD be determined by the originating UA, the final 216 priority MAY be determined by a proxy along the way, or the UAS. 218 Rule #9: Where multiple PIDF documents are contained within a single 219 request, document selection SHOULD be based on document order. 221 The following examples illustrate the application of these rules. 223 4.1. Single Civic Location Information 225 Jane is at a coffee shop on the ground floor of a large shopping 226 mall. Jane turns on her laptop and connects to the coffee-shop's 227 WiFi hotspot, Jane obtains a complete civic address for her current 228 location, for example using [6]. A Location Object is constructed 229 consisting of a single PIDF document, with a single geopriv tuple, 230 and a single location residing in the element. This 231 document is unambiguous, and should be interpreted correctly if sent 232 of the network. 234 4.2. Civic and Geospatial Location Information 236 Mike is visiting his Seattle office and connects his laptop into the 237 Ethernet port in a spare cube. Mike's computer receives a location 238 over DHCP as defined in [2]. In this case the location is a geodetic 239 location, with the altitude represented as a building floor number. 240 This is constructed by Mike's computer into the following PIDF 241 document: 243 244 249 250 251 252 253 254 2 255 256 257 258 259 260 2006-01-30T20:57:29Z 261 262 263 264 265 266 268 269 270 37.775 -122.4194 271 37.555 -122.4194 272 37.555 -122.4264 273 37.775 -122.4264 274 37.775 -122.4194 275 276 277 278 279 280 281 282 2006-01-30T20:57:29Z 283 284 286 The constructed PIDF document contains two geopriv elements each in a 287 separate PIDF tuple, the first being a civic address made up of only 288 floor, the second containing the provided geodetic information. If 289 the location is required for routing purposes, which information is 290 used? Applying rule #8, we will likely fail, or at a minimum need to 291 fall back to the second tuple describing the geodetic location, a 292 route described by floor only is not precise enough in the normal 293 case to permit route selection. If rule #6 and #7 are applied, then 294 the revised PIDF-LO document creates a complex as shown below. 296 297 302 303 304 305 306 308 309 310 37.775 -122.4194 311 37.555 -122.4194 312 37.555 -122.4264 313 37.775 -122.4264 314 37.775 -122.4194 315 316 317 318 319 2 320 321 322 323 324 325 2003-06-22T20:57:29Z 326 327 329 It is now clear that the main location of user is inside the 330 rectangle bounded by the geodetic coordinates specfied. Further that 331 the user is on the second floor of the building located at these 332 coordinates. 334 4.3. Manual/Automatic Configuration of Location Information 336 Loraine has a predefined civic location stored in her laptop, since 337 she normally lives in Sydney, the address in her address is for her 338 Sydney-based apartment. Loraine decides to visit sunny San 339 Francisco, and when she gets there she plugs in her laptop and makes 340 a call. Loraine's laptop receives a new location from the visited 341 network in San Francisco. As ths system cannot be sure that the pre- 342 existing and new location describe the same place, Loraine's computer 343 generates a new PIDF-LO and will use this to represent Loraine's 344 location. If Loraine's computer were to add the new location to her 345 existing PIDF location document (breaking rule #3), then the correct 346 information may still be interpretted by location recipient providing 347 Loraine's system applies rule #9. In this case the resulting order 348 of location information in the PIDF document should be San Francisco 349 first, followed by Sydney. Since the information is provided by 350 different sources, rule #8 should also be applied and the information 351 placed in different tuples with San Francisco first. 353 5. Geodetic Coordinate Representation 355 The geodetic examples provided in [3] are illustrated using the gml: 356 location element which uses the gml:coordinates elements (inside the 357 gml:Point element) and this representation has several drawbacks. 358 Firstly, it has been deprecated in later versions of GML (3.1 and 359 beyond) making it inadvisable to use for new applications. Secondly, 360 the format of the coordinates type is opaque and so can be difficult 361 to parse and interpret to ensure consistent results, as the same 362 geodetic location can be expressed in a variety of ways. The PIDF-LO 363 Geodetic Shapes specification [5] provides a specific GML profile for 364 expressing commonly used shapes using simple GML representations. 365 The shapes defined in [5] are the recommended shapes to ensure 366 interoperability between location based applications. 368 6. Geodetic Shape Representation 370 The cellular mobile world today makes extensive use of geodetic based 371 location information for emergency and other location-based 372 applications. Generally these locations are expressed as a point 373 (either in two or three dimensions) and an area or volume of 374 uncertainty around the point. In theory, the area or volume 375 represents a coverage in which the user has a relatively high 376 probability of being found, and the point is a convenient means of 377 defining the centroid for the area or volume. In practice, most 378 systems use the point as an absolute value and ignore the 379 uncertainty. It is difficult to determine if systems have been 380 implement in this manner for simplicity, and even more difficult to 381 predict if uncertainty will play a more important role in the future. 382 An important decision is whether an uncertainty area should be 383 specified. 385 [5] defines eight shape types most of which are easily translated in 386 shapes definitions used in other applications and protocol, such as 387 Open Mobile Alliance (OMA) Mobile Location Protocol (MLP). For 388 completeness the shape defined in [5] are listed below: 390 o Point (2d or 3d) 392 o Polygon (2d) 394 o Circle (2d) 396 o Ellipse (2d) 398 o Arc band (2d) 400 o Sphere (3d circle) 402 o Ellipsoid (3d) 404 o Prism (3d polygon) 406 [5] also describes a standard set of coordinate reference systems 407 (CRS), unit of measure and conventions relating to lines and 408 distances that will be repeated here. 410 7. Recommendations 412 As a summary this document gives a few recommendations on the usage 413 of location information in PIDF-LO. Nine rules specified in 414 Section 4 give guidelines on the ambiguity of PIDF-LO with regard to 415 the occurrence of multiple location information. It is recommend 416 that only the shape types and shape representations described in [5] 417 be used to express geodetic locations for exchange between general 418 applications. By standardizing geodetic data representation 419 interoperability issues are mitigated. 421 If Geodetic information is to be provided via DHCP, then a minimum 422 resolution of 20 bits SHOULD be specified for both the Latitude and 423 Longitude fields to achieve sub 100 metre precision. Where only two 424 dimensional objects are required polygons SHOULD be used to express 425 the enclosed area. Where 3 dimensions are required a rectangular 426 prism SHOULD be used. 428 8. Security Considerations 430 The primary security considerations relate to how location 431 information is conveyed and used, which are outside the scope of this 432 document. This document is intended to serve only as a set of 433 guidelines as to which elements MUST or SHOULD be implemented by 434 systems wishing to perform location dependent routing. The 435 ramification of such recommendations is that they extend to devices 436 and clients that wish to make use of such services. 438 9. IANA Considerations 440 This document does not introduce any IANA considerations. 442 10. Acknowledgments 444 The authors would like to thank the GEOPRIV working group for their 445 discussions in the context of PIDF-LO, in particular Carl Reed, Ron 446 Lake, James Polk and Henning Schulzrinne. Furthermore, we would like 447 to thank Jon Peterson as the author of PIDF-LO and Nadine Abbott for 448 her constructive comments in clarifying some aspects of the document. 450 11. Open Issues 452 Do we need to indicate which shapes are acceptable for emergency 453 calling? Ceratinly not all can be used today, for example the 454 polygon and prism types will not work with NENA i2 as it is defined 455 today due to restrictions over the VE2 interface [7]. 457 12. References 459 12.1. Normative references 461 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 462 Levels", March 1997. 464 12.2. Informative References 466 [2] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 467 Configuration Protocol Option for Coordinate-based Location 468 Configuration Information", RFC 3825, July 2004. 470 [3] Peterson, J., "A Presence-based GEOPRIV Location Object 471 Format", RFC 4119, December 2005. 473 [4] Thomson, M. and J. Winterbottom, "Revised Civic Location Format 474 for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-01 (work in 475 progress), January 2006. 477 [5] Thomson, M., "draft-thomson-geopriv-geo-shape, Geodetic Shapes 478 for the Representation of Uncertainty in PIDF-LO", 479 January 2006. 481 [6] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 482 and DHCPv6) Option for Civic Addresses Configuration 483 Information", draft-ietf-geopriv-dhcp-civil-09 (work in 484 progress), January 2006. 486 [7] "NENA Standard for the Implementation of the Wireless Emergency 487 Service Protocol E2 Interface". 489 [8] Schulzrinne, H., "A Document Format for Expressing Privacy 490 Preferences", draft-ietf-geopriv-common-policy-07 (work in 491 progress), February 2006. 493 [9] "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project; 494 Technical Specification Group Code Network; Universal 495 Geographic Area Description (GAD)". 497 [10] "TR-45 J-STD-036-AD-2 Enhanced Wireless 9-1-1 Phase 2". 499 Appendix A. Creating a PIDF-LO from DHCP Geo Encoded Data 501 RFC-3825 [2] describes a means by which an end-point may learns it 502 location from information encoded into DHCP option 123. The 503 following section describes how and end-point can take this 504 information and represent it in a well formed PIDF-LO describing this 505 geodetic location. 507 The location information described in RFC-3825 consists of a 508 latitude, longitude, altitude and datum. 510 A.1. Latitude and Longitude 512 The latitude and longitude values are represented in degrees and 513 decimal degrees. Latitude values are positive if north of the 514 equator, and negative if south of the equator. Similarly 515 longitudinal values are positive if east of the Greenwich meridian, 516 and negative if west of the Greenwich meridian. 518 The latitude and longitude values are each 34 bit long fields 519 consisting of a 9 bit integer component and a 25 bit fraction 520 component, with negative numbers being represented in 2s complement 521 notation. The latitude and longitude fields are each proceeded by a 522 6 bit resolution field, the LaRes for latitude, and the LoRes for 523 longitude. The value in the LaRes field indicates the number of 524 significant bits to interpret in the Latitude field, while the value 525 in the LoRes field indicates the number of significant bits to 526 interpret in the Longitude field. 528 For example, if you are in Wollongong Australia which is located at 529 34 Degrees 25 minutes South and 150 degrees 32 minutes East this 530 would translate to -34.41667, 150.53333 in decimal degrees. If these 531 numbers are translated to their full 34 bit representations, then we 532 arrive the following: 534 Latitude = 111011101.1001010101010101000111010 536 Longitude = 0100101101000100010001000010100001 538 RFC-3825, uses the LaRes and LoRes values to specify a lower and 539 upper boundary for location thereby specifying an area. The size of 540 the area specified is directly related to the value specified in the 541 LaRes and LoRes fields. 543 Using the previous example, if LaRes is set 7, then lower latitude 544 boundary can be calculated as -256+128+64+16+8+4, which is -36 545 degrees, the upper boundary then becomes -256+128+64+16+8+4+2+1 which 546 is -35 degrees. LoRes may be used similarly for Longitude. 548 So what level of precision is useful? Well, certain types of 549 applications and regulations call for different levels of precision, 550 and the required precision may vary depending on how the location was 551 determined. For Cellular 911 calls in the United States, for 552 example, if the network measures the location then the caller should 553 be within 100 metres, while if the handset does the measurement then 554 the location should be within 50 metres. Since DHCP is a network 555 based mechanism we will benchmark off 100 metres (approximately 330 556 ft) which is still a large area. 558 For simplicity we shall assume that we are defining a square, in 559 which we are equally to appear anywhere. The greatest distance 560 through this square is across the diagonal, so we make this 100 561 metres. 563 +----------------------+ 564 | _/| 565 | _/ | 566 | _/ | 567 | _/ | 568 | _/ | 569 | 100_/ metres | 570 | _/ | 571 | _/ | 572 | _/ | 573 | _/ | 574 |_/ | 575 +----------------------+ 577 The distance between the top and the bottom and the left and the 578 right is the same, the area being a square, and this works out to be 579 70.7 metres. When expressed in decimal degrees, the third point 580 after the decimal place represents about 100 metre precision, this 581 equates to 10 binary places of fractional part. A 70 metre distance 582 is required, so 11 fractional binary digits are necessary resulting 583 in a total of 20 bits of precision. 585 With -34.4167, 150.5333 encoded with 20 bits of precision for the 586 LaRes and LoRes, the corners of the enclosing square are: 588 Point 1 (-34.4170, 150.5332) 589 Point 2 (-34.4170, 150.5337) 590 Point 3 (-34.4165, 150.5332) 591 Point 4 (-34.4165, 150.5337) 593 A.2. Altitude 595 The altitude elements define how the altitude is encoded and to what 596 level of precision. The units for altitude are either metres, or 597 floors, with the actual measurement being encoded in a similar manner 598 to those for latitude and longitude, but with 22 bit integer, and 8 599 bit fractional components. 601 A.3. Generating the PIDF-LO 603 If altitude is not required, or is expressed in floors then a 604 geodetic location expressed by a polygon SHOULD be used, with points 605 expressed in a counter-clockwise direction. If the altitude is 606 expressed in floors and is required, the altitude SHOULD be expressed 607 as a civic floor number as part of the same location-info element. 608 In the example above the GML for the location would be expressed as 609 follows: 611 613 614 615 -34.4165 150.5332 616 -34.4170 150.5532 617 -34.4170 150.5537 618 -34.4165 150.5337 619 -34.4165 150.5332 620 621 622 624 If a floor number of say 3 were included, then the location-info 625 element would contain the above information and the following: 627 629 2 630 632 When altitude is expressed as an integer and fractional component, as 633 with the latitude and longitude, it expresses a range which requires 634 the prism form to be used. Care must be taken to ensure that the 635 points are defined in a counter-clowise direction to ensure that the 636 upward normal points up. 638 Extending the previous example to include an altitude expressed in 639 metres rather than floors. AltRes is set to a value of 19, and the 640 Altitude value is set to 34. Using similar techniques as shown in 641 the latitude and longitude section, a range of altitudes between 32 642 metres and 40 metres is described. The prism would therefore be 643 defined as follows: 645 648 649 650 651 652 -34.4165 150.5332 32 653 -34.4170 150.5532 32 654 -34.4170 150.5537 32 655 -34.4165 150.5337 32 656 -34.4165 150.5332 32 657 658 659 660 661 662 8 663 664 666 The Method value SHOULD be set to DHCP. Note that this case, the 667 DHCP is referring to the way in which location information was 668 delivered to the IP-device, and not necessarily how the location was 669 determined. 671 The timestamp value SHOULD be set to the time that location was 672 retrieved from the DHCP server. 674 The client application MAY insert any usage rules that are pertinent 675 to the user of the device and that comply with [8]. A guideline is 676 that the any retention-expiry value SHOULD NOT exceed the current 677 lease time. 679 The Provided-By element SHOULD NOT be populated as this is not 680 provided by the source of the location information. 682 The 3 completed PIDF-LO representations are provided below, and 683 represent a location without altitude, a location with a civic 684 altitude, and a location represented as a 3 dimensional rectangular 685 prism. 687 688 694 695 696 697 698 699 700 701 -34.4165 150.5332 702 -34.4170 150.5532 703 -34.4170 150.5537 704 -34.4165 150.5337 705 -34.4165 150.5332 706 707 708 709 710 711 DHCP 712 713 714 2005-07-05T14:49:53+10:00 715 716 717 718 725 726 727 728 729 730 731 732 -34.4165 150.5332 733 -34.4170 150.5532 734 -34.4170 150.5537 735 -34.4165 150.5337 736 -34.4165 150.5332 737 738 739 740 741 2 742 743 744 745 DHCP 746 747 748 2005-07-05T14:49:53+10:00 749 750 751 752 758 759 760 761 762 763 764 765 766 767 -34.4165 150.5332 32 768 -34.4170 150.5532 32 769 -34.4170 150.5537 32 770 -34.4165 150.5337 32 771 -34.4165 150.5332 32 772 773 774 775 776 777 8 778 779 780 781 782 DHCP 783 784 785 2005-07-05T14:49:53+10:00 786 787 789 Authors' Addresses 791 James Winterbottom 792 Andrew Corporation 793 Wollongong 794 NSW Australia 796 Email: james.winterbottom@andrew.com 798 Martin Thomson 799 Andrew Corporation 800 Wollongong 801 NSW Australia 803 Email: martin.thomson@andrew.com 805 Hannes Tschofenig 806 Siemens 807 Otto-Hahn-Ring 6 808 Munich, Bavaria 81739 809 Germany 811 Email: Hannes.Tschofenig@siemens.com 813 Intellectual Property Statement 815 The IETF takes no position regarding the validity or scope of any 816 Intellectual Property Rights or other rights that might be claimed to 817 pertain to the implementation or use of the technology described in 818 this document or the extent to which any license under such rights 819 might or might not be available; nor does it represent that it has 820 made any independent effort to identify any such rights. Information 821 on the procedures with respect to rights in RFC documents can be 822 found in BCP 78 and BCP 79. 824 Copies of IPR disclosures made to the IETF Secretariat and any 825 assurances of licenses to be made available, or the result of an 826 attempt made to obtain a general license or permission for the use of 827 such proprietary rights by implementers or users of this 828 specification can be obtained from the IETF on-line IPR repository at 829 http://www.ietf.org/ipr. 831 The IETF invites any interested party to bring to its attention any 832 copyrights, patents or patent applications, or other proprietary 833 rights that may cover technology that may be required to implement 834 this standard. Please address the information to the IETF at 835 ietf-ipr@ietf.org. 837 Disclaimer of Validity 839 This document and the information contained herein are provided on an 840 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 841 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 842 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 843 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 844 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 845 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 847 Copyright Statement 849 Copyright (C) The Internet Society (2006). This document is subject 850 to the rights, licenses and restrictions contained in BCP 78, and 851 except as set forth therein, the authors retain all their rights. 853 Acknowledgment 855 Funding for the RFC Editor function is currently provided by the 856 Internet Society.