idnits 2.17.1 draft-ietf-geopriv-pdif-lo-profile-01.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 1383. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1360. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1373. ** 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 (July 18, 2005) is 6850 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 1026, 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 (-09) exists of draft-ietf-geopriv-dhcp-civil-06 == Outdated reference: A later version (-11) exists of draft-ietf-geopriv-common-policy-04 Summary: 5 errors (**), 0 flaws (~~), 5 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: January 19, 2006 Nortel 5 H. Tschofenig 6 Siemens 7 July 18, 2005 9 GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations 10 draft-ietf-geopriv-pdif-lo-profile-01.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 January 19, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 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 . . . . . . . . . . . . . . . . . . . . . 23 76 7.1 Zero Dimensions . . . . . . . . . . . . . . . . . . . . . 23 77 7.2 One Dimensions . . . . . . . . . . . . . . . . . . . . . . 23 78 7.3 Two Dimensions . . . . . . . . . . . . . . . . . . . . . . 24 79 7.4 Three Dimensions . . . . . . . . . . . . . . . . . . . . . 24 80 7.5 Envelopes . . . . . . . . . . . . . . . . . . . . . . . . 24 81 7.6 Temporal Dimensions . . . . . . . . . . . . . . . . . . . 25 82 7.7 Units of Measure . . . . . . . . . . . . . . . . . . . . . 25 83 7.8 Coordinate Reference System (CRS) . . . . . . . . . . . . 25 84 8. Recommendations . . . . . . . . . . . . . . . . . . . . . . 27 85 9. Security Considerations . . . . . . . . . . . . . . . . . . 28 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 29 87 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 30 88 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 31 89 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 90 13.1 Normative references . . . . . . . . . . . . . . . . . . 32 91 13.2 Informative References . . . . . . . . . . . . . . . . . 32 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 33 93 A. Creating a PIDF-LO from DHCP Geo Encoded Data . . . . . . . 34 94 A.1 Latitude and Longitude . . . . . . . . . . . . . . . . . . 34 95 A.2 Altitude . . . . . . . . . . . . . . . . . . . . . . . . . 36 96 A.3 Generating the PIDF-LO . . . . . . . . . . . . . . . . . . 36 97 Intellectual Property and Copyright Statements . . . . . . . 41 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 224 the coffee-shop's WiFi hotspot, Jane obtains a complete civic address 225 for her current location, for example using [5]. She constructs a 226 Location Object which consists of a single PIDF document, with a 227 single geopriv tuple, with a single location residing in the 228 element. This is largely unambiguous, and if this 229 location is sent over the network, providing it understands civic 230 addresses, correct 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 478 479 The GML representation of this is below: 481 482 487 488 489 490 491 492 493 494 495 496 497 498 499 501 42.5463 -73.2512 502 503 504 2492.3 505 506 521 522 63.7 523 524 525 118.4 527 528 530 531 533 42.535651 -73.224473 42.538018 -73.230411 535 536 537 538 540 42.5463 -73.2512 541 542 548 549 1938.5 550 551 552 63.7 553 554 555 118.4 556 557 558 559 561 42.554016 -73.230007 42.556220 -73.223952 562 563 564 565 566 567 568 569 570 571 572 573 574 576 577 2004-12-01T09:28:43+10:00 578 579 581 This representation poses a few potential problems over the 3GPP 582 representation. In the 3GPP representation the point is absolute, 583 and everything else is defined relative to this point, ensuring that 584 the band is indeed bounded. The representation of arc band above 585 does not share all of these properties. In the GML arc band 586 representation above, the point and radii are relative, but the 587 bounding lines of the starting and finishing angles are not, these 588 are necessarily defined as independent line segments. By having to 589 define the arc enclosures as individual line segments it is possible 590 to define an unbounded arc band which would consist of two arcs some 591 arbitrary distance apart with two lines that may or may not intersect 592 them. 594 A second concern with this representing uncertainty using this 595 method, is that there is no explicit statement or way of indicating 596 to the receiving application what type of uncertainty is being 597 represented. Today several different representations of uncertainty 598 are valid with in the same application, so knowing which type is 599 being used, and how to interpret it is important, and this is 600 particularly true if the shape must also be validated as is the case 601 above. 603 Ensuring the legality of this shape type when represented in GML is 604 more complex than in MLP as the type must first be determined before 605 its validity can be assessed. Users of this shape type may be better 606 served by a formal shape definition being introduced into GeoPriv so 607 that these problems can be more readily overcome. 609 6.2 Ellipsoid Point With Uncertainty Circle 611 This shape type is used extensively over the North American NENA 612 defined E2 interface for transporting mobile geodetic location from 613 the MPC/GMLC to the ALI and subsequently the PSAPs. In 3GPP this is 614 defined as a WGS-84 point (ellipsoid point), and a radius or 615 uncertainty around that point, specified in metres. The 3GPP MLP 616 representation for an ellipsoid point with uncertainty is defined as 617 follows: 619 620 621 622 623 624 42.5463 625 -73.2512 626 627 850.24 628 629 630 632 This shape is similarly defined in GML below: 634 635 640 641 642 643 644 645 646 647 648 649 650 651 652 654 42.5463 -73.2512 655 656 657 850.24 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 2004-12-01T09:28:43+10:00 673 674 676 This type does not have all of the problems associated with the arc 677 band representation, in that the radius of the circle is relative to 678 the centre, and so the validation is unnecessary. However it does 679 suffer from the potential problem that the application still needs to 680 determine the type of uncertainty being represented, though this 681 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 728 The GML object here is clear in its definition. A gml:LinearRing 729 MUST have a minimum of four points, with the first and last points 730 being the same. The 3GPP MLP representation for a polygon is 731 provided below. 733 734 735 736 737 738 739 740 42.556844 741 -73.248157 742 743 744 42.549631 745 -73.237283 746 747 748 42.539087 749 -73.240328 750 751 752 42.535756 753 -73.254242 754 755 756 42.542969 757 -73.265115 758 759 760 42.553513 761 -73.262075 762 763 764 42.556844 765 -73.248157 766 767 768 769 770 771 773 While these two representations are very similar and precise, they 774 are not widely used at present. If only a coverage area is required 775 without a nominal central point requiring specification, then this 776 form is ideal for representation using GML. 778 7. Baseline Geometry 780 PIDF-LO suggests to use GMLv3 feature.xsd, which provides a subset of 781 the available GML functionality. As a consequence a number of 782 further XML files are implicitly included, namely 783 geometryBasic0d1d.xsd, geometryBasic2d.xsd, temporal.xsd, 784 measure.xsd, units.xsd, gmlBase.xsd, dictionary.xsd, xLinks.xsd and 785 basicTypes.xsd, as being necessary to support. This provides for a 786 vast range of possibilities which would pose significant 787 complications to implementors wish to develop location dependent 788 routing applications. By agreeing to a minimal set of data 789 appropriate for routing, a minimum set of GML that MUST be 790 implemented by a given application type can also be set. This does 791 not preclude the additional functionality from being implemented, 792 merely that it may not be understood by some nodes. 794 7.1 Zero Dimensions 796 The minimum supported set of elements is position/Point/pos provided 797 by geometryBasic0d1d.xsd. 799 Thus a point location has only one representation as follows: 801 802 803 4.5 -36.2 804 805 807 The and objects MUST NOT be used since they are 808 deprecated in GML 3.1 and their functionality can be substituted with 809 the above-described elements. 811 Note that pos allows altitude to be expressed based on the selected 812 Coordinate Reference Systems (e.g., EPSG:4979 or EPSG:4326). Most 813 Coordinate Reference Systems use altitude above the geoid and not 814 altitude above the ground. 816 7.2 One Dimensions 818 Support for one dimensional shapes (such as the LineString or the 819 posList object)is not required except as a part of two dimensional 820 shapes. 822 geometryBasic0d1d.xsd provides these geometric properties and 823 objects. 825 7.3 Two Dimensions 827 The examples previously used were all contructed using elements from 828 this schema which reuse functionality from geometryBasic2d.xsd. As 829 was described earlier the arcband definition in GML is problematic 830 for producing a closed solid and SHOULD consequently be avoided. As 831 a result of this, elements required exclusively for representing the 832 arcband shape have not been included in the minimum supported element 833 set. The minimum element set is therefore restricted to circle and 834 polygon. 836 Circle: 838 extentOf/ 839 Polygon/ 840 exterior/ 841 Ring/ 842 curveMember/ 843 Curve/ 844 segments/ 845 CircleByCentrePoint/ -> Circle 846 pos 847 radius 849 Alternatively it would be possible to use the following structure to 850 express a circle using the element with three pos 851 elements as well. However, the usage of pos and radius, as shown 852 above, is inline with the model used by the 3GPP. 854 Polygon: 856 extentOf/ 857 Polygon/ 858 exterior/ 859 LinearRing/ 860 pos or posList -> Polygon 862 7.4 Three Dimensions 864 Support for three dimensions is not required 866 7.5 Envelopes 868 The Envelope element is a representation of a bounding box and can be 869 expressed in two or three dimensions. Defining a space using the 870 Envelope element should be done with extreme caution due to 871 continuity problems at the extremities of the CRS. In WGS-84, two 872 envelopes are required at the 180th meridian. The minimum set of 873 elements required to support an Envelope are: 875 boundBy/ 876 Envelope/ 877 upperCorner/ 878 Point/ 879 Pos 881 lowerCorner/ 882 Point/ 883 Pos/ 885 7.6 Temporal Dimensions 887 Support for temporal elements is not required 889 7.7 Units of Measure 891 The base SI units as a minimum MUST be supported. For measures of 892 distance this is metres. The EPSG URN for metres is: 894 metres = urn:ogc:def:uom:EPSG:9001:6.6 896 Angles are frequently expressed in terms of both degrees and radians, 897 consequently both MUST be implemented. 899 degrees = urn:ogc:def:uom:EPSG:9102:6.6 900 radians = urn:ogc:def:uom:EPSG:9101:6.6 902 Further units of measurement are not required. 904 7.8 Coordinate Reference System (CRS) 906 There are a very large number of coordinate reference systems in 907 existence today, but many are, however, not in widespread use. 908 Existing communications protocols such as those used in both the 909 ANSI, 3GPP and NENA standards (see [6], [7], [8]) have standardized 910 on WGS-84. It is recommended for routing purpose that only WGS-84 911 coordinate types MUST be implemented and further that this set be 912 restricted to the following: 914 WGS84(2D) = urn:ogc:def:crs:EPSG:6.6:4326 915 WGS84(3D) = urn:ogc:def:crs:EPSG:6.6:4979 917 8. Recommendations 919 As a summary this document gives a few recommendations on the usage 920 of location information in PIDF-LO. Nine rules specified in 921 Section 4 give guidelines on the ambiguity of PIDF-LO with regard to 922 the occurrence of multiple location information. It is recommend 923 that gml:position, gml:pos types be used to specify locations when 924 locations are needed for routing and specifically emergency routing. 925 Enhancements to GMLv3 feature.xsd may need to be defined to allow 926 complex shapes types to be specified in a way that makes them easy to 927 distinguish and validate. This is particularly important if the data 928 is to be used during the decision making process of routing signaling 929 messages. 931 Only a limited subset of GML functionality from the feature.xsd 932 schema is necessary to describe a geodetic location with sufficient 933 precision to allow a routing decision to be made. Restricting both 934 the amount of GML that MUST be implemented, and the number of 935 variations in which this data can be expressed significantly reduces 936 the likelihood of interoperability issues in the future. Precedents 937 exist in the other communications protocols for restricting CRS types 938 and representations for the sake of simplicity and interoperability, 939 and the recommendation is made to adopt similar restrictions for 940 mandatory implementable components of GeoPriv. 942 If Geodetic information is to be provided via DHCP, then a minimum 943 resolution of 20 bits SHOULD be specified for both the Latitude and 944 Longitude fields so that sub 100 metre precision is achieved. Where 945 only two dimensional objects are required polygons SHOULD be used to 946 express the enclosed area. Where 3 dimensions are required a 3 947 dimensional bounding box representing a rectangular prism SHOULD be 948 used with care taken around the 180th meridian. 950 9. Security Considerations 952 The primary security considerations relate to how location 953 information is conveyed and used, which are outside the scope of this 954 document. This document is intended to serve only as a set of 955 guidelines as to which elements MUST or SHOULD be implemented by 956 systems wishing to perform location dependent routing. The 957 ramification of such recommendations is that they extend to devices 958 and clients that wish to make use of such services. 960 10. IANA Considerations 962 This document does not introduce any IANA considerations. 964 11. Acknowledgments 966 The authors would like to thank the GEOPRIV working group for their 967 discussions in the context of PIDF-LO, in particular James Polk and 968 Henning Schulzrinne. Furthermore, we would like to thanks Jon 969 Peterson as the author of PIDF-LO and Nadine Abbott for her 970 constructive comments in clarifying some aspects of the document. 972 12. Open Issues 974 Need to get define minimal subset of Civic information that is useful 975 for routing purposes. May be hard to get normative, but hopefully we 976 can get something that is generally representative. 978 Need agreement on minimal set of shape support. 980 Need to go through the rules to enhance clarity. These rules are 981 highly likely to be important in quite a number of Location Dependent 982 Routing (LDR) based applications, including ECRIT. General feedback 983 is that they are not clear or precise enough yet. Henning has 984 provide some good feedback here that I have not had time to 985 incorporate yet, some of these comments will hopefully be easier to 986 resolve if open issue 1 above is also resoved. 988 13. References 990 13.1 Normative references 992 [1] Peterson, J., "A Presence-based GEOPRIV Location Object Format", 993 draft-ietf-geopriv-pidf-lo-03 (work in progress), 994 September 2004. 996 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 997 Levels", March 1997. 999 13.2 Informative References 1001 [3] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 1002 Configuration Protocol Option for Coordinate-based Location 1003 Configuration Information", RFC 3825, July 2004. 1005 [4] "Mobile Location Protocol (MLP), OMA, Candidate Version 3.1", 1006 March 2004. 1008 [5] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 1009 and DHCPv6) Option for Civic Addresses Configuration 1010 Information", draft-ietf-geopriv-dhcp-civil-06 (work in 1011 progress), May 2005. 1013 [6] "TR-45 J-STD-036-AD-2 Enhanced Wireless 9-1-1 Phase 2". 1015 [7] "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project; 1016 Technical Specification Group Code Network; Universal 1017 Geographic Area Description (GAD)". 1019 [8] "NENA Standard for the Implementation of the Wireless Emergency 1020 Service Protocol E2 Interface". 1022 [9] Schulzrinne, H., "A Document Format for Expressing Privacy 1023 Preferences", draft-ietf-geopriv-common-policy-04 (work in 1024 progress), February 2005. 1026 [10] Peterson, J., "A Presence Architecture for the Distribution of 1027 GEOPRIV Location Objects", draft-ietf-geopriv-pres-02 (work in 1028 progress), September 2004. 1030 Authors' Addresses 1032 James Winterbottom 1033 Nortel 1034 Wollongong 1035 NSW Australia 1037 Email: winterb@nortel.com 1039 Martin Thomson 1040 Nortel 1041 Wollongong 1042 NSW Australia 1044 Email: martin.thomson@nortel.com 1046 Hannes Tschofenig 1047 Siemens 1048 Otto-Hahn-Ring 6 1049 Munich, Bavaria 81739 1050 Germany 1052 Email: Hannes.Tschofenig@siemens.com 1054 Appendix A. Creating a PIDF-LO from DHCP Geo Encoded Data 1056 RFC-3825 [3] describes a means by which an end-point may learns it 1057 location from information encoded into DHCP option 123. The 1058 following section describes how and end-point can take this 1059 information and represent it in a well formed PIDF-LO describing this 1060 geodetic location. 1062 The location information described in RFC-3825 consists of a 1063 latitude, longitude, altitude and datum. 1065 A.1 Latitude and Longitude 1067 The latitude and longitude values are represented in degrees and 1068 decimal degrees. Latitude values are positive if north of the 1069 equator, and negative if south of the equator. Similarly 1070 longitudinal values are positive if east of the Greenwich meridian, 1071 and negative if west of the Greenwich meridian. 1073 The latitude and longitude values are each 34 bit long fields 1074 consisting of a 9 bit integer component and a 25 bit fraction 1075 component, with negative numbers being represented in 2s complement 1076 notation. The latitude and longitude fields are each proceeded by a 1077 6 bit resolution field, the LaRes for latitude, and the LoRes for 1078 longitude. The value in the LaRes field indicates the number of 1079 significant bits to interpret in the Latitude field, while the value 1080 in the LoRes field indicates the number of significant bits to 1081 interpret in the Longitude field. 1083 For example, if you are in Wollongong Australia which is located at 1084 34 Degrees 25 minutes South and 150 degrees 32 minutes East this 1085 would translate to -34.41667, 150.53333 in decimal degrees. If these 1086 numbers are translated to their full 34 bit representations, then we 1087 arrive the following: 1089 Latitude = 111011101.1001010101010101000111010 1091 Longitude = 0100101101000100010001000010100001 1093 RFC-3825, uses the LaRes and LoRes values to specify a lower and 1094 upper boundary for location thereby specifying an area. The size of 1095 the area specified is directly related to the value specified in the 1096 LaRes and LoRes fields. 1098 Using the previous example, if LaRes is set 7, then lower latitude 1099 boundary can be calculated as -256+128+64+16+8+4, which is -36 1100 degrees, the upper boundary then becomes -256+128+64+16+8+4+2+1 which 1101 is -35 degrees. LoRes may be used similarly for Longitude. 1103 So what level of precision is useful? Well, certain types of 1104 applications and regulations call for different levels of precision, 1105 and the required precision may vary depending on how the location was 1106 determined. For Cellular 911 calls in the United States, for 1107 example, if the network measures the location then the caller should 1108 be within 100 metres, while if the handset does the measurement then 1109 the location should be within 50 metres. Since DHCP is a network 1110 based mechanism we will benchmark off 100 metres (approximately 330 1111 ft) which is still a large area. 1113 For simplicity we shall assume that we are defining a square, in 1114 which we are equally to appear anywhere. The greatest distance 1115 through this square is across the diagonal, so we make this 100 1116 metres. 1118 +----------------------+ 1119 | _/| 1120 | _/ | 1121 | _/ | 1122 | _/ | 1123 | _/ | 1124 | 100_/ metres | 1125 | _/ | 1126 | _/ | 1127 | _/ | 1128 | _/ | 1129 |_/ | 1130 +----------------------+ 1132 The distance between the top and the bottom and the left and the 1133 right is the same, the area being a square, and this works out to be 1134 70.7 metres. When expressed in decimal degrees, the third point 1135 after the decimal place represents about 100 metre precision, this 1136 equates to 10 binary places of fractional part. A 70 metre distance 1137 is required, so 11 fractional binary digits are necessary resulting 1138 in a total of 20 bits of precision. 1140 With -34.4167, 150.5333 encoded with 20 bits of precision for the 1141 LaRes and LoRes, the corners of the enclosing square are: 1143 Point 1 (-34.4170, 150.5332) 1144 Point 2 (-34.4170, 150.5337) 1145 Point 3 (-34.4165, 150.5332) 1146 Point 4 (-34.4165, 150.5337) 1148 A.2 Altitude 1150 The altitude elements define how the altitude is encoded and to what 1151 level of precision. The units for altitude are either metres, or 1152 floors, with the actual measurement being encoded in a similar manner 1153 to those for latitude and longitude, but with 22 bit integer, and 8 1154 bit fractional components. 1156 A.3 Generating the PIDF-LO 1158 If altitude is not required, or is expressed in floors then a 1159 geodetic location expressed by a polygon SHOULD be used. If the 1160 altitude is expressed in floors and is required, the altitude SHOULD 1161 be expressed as a civic floor number as part of the same location- 1162 info element. In the example above the GML for the location would be 1163 expressed as follows: 1165 1166 1167 1168 1169 1171 -34.4165 150.5332 1172 -34.4165 150.5337 1173 -34.4170 150.5537 1174 -34.4170 150.5532 1175 -34.4165 150.5332 1176 1177 1178 1179 1180 1182 If a floor number of say 3 were included, then the location-info 1183 element would contain the above information and the following: 1185 1186 2 1187 1189 When altitude is expressed as an integer and fractional component, as 1190 with the latitude and longitude, it expresses a range, and this 1191 cannot be easily expressed in polygon form. Envelopes, as described 1192 earlier, define upper and lower bounds for rectangular enclosures, 1193 both in two and 3 dimensions, and SHOULD be used where an altitude 1194 range is specified. Care must be taken around the 180th meridian to 1195 ensure a misrepresentation does not occur should the 180th meridian 1196 be crossed. 1198 Extending the previous example to include an altitude expressed in 1199 metres rather than floors. AltRes is set to a value of 19, and the 1200 Altitude value is set to 34. Using similar techniques as shown in 1201 the latitude and longitude section, a range of altitudes between 32 1202 metres and 40 metres is described. The Envelope would therefore be 1203 defined as follows: 1205 1206 1207 1208 1209 -34.4165 150.5337 40 1210 1211 1212 1213 1214 -34.4170 150.5332 32 1215 1216 1217 1218 1220 The Method value SHOULD be set to DHCP. Note that this case, the 1221 DHCP is referring to the way in which location information was 1222 delivered to the IP-device, and not necessarily how the location was 1223 determined. 1225 The timestamp value SHOULD be set to the time that location was 1226 retrieved from the DHCP server. 1228 The client application MAY insert any usage rules that are pertinent 1229 to the user of the device and that comply with [9]. A guideline is 1230 that the any retention-expiry value SHOULD NOT exceed the current 1231 lease time. 1233 The Provided-By element SHOULD NOT be populated as this is not 1234 provided by the source of the location information. 1236 The 3 completed PIDF-LO representations are provided below, and 1237 represent a location without altitude, a location with a civic 1238 altitude, and a location represented as a 3 dimensional rectangular 1239 prism. 1241 1242 1247 1248 1249 1250 1251 1252 1253 1254 1255 1257 -34.4165 150.5332 1258 -34.4165 150.5337 1260 -34.4170 150.5537 1261 -34.4170 150.5532 1262 -34.4165 150.5332 1263 1264 1265 1266 1267 1268 1269 1270 1271 DHCP 1272 1273 1274 2005-07-05T14:49:53+10:00 1275 1276 1277 1278 1284 1285 1286 1287 1288 1289 1290 1291 1292 1294 -34.4165 150.5332 1295 -34.4165 150.5337 1296 -34.4170 150.5537 1297 -34.4170 150.5532 1298 -34.4165 150.5332 1299 1300 1301 1302 1303 1304 1305 2 1306 1307 1308 1309 1310 DHCP 1311 1312 1313 2005-07-05T14:49:53+10:00 1314 1315 1316 1317 1323 1324 1325 1326 1327 1328 1329 1330 1331 -34.4165 150.5337 40 1332 1333 1334 1335 1336 -34.4170 150.5332 32 1337 1338 1339 1340 1341 1342 1343 1344 DHCP 1345 1346 1347 2005-07-05T14:49:53+10:00 1348 1349 1351 Intellectual Property Statement 1353 The IETF takes no position regarding the validity or scope of any 1354 Intellectual Property Rights or other rights that might be claimed to 1355 pertain to the implementation or use of the technology described in 1356 this document or the extent to which any license under such rights 1357 might or might not be available; nor does it represent that it has 1358 made any independent effort to identify any such rights. Information 1359 on the procedures with respect to rights in RFC documents can be 1360 found in BCP 78 and BCP 79. 1362 Copies of IPR disclosures made to the IETF Secretariat and any 1363 assurances of licenses to be made available, or the result of an 1364 attempt made to obtain a general license or permission for the use of 1365 such proprietary rights by implementers or users of this 1366 specification can be obtained from the IETF on-line IPR repository at 1367 http://www.ietf.org/ipr. 1369 The IETF invites any interested party to bring to its attention any 1370 copyrights, patents or patent applications, or other proprietary 1371 rights that may cover technology that may be required to implement 1372 this standard. Please address the information to the IETF at 1373 ietf-ipr@ietf.org. 1375 Disclaimer of Validity 1377 This document and the information contained herein are provided on an 1378 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1379 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1380 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1381 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1382 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1383 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1385 Copyright Statement 1387 Copyright (C) The Internet Society (2005). This document is subject 1388 to the rights, licenses and restrictions contained in BCP 78, and 1389 except as set forth therein, the authors retain all their rights. 1391 Acknowledgment 1393 Funding for the RFC Editor function is currently provided by the 1394 Internet Society.