idnits 2.17.1 draft-ietf-geopriv-pdif-lo-profile-02.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 1381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1358. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1365. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1371. ** 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 56: '...ecommends a subset of GML that MUST be...' RFC 2119 keyword, line 178: '... A GeoPriv tuple MUST completely defin...' RFC 2119 keyword, line 181: '...tion description SHOULD reside in a se...' RFC 2119 keyword, line 184: '... document (PIDF) MUST only be done if ...' RFC 2119 keyword, line 188: '... element SHOULD be avoided where ...' (28 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [2], but that reference does not seem to mention RFC 2119 either. -- 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 (February 4, 2006) is 6655 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '10' is defined on line 1024, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Obsolete informational reference (is this intentional?): RFC 3825 (ref. '3') (Obsoleted by RFC 6225) == Outdated reference: A later version (-11) exists of draft-ietf-geopriv-common-policy-06 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Geopriv J. Winterbottom 3 Internet-Draft M. Thomson 4 Expires: August 8, 2006 Andrew Corporation 5 H. Tschofenig 6 Siemens 7 February 4, 2006 9 GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations 10 draft-ietf-geopriv-pdif-lo-profile-02.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 8, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 The Presence Information Data Format Location Object (PIDF-LO) 44 specification provides a flexible and versatile means to represent 45 location information. There are, however, circumstances that arise 46 when information needs to be constrained in how it is represented so 47 that the number of options that need to be implemented in order to 48 make use of it are reduced. There is growing interest in being able 49 to use location information contained in a PIDF-LO for routing 50 applications. To allow successfully interoperability between 51 applications, location information needs to be normative and more 52 tightly constrained than is currently specified in the PIDF-LO. This 53 document makes recommendations on how to constrain, represent and 54 interpret locations in a PIDF-LO. It further looks at existing 55 communications standards that make use of geodetic information for 56 routing purposes and recommends a subset of GML that MUST be 57 implemented by applications to allow location dependent routing to 58 occur. 60 Table of Contents 62 1. CHANGES SINCE LAST TIME . . . . . . . . . . . . . . . . . . . 4 63 1.1. 01 changes . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Using Location Information . . . . . . . . . . . . . . . . . . 7 67 4.1. Single Civic Location Information . . . . . . . . . . . . 8 68 4.2. Civic and Geospatial Location Information . . . . . . . . 9 69 4.3. Manual/Automatic Configuration of Location Information . . 11 70 5. Geodetic Coordinate Representation . . . . . . . . . . . . . . 12 71 6. Uncertainty in Location Representation . . . . . . . . . . . . 14 72 6.1. Arc band . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 6.2. Ellipsoid Point With Uncertainty Circle . . . . . . . . . 18 74 6.3. Polygon . . . . . . . . . . . . . . . . . . . . . . . . . 21 75 7. Baseline Geometry . . . . . . . . . . . . . . . . . . . . . . 24 76 7.1. Zero Dimensions . . . . . . . . . . . . . . . . . . . . . 24 77 7.2. One Dimensions . . . . . . . . . . . . . . . . . . . . . . 24 78 7.3. Two Dimensions . . . . . . . . . . . . . . . . . . . . . . 25 79 7.4. Three Dimensions . . . . . . . . . . . . . . . . . . . . . 25 80 7.5. Envelopes . . . . . . . . . . . . . . . . . . . . . . . . 25 81 7.6. Temporal Dimensions . . . . . . . . . . . . . . . . . . . 26 82 7.7. Units of Measure . . . . . . . . . . . . . . . . . . . . . 26 83 7.8. Coordinate Reference System (CRS) . . . . . . . . . . . . 26 84 8. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 28 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 87 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 88 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 32 89 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 90 13.1. Normative references . . . . . . . . . . . . . . . . . . . 33 91 13.2. Informative References . . . . . . . . . . . . . . . . . . 33 92 Appendix A. Creating a PIDF-LO from DHCP Geo Encoded Data . . . . 34 93 A.1. Latitude and Longitude . . . . . . . . . . . . . . . . . . 34 94 A.2. Altitude . . . . . . . . . . . . . . . . . . . . . . . . . 36 95 A.3. Generating the PIDF-LO . . . . . . . . . . . . . . . . . . 36 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 97 Intellectual Property and Copyright Statements . . . . . . . . . . 42 99 1. CHANGES SINCE LAST TIME 101 1.1. 01 changes 103 minor changes to the abstract. 105 Minor changes to the introduction. 107 Added and appendix to take implementers through how to create a 108 PIDF-LO from data received using DHCP option 123 as defined in [3]. 110 Rectified examples to use position and pos rather than location and 111 point. 113 Corrected example 3 so that it does not violate SIP rules. 115 Added addition geopriv elements to the status component of the figure 116 in "Using Location Information" to more accurately reflect the 117 cardinality issues. 119 Revised text in section "Geodection Coordinate Representation. 120 Removed last example as this was addressed with the change to 121 position and pos in previous examples. 123 2. Introduction 125 The Presence Information Data Format Location Object (PIDF-LO) [1] is 126 the IETF recommended way of encoding location information and 127 associated privacy policies. Location information in PIDF-LO may be 128 described in a geospatial manner based on a subset of GMLv3, or as 129 civic location information. Uses for PIDF-LO are envisioned in the 130 context of numerous location based applications. This document makes 131 recommendations for formats and conventions to make interoperability 132 less problematic. To enhance clarify formats comparisons between GML 133 and the 3GPP Mobile Location Protocol (MLP) standard [4], are 134 examined. 136 3. Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [2]. 142 4. Using Location Information 144 The PIDF format provides for an unbounded number of tuples. The 145 geopriv element resides inside the status component of a tuple, hence 146 a single PIDF document may contain an arbitrary number of location 147 objects some or all of which may be contradictory or complementary. 148 The actual location information is contained inside a 149 element, and there may be one or more actual locations described 150 inside the element. 152 Graphically, the structure of the PIDF/PIDF-LO can be depicted as 153 follows: 155 PIDF document 156 tuple 1 157 status 158 geopriv 159 location-info 160 civicAddress 161 location 162 usage-rules 163 geopriv 2 164 geopriv 3 165 . 166 . 167 . 169 tuple 2 170 tuple 3 172 All of these potential sources and storage places for location lead 173 to confusion for the generators, conveyors and users of location 174 information. Practical experience within the United States National 175 Emergency Number Association (NENA) in trying to solve these 176 ambiguities led the following conventions being adopted: 178 Rule #1: A GeoPriv tuple MUST completely define a specific location. 180 Rule #2: Where a location can be uniquely described in more than one 181 way, each location description SHOULD reside in a separate tuple. 183 Rule #3: Providing more than one location in a single presence 184 document (PIDF) MUST only be done if all objects describe the same 185 location. 187 Rule #4: Providing more than one location in a single 188 element SHOULD be avoided where possible. 190 Rule #5: When providing more than one location in a single element they MUST be provided by a common source. If you 192 have more than one location in the element, then 193 the combination (complex of)these elements defines the complete 194 location. 196 Rule #6: Providing more than one location in a single 197 element SHOULD only be done if they form a complex to describe the 198 same location. For example, a geodetic location describing a 199 point, and a civic location indicating the floor in a building. 201 Rule #7: Where a location complex is provided in a single element, the higher precision locations MUST be provided 203 first. For example, a geodetic location describing a point, and a 204 civic location indicating the floor MUST be represented with the 205 point first followed by the civic location. 207 Rule #8: Where a PIDF document contains more than one tuple 208 containing a status element with a geopriv location element , the 209 priority of tuples SHOULD be based on tuple position within the 210 PIDF document. That is to say, the tuple with the highest 211 priority location occurs earliest in the PIDF document. Initial 212 priority SHOULD be determined by the originating UA, the final 213 priority MAY be determined by a proxy along the way. 215 Rule #9: Where multiple PIDF documents are contained within a single 216 request, document selection SHOULD be based on document order. 218 The following examples illustrate the useful of these rules. 220 4.1. Single Civic Location Information 222 Jane is at a coffee shop on the ground floor of a large shopping 223 mall. Jane turns on her laptop and connects to the coffee-shop's 224 WiFi hotspot, Jane obtains a complete civic address for her current 225 location, for example using [5]. She constructs a Location Object 226 which consists of a single PIDF document, with a single geopriv 227 tuple, with a single location residing in the 228 element. This is largely unambiguous, and if this location is sent 229 over the network, providing it understands civic addresses, correct 230 handling of any request should be possible. 232 4.2. Civic and Geospatial Location Information 234 Mike is visiting his Seattle office and connects his laptop into the 235 Ethernet port in a spare cube. Mike's computer receives a location 236 over DHCP as defined in [3]. In this case the location is a geodetic 237 location, with the altitude represented as a building floor number. 238 This is constructed by Mike's computer into the following PIDF 239 document: 241 242 247 248 249 250 251 252 2 253 254 255 256 257 258 259 2003-06-22T20:57:29Z 260 261 262 263 264 265 266 267 37.775 -122.4194 268 269 270 271 272 273 274 275 2003-06-22T20:57:29Z 276 277 279 The constructed PIDF document contains two geopriv elements each in a 280 separate PIDF tuple, the first being a civic address made up of only 281 floor, the second containing the provided geodetic information. If 282 the location is required for routing purposes, which information is 283 used? Applying rule #8, we will likely fail, or at a minimum need to 284 fall back to the second tuple describing the geodetic location, a 285 route described by floor only is precise enough in the normal case to 286 permit route selection. If rule #6 and #7 are applied, then the 287 revised PIDF-LO document would look creates a complex as shown below. 289 290 295 296 297 298 299 300 301 37.775 -122.4194 302 303 304 305 2 306 307 308 309 310 311 312 2003-06-22T20:57:29Z 313 314 316 It is now clear that the main location of user is a geodetic location 317 at latitude 37.775 and longitude -122.4194. Further that the user is 318 on the second floor of the building located at those coordinates. 320 4.3. Manual/Automatic Configuration of Location Information 322 Erin has a predefined civic location stored in her laptop, since she 323 normally lives in Sydney, the address in her address is for her 324 Sydney-based apartment. Erin decides to visit sunny San Francisco, 325 and when she gets there she plugs in her laptop and makes a call. 326 Erin's laptop receives a new location from the visited network in San 327 Francisco and adds this to her existing PIDF location document. 328 Applying rule #9, the resulting order of location information in the 329 PIDF document should be San Francisco first, followed by Sydney. 330 Since the information is provided by different sources, rule #8 331 should also be applied and the information places in different tuples 332 with San Francisco first. 334 5. Geodetic Coordinate Representation 336 The geodetic examples provided in [1] are illustrated using the gml: 337 location element which uses the gml:coordinates elements (inside the 338 gml:Point element) and this representation has several drawbacks. 339 Firstly, it has been deprecated in later versions of GML (3.1 and 340 beyond) making it inadvisable to use for new applications. Secondly, 341 the format of the coordinates type is opaque and so can be difficult 342 to parse and interpret to ensure consistent results, as the same 343 geodetic location can be expressed in a variety of ways. An 344 alternative is to use the gml:position and gml:pos elements. These 345 elements have a structured format, in that each field is represented 346 as a double, and a single space exists between each field. Such a 347 format does not introduce the same degree of misinterpretation. The 348 recommended representation therefore for expressing geodetic 349 coordinates for location based routing applications would be: 351 352 353 37.775 -122.422 354 355 357 The coordinate reference system (CRS) indicates which numbers in the 358 sequence equate to latitude, longitude etc, and in addition to this 359 the CRS also provides an indication of direction represented by the 360 sign of the number. For example, in WGS-84 (represented as CRS: 361 4326), as shown in the code snippet above, the format is latitude 362 followed by longitude. A positive value for latitude represents a 363 location north of the equator while a negative value represents a 364 location south of the equator. Similarly for longitude, a positive 365 value represents a location east of Greenwich, while a negative value 366 represents a location west of Greenwich. 368 EPSG 4326 is the two dimensional WGS-84 representation, if we wanted 369 to represented this in three dimensions, that is with an altitude as 370 well, then we would use EPSG 4979 and the format would be as follows: 372 373 374 37.775 -122.422 22 375 376 378 The format using CRS:4979 is similar to CRS:4326, though we now have 379 an altitude value. Specifically the altitude is provided in metres 380 above the geoid, which will not be useful for general routing 381 applications since the geoid is generally neither ground-level nor 382 sea-level. However, for more specialized geographic applications it 383 may be useful. 385 6. Uncertainty in Location Representation 387 The cellular mobile world today makes extensive use of geodetic based 388 location information for emergency and other location-based 389 applications. Generally these locations are expressed as a point 390 (either in two or three dimensions) and an area or volume of 391 uncertainty around the point. In theory, the area or volume 392 represents a coverage in which the user has a relatively high 393 probability of being found, and the point is a convenient means of 394 defining the centroid for the area or volume. In practice, most 395 systems today use the point as an absolute value and ignore the 396 uncertainty. It is difficult to determine if systems have been 397 implement in this manner for simplicity, and even more difficult to 398 predict if uncertainty will play a more important role in the future. 399 An important decision is whether an uncertainty area should be 400 specified. 402 There are six common ways to represent location and uncertainty, but 403 are listed below for completeness: 405 o Arc band 407 o Ellipsoid point with uncertainty circle 409 o Polygon 411 o Ellipsoid point with altitude 413 o Ellipsoid point with uncertainty ellipse 415 o Ellipsoid point with altitude and uncertainty ellipsoid 417 GML was designed to provide a very flexible abstraction on which 418 specific representations of geometric and geographic schemes could be 419 extended. Representing some of the above shapes is difficult if not 420 impossible using base GML. However, only a subset of GML, namely 421 feature.xsd, is mandatory for a PIDF-LO implementation. Extending 422 GML to easily represent these shapes may lead to interoperability 423 issues and so is not recommended. The authors of this document were 424 unable to find a means to express either an ellipse or and ellipsoid 425 using only the elements defined in feature.xsd. 427 The following sections describe four shapes that can be defined in 428 GML, and show the equivalent representation in 3GPP MLP [4]. 430 6.1. Arc band 432 Arc band is used primarily where timing advance (TA) information is 433 known. Timing advance is a mechanism used in wireless communications 434 to help ensure that handsets and base-stations remained synchronized. 435 Timing advance is stepped based on signal propagation and is fairly 436 deterministic, for GSM each increase in TA value represents 553.85 437 metres. 439 The arc band type was developed to represent the area between two 440 successive TA values and an antenna opening. This is presented in 441 3GPP as a point, two radii, and two angles representing the start and 442 the stop of the angles for the opening. 444 ,..__ 445 / `-. 446 / `-. 447 / `. 448 / \ 449 /__ \ 450 . `-. \ 451 start. `. \ 452 angle \ . 453 . | | 454 o ' | 455 . / ' 456 . / ; 457 stop . .,' / 458 angle `. / 459 `. / 460 `. ,' 461 `. ,' 462 `' 464 465 466 467 468 469 42.5463 470 -73.2512 471 472 1938.5 473 2492.3 474 63.7 475 118.4 476 477 479 481 The GML representation of this is below: 483 484 489 490 491 492 493 494 495 496 497 498 499 500 501 503 42.5463 -73.2512 504 505 506 2492.3 507 508 523 524 63.7 526 527 528 118.4 529 530 532 533 535 42.535651 -73.224473 42.538018 -73.230411 537 538 539 540 542 42.5463 -73.2512 543 544 550 551 1938.5 552 553 554 63.7 555 556 557 118.4 558 559 560 561 563 42.554016 -73.230007 42.556220 -73.223952 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 2004-12-01T09:28:43+10:00 579 580 582 This representation poses a few potential problems over the 3GPP 583 representation. In the 3GPP representation the point is absolute, 584 and everything else is defined relative to this point, ensuring that 585 the band is indeed bounded. The representation of arc band above 586 does not share all of these properties. In the GML arc band 587 representation above, the point and radii are relative, but the 588 bounding lines of the starting and finishing angles are not, these 589 are necessarily defined as independent line segments. By having to 590 define the arc enclosures as individual line segments it is possible 591 to define an unbounded arc band which would consist of two arcs some 592 arbitrary distance apart with two lines that may or may not intersect 593 them. 595 A second concern with this representing uncertainty using this 596 method, is that there is no explicit statement or way of indicating 597 to the receiving application what type of uncertainty is being 598 represented. Today several different representations of uncertainty 599 are valid with in the same application, so knowing which type is 600 being used, and how to interpret it is important, and this is 601 particularly true if the shape must also be validated as is the case 602 above. 604 Ensuring the legality of this shape type when represented in GML is 605 more complex than in MLP as the type must first be determined before 606 its validity can be assessed. Users of this shape type may be better 607 served by a formal shape definition being introduced into GeoPriv so 608 that these problems can be more readily overcome. 610 6.2. Ellipsoid Point With Uncertainty Circle 612 This shape type is used extensively over the North American NENA 613 defined E2 interface for transporting mobile geodetic location from 614 the MPC/GMLC to the ALI and subsequently the PSAPs. In 3GPP this is 615 defined as a WGS-84 point (ellipsoid point), and a radius or 616 uncertainty around that point, specified in metres. The 3GPP MLP 617 representation for an ellipsoid point with uncertainty is defined as 618 follows: 620 621 622 623 624 625 42.5463 626 -73.2512 627 628 850.24 629 630 631 633 This shape is similarly defined in GML below: 635 636 641 642 643 644 645 646 647 648 649 650 651 652 653 655 42.5463 -73.2512 656 657 658 850.24 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 2004-12-01T09:28:43+10:00 674 675 677 This type does not have all of the problems associated with the arc 678 band representation, in that the radius of the circle is relative to 679 the centre, and so the validation is unnecessary. However it does 680 suffer from the potential problem that the application still needs to 681 determine the type of uncertainty being represented, though this 682 maybe made more clear through the explicit use of the gml: 683 CircleByCenterPoint element. 685 6.3. Polygon 687 A polygon is defined as a set of points to form an enclosed bounded 688 shape. It is here that GML and the 3GPP shapes are most similar. 689 The representation for a polygon in GML is given first: 691 692 697 698 699 700 701 702 703 704 705 707 42.556844 -73.248157 708 42.549631 -73.237283 709 42.539087 -73.240328 710 42.535756 -73.254242 711 42.542969 -73.265115 712 42.553513 -73.262075 713 42.556844 -73.248157 714 715 716 717 718 719 720 721 722 723 724 2004-12-13T14:49:53+10:00 725 726 727 The GML object here is clear in its definition. A gml:LinearRing 728 MUST have a minimum of four points, with the first and last points 729 being the same. The 3GPP MLP representation for a polygon is 730 provided below. 732 733 734 735 736 737 738 739 42.556844 740 -73.248157 741 742 743 42.549631 744 -73.237283 745 746 747 42.539087 748 -73.240328 749 750 751 42.535756 752 -73.254242 753 754 755 42.542969 756 -73.265115 757 758 759 42.553513 760 -73.262075 761 762 763 42.556844 764 -73.248157 765 766 767 768 769 770 772 While these two representations are very similar and precise, they 773 are not widely used at present. If only a coverage area is required 774 without a nominal central point requiring specification, then this 775 form is ideal for representation using GML. 777 7. Baseline Geometry 779 PIDF-LO suggests to use GMLv3 feature.xsd, which provides a subset of 780 the available GML functionality. As a consequence a number of 781 further XML files are implicitly included, namely 782 geometryBasic0d1d.xsd, geometryBasic2d.xsd, temporal.xsd, 783 measure.xsd, units.xsd, gmlBase.xsd, dictionary.xsd, xLinks.xsd and 784 basicTypes.xsd, as being necessary to support. This provides for a 785 vast range of possibilities which would pose significant 786 complications to implementors wish to develop location dependent 787 routing applications. By agreeing to a minimal set of data 788 appropriate for routing, a minimum set of GML that MUST be 789 implemented by a given application type can also be set. This does 790 not preclude the additional functionality from being implemented, 791 merely that it may not be understood by some nodes. 793 7.1. Zero Dimensions 795 The minimum supported set of elements is position/Point/pos provided 796 by geometryBasic0d1d.xsd. 798 Thus a point location has only one representation as follows: 800 801 802 4.5 -36.2 803 804 806 The and objects MUST NOT be used since they are 807 deprecated in GML 3.1 and their functionality can be substituted with 808 the above-described elements. 810 Note that pos allows altitude to be expressed based on the selected 811 Coordinate Reference Systems (e.g., EPSG:4979 or EPSG:4326). Most 812 Coordinate Reference Systems use altitude above the geoid and not 813 altitude above the ground. 815 7.2. One Dimensions 817 Support for one dimensional shapes (such as the LineString or the 818 posList object)is not required except as a part of two dimensional 819 shapes. 821 geometryBasic0d1d.xsd provides these geometric properties and 822 objects. 824 7.3. Two Dimensions 826 The examples previously used were all contructed using elements from 827 this schema which reuse functionality from geometryBasic2d.xsd. As 828 was described earlier the arcband definition in GML is problematic 829 for producing a closed solid and SHOULD consequently be avoided. As 830 a result of this, elements required exclusively for representing the 831 arcband shape have not been included in the minimum supported element 832 set. The minimum element set is therefore restricted to circle and 833 polygon. 835 Circle: 837 extentOf/ 838 Polygon/ 839 exterior/ 840 Ring/ 841 curveMember/ 842 Curve/ 843 segments/ 844 CircleByCentrePoint/ -> Circle 845 pos 846 radius 848 Alternatively it would be possible to use the following structure to 849 express a circle using the element with three pos 850 elements as well. However, the usage of pos and radius, as shown 851 above, is inline with the model used by the 3GPP. 853 Polygon: 855 extentOf/ 856 Polygon/ 857 exterior/ 858 LinearRing/ 859 pos or posList -> Polygon 861 7.4. Three Dimensions 863 Support for three dimensions is not required 865 7.5. Envelopes 867 The Envelope element is a representation of a bounding box and can be 868 expressed in two or three dimensions. Defining a space using the 869 Envelope element should be done with extreme caution due to 870 continuity problems at the extremities of the CRS. In WGS-84, two 871 envelopes are required at the 180th meridian. The minimum set of 872 elements required to support an Envelope are: 874 boundBy/ 875 Envelope/ 876 upperCorner/ 877 Point/ 878 Pos 880 lowerCorner/ 881 Point/ 882 Pos/ 884 7.6. Temporal Dimensions 886 Support for temporal elements is not required 888 7.7. Units of Measure 890 The base SI units as a minimum MUST be supported. For measures of 891 distance this is metres. The EPSG URN for metres is: 893 metres = urn:ogc:def:uom:EPSG:9001:6.6 895 Angles are frequently expressed in terms of both degrees and radians, 896 consequently both MUST be implemented. 898 degrees = urn:ogc:def:uom:EPSG:9102:6.6 899 radians = urn:ogc:def:uom:EPSG:9101:6.6 901 Further units of measurement are not required. 903 7.8. Coordinate Reference System (CRS) 905 There are a very large number of coordinate reference systems in 906 existence today, but many are, however, not in widespread use. 907 Existing communications protocols such as those used in both the 908 ANSI, 3GPP and NENA standards (see [6], [7], [8]) have standardized 909 on WGS-84. It is recommended for routing purpose that only WGS-84 910 coordinate types MUST be implemented and further that this set be 911 restricted to the following: 913 WGS84(2D) = urn:ogc:def:crs:EPSG:6.6:4326 914 WGS84(3D) = urn:ogc:def:crs:EPSG:6.6:4979 916 8. Recommendations 918 As a summary this document gives a few recommendations on the usage 919 of location information in PIDF-LO. Nine rules specified in 920 Section 4 give guidelines on the ambiguity of PIDF-LO with regard to 921 the occurrence of multiple location information. It is recommend 922 that gml:position, gml:pos types be used to specify locations when 923 locations are needed for routing and specifically emergency routing. 924 Enhancements to GMLv3 feature.xsd may need to be defined to allow 925 complex shapes types to be specified in a way that makes them easy to 926 distinguish and validate. This is particularly important if the data 927 is to be used during the decision making process of routing signaling 928 messages. 930 Only a limited subset of GML functionality from the feature.xsd 931 schema is necessary to describe a geodetic location with sufficient 932 precision to allow a routing decision to be made. Restricting both 933 the amount of GML that MUST be implemented, and the number of 934 variations in which this data can be expressed significantly reduces 935 the likelihood of interoperability issues in the future. Precedents 936 exist in the other communications protocols for restricting CRS types 937 and representations for the sake of simplicity and interoperability, 938 and the recommendation is made to adopt similar restrictions for 939 mandatory implementable components of GeoPriv. 941 If Geodetic information is to be provided via DHCP, then a minimum 942 resolution of 20 bits SHOULD be specified for both the Latitude and 943 Longitude fields so that sub 100 metre precision is achieved. Where 944 only two dimensional objects are required polygons SHOULD be used to 945 express the enclosed area. Where 3 dimensions are required a 3 946 dimensional bounding box representing a rectangular prism SHOULD be 947 used with care taken around the 180th meridian. 949 9. Security Considerations 951 The primary security considerations relate to how location 952 information is conveyed and used, which are outside the scope of this 953 document. This document is intended to serve only as a set of 954 guidelines as to which elements MUST or SHOULD be implemented by 955 systems wishing to perform location dependent routing. The 956 ramification of such recommendations is that they extend to devices 957 and clients that wish to make use of such services. 959 10. IANA Considerations 961 This document does not introduce any IANA considerations. 963 11. Acknowledgments 965 The authors would like to thank the GEOPRIV working group for their 966 discussions in the context of PIDF-LO, in particular James Polk and 967 Henning Schulzrinne. Furthermore, we would like to thanks Jon 968 Peterson as the author of PIDF-LO and Nadine Abbott for her 969 constructive comments in clarifying some aspects of the document. 971 12. Open Issues 973 Need to get define minimal subset of Civic information that is useful 974 for routing purposes. May be hard to get normative, but hopefully we 975 can get something that is generally representative. 977 Need agreement on minimal set of shape support. 979 Need to go through the rules to enhance clarity. These rules are 980 highly likely to be important in quite a number of Location Dependent 981 Routing (LDR) based applications, including ECRIT. General feedback 982 is that they are not clear or precise enough yet. Henning has 983 provide some good feedback here that I have not had time to 984 incorporate yet, some of these comments will hopefully be easier to 985 resolve if open issue 1 above is also resoved. 987 13. References 989 13.1. Normative references 991 [1] Peterson, J., "A Presence-based GEOPRIV Location Object Format", 992 RFC 4119, December 2005. 994 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 995 Levels", March 1997. 997 13.2. Informative References 999 [3] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 1000 Configuration Protocol Option for Coordinate-based Location 1001 Configuration Information", RFC 3825, July 2004. 1003 [4] "Mobile Location Protocol (MLP), OMA, Candidate Version 3.1", 1004 March 2004. 1006 [5] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 1007 and DHCPv6) Option for Civic Addresses Configuration 1008 Information", draft-ietf-geopriv-dhcp-civil-09 (work in 1009 progress), January 2006. 1011 [6] "TR-45 J-STD-036-AD-2 Enhanced Wireless 9-1-1 Phase 2". 1013 [7] "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project; 1014 Technical Specification Group Code Network; Universal 1015 Geographic Area Description (GAD)". 1017 [8] "NENA Standard for the Implementation of the Wireless Emergency 1018 Service Protocol E2 Interface". 1020 [9] Schulzrinne, H., "A Document Format for Expressing Privacy 1021 Preferences", draft-ietf-geopriv-common-policy-06 (work in 1022 progress), October 2005. 1024 [10] Peterson, J., "A Presence Architecture for the Distribution of 1025 GEOPRIV Location Objects", draft-ietf-geopriv-pres-02 (work in 1026 progress), September 2004. 1028 Appendix A. Creating a PIDF-LO from DHCP Geo Encoded Data 1030 RFC-3825 [3] describes a means by which an end-point may learns it 1031 location from information encoded into DHCP option 123. The 1032 following section describes how and end-point can take this 1033 information and represent it in a well formed PIDF-LO describing this 1034 geodetic location. 1036 The location information described in RFC-3825 consists of a 1037 latitude, longitude, altitude and datum. 1039 A.1. Latitude and Longitude 1041 The latitude and longitude values are represented in degrees and 1042 decimal degrees. Latitude values are positive if north of the 1043 equator, and negative if south of the equator. Similarly 1044 longitudinal values are positive if east of the Greenwich meridian, 1045 and negative if west of the Greenwich meridian. 1047 The latitude and longitude values are each 34 bit long fields 1048 consisting of a 9 bit integer component and a 25 bit fraction 1049 component, with negative numbers being represented in 2s complement 1050 notation. The latitude and longitude fields are each proceeded by a 1051 6 bit resolution field, the LaRes for latitude, and the LoRes for 1052 longitude. The value in the LaRes field indicates the number of 1053 significant bits to interpret in the Latitude field, while the value 1054 in the LoRes field indicates the number of significant bits to 1055 interpret in the Longitude field. 1057 For example, if you are in Wollongong Australia which is located at 1058 34 Degrees 25 minutes South and 150 degrees 32 minutes East this 1059 would translate to -34.41667, 150.53333 in decimal degrees. If these 1060 numbers are translated to their full 34 bit representations, then we 1061 arrive the following: 1063 Latitude = 111011101.1001010101010101000111010 1065 Longitude = 0100101101000100010001000010100001 1067 RFC-3825, uses the LaRes and LoRes values to specify a lower and 1068 upper boundary for location thereby specifying an area. The size of 1069 the area specified is directly related to the value specified in the 1070 LaRes and LoRes fields. 1072 Using the previous example, if LaRes is set 7, then lower latitude 1073 boundary can be calculated as -256+128+64+16+8+4, which is -36 1074 degrees, the upper boundary then becomes -256+128+64+16+8+4+2+1 which 1075 is -35 degrees. LoRes may be used similarly for Longitude. 1077 So what level of precision is useful? Well, certain types of 1078 applications and regulations call for different levels of precision, 1079 and the required precision may vary depending on how the location was 1080 determined. For Cellular 911 calls in the United States, for 1081 example, if the network measures the location then the caller should 1082 be within 100 metres, while if the handset does the measurement then 1083 the location should be within 50 metres. Since DHCP is a network 1084 based mechanism we will benchmark off 100 metres (approximately 330 1085 ft) which is still a large area. 1087 For simplicity we shall assume that we are defining a square, in 1088 which we are equally to appear anywhere. The greatest distance 1089 through this square is across the diagonal, so we make this 100 1090 metres. 1092 +----------------------+ 1093 | _/| 1094 | _/ | 1095 | _/ | 1096 | _/ | 1097 | _/ | 1098 | 100_/ metres | 1099 | _/ | 1100 | _/ | 1101 | _/ | 1102 | _/ | 1103 |_/ | 1104 +----------------------+ 1106 The distance between the top and the bottom and the left and the 1107 right is the same, the area being a square, and this works out to be 1108 70.7 metres. When expressed in decimal degrees, the third point 1109 after the decimal place represents about 100 metre precision, this 1110 equates to 10 binary places of fractional part. A 70 metre distance 1111 is required, so 11 fractional binary digits are necessary resulting 1112 in a total of 20 bits of precision. 1114 With -34.4167, 150.5333 encoded with 20 bits of precision for the 1115 LaRes and LoRes, the corners of the enclosing square are: 1117 Point 1 (-34.4170, 150.5332) 1118 Point 2 (-34.4170, 150.5337) 1119 Point 3 (-34.4165, 150.5332) 1120 Point 4 (-34.4165, 150.5337) 1122 A.2. Altitude 1124 The altitude elements define how the altitude is encoded and to what 1125 level of precision. The units for altitude are either metres, or 1126 floors, with the actual measurement being encoded in a similar manner 1127 to those for latitude and longitude, but with 22 bit integer, and 8 1128 bit fractional components. 1130 A.3. Generating the PIDF-LO 1132 If altitude is not required, or is expressed in floors then a 1133 geodetic location expressed by a polygon SHOULD be used. If the 1134 altitude is expressed in floors and is required, the altitude SHOULD 1135 be expressed as a civic floor number as part of the same location- 1136 info element. In the example above the GML for the location would be 1137 expressed as follows: 1139 1140 1141 1142 1143 1145 -34.4165 150.5332 1146 -34.4165 150.5337 1147 -34.4170 150.5537 1148 -34.4170 150.5532 1149 -34.4165 150.5332 1150 1151 1152 1153 1154 1156 If a floor number of say 3 were included, then the location-info 1157 element would contain the above information and the following: 1159 1160 2 1161 1163 When altitude is expressed as an integer and fractional component, as 1164 with the latitude and longitude, it expresses a range, and this 1165 cannot be easily expressed in polygon form. Envelopes, as described 1166 earlier, define upper and lower bounds for rectangular enclosures, 1167 both in two and 3 dimensions, and SHOULD be used where an altitude 1168 range is specified. Care must be taken around the 180th meridian to 1169 ensure a misrepresentation does not occur should the 180th meridian 1170 be crossed. 1172 Extending the previous example to include an altitude expressed in 1173 metres rather than floors. AltRes is set to a value of 19, and the 1174 Altitude value is set to 34. Using similar techniques as shown in 1175 the latitude and longitude section, a range of altitudes between 32 1176 metres and 40 metres is described. The Envelope would therefore be 1177 defined as follows: 1179 1180 1181 1182 1183 -34.4165 150.5337 40 1184 1185 1186 1187 1188 -34.4170 150.5332 32 1189 1190 1191 1192 1194 The Method value SHOULD be set to DHCP. Note that this case, the 1195 DHCP is referring to the way in which location information was 1196 delivered to the IP-device, and not necessarily how the location was 1197 determined. 1199 The timestamp value SHOULD be set to the time that location was 1200 retrieved from the DHCP server. 1202 The client application MAY insert any usage rules that are pertinent 1203 to the user of the device and that comply with [9]. A guideline is 1204 that the any retention-expiry value SHOULD NOT exceed the current 1205 lease time. 1207 The Provided-By element SHOULD NOT be populated as this is not 1208 provided by the source of the location information. 1210 The 3 completed PIDF-LO representations are provided below, and 1211 represent a location without altitude, a location with a civic 1212 altitude, and a location represented as a 3 dimensional rectangular 1213 prism. 1215 1216 1221 1222 1223 1224 1225 1226 1227 1228 1229 1231 -34.4165 150.5332 1232 -34.4165 150.5337 1234 -34.4170 150.5537 1235 -34.4170 150.5532 1236 -34.4165 150.5332 1237 1238 1239 1240 1241 1242 1243 1244 1245 DHCP 1246 1247 1248 2005-07-05T14:49:53+10:00 1249 1250 1251 1252 1258 1259 1260 1261 1262 1263 1264 1265 1266 1268 -34.4165 150.5332 1269 -34.4165 150.5337 1270 -34.4170 150.5537 1271 -34.4170 150.5532 1272 -34.4165 150.5332 1273 1274 1275 1276 1277 1278 1279 2 1280 1281 1282 1283 1284 DHCP 1285 1286 1287 2005-07-05T14:49:53+10:00 1288 1289 1290 1291 1297 1298 1299 1300 1301 1302 1303 1304 1305 -34.4165 150.5337 40 1306 1307 1308 1309 1310 -34.4170 150.5332 32 1311 1312 1313 1314 1315 1316 1317 1318 DHCP 1319 1320 1321 2005-07-05T14:49:53+10:00 1322 1323 1325 Authors' Addresses 1327 James Winterbottom 1328 Andrew Corporation 1329 Wollongong 1330 NSW Australia 1332 Email: james.winterbottom@andrew.com 1334 Martin Thomson 1335 Andrew Corporation 1336 Wollongong 1337 NSW Australia 1339 Email: martin.thomson@andrew.com 1341 Hannes Tschofenig 1342 Siemens 1343 Otto-Hahn-Ring 6 1344 Munich, Bavaria 81739 1345 Germany 1347 Email: Hannes.Tschofenig@siemens.com 1349 Intellectual Property Statement 1351 The IETF takes no position regarding the validity or scope of any 1352 Intellectual Property Rights or other rights that might be claimed to 1353 pertain to the implementation or use of the technology described in 1354 this document or the extent to which any license under such rights 1355 might or might not be available; nor does it represent that it has 1356 made any independent effort to identify any such rights. Information 1357 on the procedures with respect to rights in RFC documents can be 1358 found in BCP 78 and BCP 79. 1360 Copies of IPR disclosures made to the IETF Secretariat and any 1361 assurances of licenses to be made available, or the result of an 1362 attempt made to obtain a general license or permission for the use of 1363 such proprietary rights by implementers or users of this 1364 specification can be obtained from the IETF on-line IPR repository at 1365 http://www.ietf.org/ipr. 1367 The IETF invites any interested party to bring to its attention any 1368 copyrights, patents or patent applications, or other proprietary 1369 rights that may cover technology that may be required to implement 1370 this standard. Please address the information to the IETF at 1371 ietf-ipr@ietf.org. 1373 Disclaimer of Validity 1375 This document and the information contained herein are provided on an 1376 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1377 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1378 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1379 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1380 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1381 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1383 Copyright Statement 1385 Copyright (C) The Internet Society (2006). This document is subject 1386 to the rights, licenses and restrictions contained in BCP 78, and 1387 except as set forth therein, the authors retain all their rights. 1389 Acknowledgment 1391 Funding for the RFC Editor function is currently provided by the 1392 Internet Society.