idnits 2.17.1 draft-ietf-geopriv-pdif-lo-profile-00.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 1077. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1054. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1061. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1067. ** 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: '... GML that MUST be implemented by app...' RFC 2119 keyword, line 145: '... A GeoPriv tuple MUST completely defin...' RFC 2119 keyword, line 148: '...tion description SHOULD reside in a se...' RFC 2119 keyword, line 151: '... document (PIDF) MUST only be done if ...' RFC 2119 keyword, line 155: '... element SHOULD be avoided where ...' (18 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 2, 2005) is 6872 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) -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-09) exists of draft-ietf-geopriv-dhcp-civil-06 -- Obsolete informational reference (is this intentional?): RFC 3825 (ref. '6') (Obsoleted by RFC 6225) Summary: 5 errors (**), 0 flaws (~~), 3 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 3, 2006 Nortel 5 H. Tschofenig 6 Siemens 7 July 2, 2005 9 GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations 10 draft-ietf-geopriv-pdif-lo-profile-00.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 3, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 The GeoPriv PIDF-LO specification provides a flexible and versatile 44 means to represent location information. There are, however, 45 circumstances that arise when information needs to be constrained in 46 how it is represented so that the number of options that need to be 47 implemented in order to make use of it are reduced. There is growing 48 interest in being able to use location information contained in a 49 PIDF-LO for message and call routing applications. For such 50 applications to interoperate successfully location information will 51 need to be normative and more constrained than is currently described 52 in the PIDF-LO specification. This paper makes recommendations on 53 how to constrain, represent and interpret locations in a PIDF-LO. It 54 further looks at existing communications standards that make use of 55 geodetic information for routing purposes and recommends a subset of 56 GML that MUST be implemented by applications to allow message routing 57 to occur. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Using Location Information . . . . . . . . . . . . . . . . . 5 64 3.1 Single Civic Location Information . . . . . . . . . . . . 6 65 3.2 Civic and Geospatial Location Information . . . . . . . . 7 66 3.3 Manual/Automatic Configuration of Location Information . . 8 67 4. Geodetic Coordinate Representation . . . . . . . . . . . . . 10 68 5. Uncertainty in Location Representation . . . . . . . . . . . 12 69 5.1 Arc band . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 5.2 Ellipsoid Point With Uncertainty Circle . . . . . . . . . 16 71 5.3 Polygon . . . . . . . . . . . . . . . . . . . . . . . . . 19 72 6. Baseline Geometry . . . . . . . . . . . . . . . . . . . . . 21 73 6.1 Zero Dimensions . . . . . . . . . . . . . . . . . . . . . 21 74 6.2 One Dimensions . . . . . . . . . . . . . . . . . . . . . . 21 75 6.3 Two Dimensions . . . . . . . . . . . . . . . . . . . . . . 22 76 6.4 Three Dimensions . . . . . . . . . . . . . . . . . . . . . 22 77 6.5 Envelopes . . . . . . . . . . . . . . . . . . . . . . . . 22 78 6.6 Temporal Dimensions . . . . . . . . . . . . . . . . . . . 23 79 6.7 Units of Measure . . . . . . . . . . . . . . . . . . . . . 23 80 6.8 Coordinate Reference System (CRS) . . . . . . . . . . . . 23 81 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . 24 82 8. Security Considerations . . . . . . . . . . . . . . . . . . 25 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26 84 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 27 85 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 28 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 87 12.1 Normative references . . . . . . . . . . . . . . . . . . 29 88 12.2 Informative References . . . . . . . . . . . . . . . . . 29 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 90 Intellectual Property and Copyright Statements . . . . . . . 31 92 1. Introduction 94 PIDF-LO [1] which was developed by the GEOPRIV working group, is the 95 IETF recommended way encoding location information and privacy 96 policies. Location information in PIDF-LO may be described in a 97 geospatial manner based on a subset of GMLv3, or as civic location 98 information. PIDF-LO may be used in a variety of ways. For example, 99 [3] motivates the usage of PIDF-LO in presence based systems. 100 Further usages are envisioned in the context of emergency services 101 and other location based routing applications. This document details 102 the usage of GMLv3 in PIDF-LO by incorporating implementation 103 experience. Recommendations for formats and conventions are provided 104 where interoperability might be problematic. For the sake of 105 compatibility, ease of use and removal of inherent ambiguity apparent 106 in GML the functionality of other geospatial systems, such as the 107 3GPP MLP standard [4], are examined. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [2]. 115 3. Using Location Information 117 The PIDF format provides for an unbounded number of tuples. The 118 geopriv element resides inside the status component of a tuple, hence 119 a single PIDF document may contain an arbitrary number of location 120 objects some or all of which may be contradictory or complementary. 121 The actual location information is contained inside a 122 element, and there may be one or more actual locations described 123 inside the element. 125 Graphically, the structure of the PIDF/PIDF-LO can be depicted as 126 follows: 128 PIDF document 129 tuple 1 130 status 131 geopriv 132 location-info 133 civicAddress 134 location 135 usage-rules 136 tuple 2 137 tuple 3 139 All of these potential sources and storage places for location lead 140 to confusion for the generators, conveyors and users of location 141 information. Practical experience within the United States National 142 Emergency Number Association (NENA) in trying to solve these 143 ambiguities led the following conventions being adopted: 145 Rule #1: A GeoPriv tuple MUST completely define a specific location. 147 Rule #2: Where a location can be uniquely described in more than one 148 way, each location description SHOULD reside in a separate tuple. 150 Rule #3: Providing more than one location in a single presence 151 document (PIDF) MUST only be done if all objects describe the same 152 location. 154 Rule #4: Providing more than one location in a single 155 element SHOULD be avoided where possible. 157 Rule #5: When providing more than one location in a single element they MUST be provided by a common source. If you 159 have more than one location in the element, then 160 the combination (complex of) these elements defines the complete 161 location. 163 Rule #6: Providing more than one location in a single 164 element SHOULD only be done if they form a complex to describe the 165 same location. For example, a geodetic location describing a 166 point, and a civic location indicating the floor in a building. 168 Rule #7: Where a location complex is provided in a single element, the higher precision locations MUST be provided 170 first. For example, a geodetic location describing a point, and a 171 civic location indicating the floor MUST be represented with the 172 point first followed by the civic location. 174 Rule #8: Where a PIDF document contains more than one tuple 175 containing a status element with a geopriv location element , the 176 priority of tuples SHOULD be based on tuple position within the 177 PIDF document. That is to say, the tuple with the highest 178 priority location occurs earliest in the PIDF document. Initial 179 priority SHOULD be determined by the originating UA, the final 180 priority MAY be determined by a proxy along the way. 182 Rule #9: Where multiple PIDF documents are contained within a single 183 request, document selection SHOULD be based on document order. 185 The following examples illustrate the useful of these rules. 187 3.1 Single Civic Location Information 189 Jane is at a coffee shop on the ground floor of a large shopping 190 mall. Jane turns on her laptop and connects to the coffee-shop's 191 WiFi hotspot, Jane obtains a complete civic address for her current 192 location, for example using [5]. She constructs a Location Object 193 which consists of a single PIDF document, with a single geopriv 194 tuple, with a single location residing in the 195 element. This is largely unambiguous, and if this location is sent 196 over the network, providing it understands civic addresses, correct 197 handling of any request should be possible. 199 3.2 Civic and Geospatial Location Information 201 Mike is visiting his Seattle office and connects his laptop into the 202 Ethernet port in a spare cube. Mike's computer receives a location 203 over DHCP as defined in [6]. In this case the location is a geodetic 204 location, with the altitude represented as a building floor number. 205 This is constructed by Mike's computer into the following PIDF 206 document: 208 209 213 214 215 216 217 218 US 219 2 220 221 222 223 224 225 226 2003-06-22T20:57:29Z 227 228 229 230 231 232 233 234 37:46:30N 122:25:10W 235 236 237 238 239 240 241 242 2003-06-22T20:57:29Z 243 244 245 So the resulting PIDF document contains two geopriv elements each in 246 a separate PIDF tuple element, the first being a civic address made 247 up of only country and floor, the second containing the received 248 geodetic information. If the location is required for emergency 249 routing purposes, which information does a SIP proxy use? Applying 250 rule #8, we will likely fail, or at a minimum need to fall back to 251 the second tuple describing the geodetic location, a routing by the 252 second floor somewhere in the US is not particularly descriptive. If 253 rule #6 and #7 are applied, then the PIDF-LO document would look 254 like: 256 257 261 262 263 265 266 267 268 37:46:30N 122:25:10W 269 270 271 272 US 273 2 274 275 276 277 278 279 280 2003-06-22T20:57:29Z 281 282 284 It is now clear that the main location of user is a geodetic location 285 at latitude 37:46:30 North and longitude 122:25:10 West. Further 286 that the user is on the second floor of the building located at those 287 coordinates. 289 3.3 Manual/Automatic Configuration of Location Information 291 Erin has a predefined civic location stored in her laptop, since she 292 normally lives in Sydney, the address in her address is for her 293 Sydney-based apartment. Erin decides to visit sunny San Francisco, 294 and when she gets there she plugs in her laptop and makes a call. 295 The location sent to the local proxy is her Sydney address, her local 296 outbound SIP proxy inserts a new PIDF document asserting her new 297 location (or returns an error message with the current location 298 information). Using rule #9, the resulting PIDF order should be San 299 Francisco document first, followed by Sydney document. If the San 300 Francisco proxy were to add the location to Erin's existing PIDF 301 document, then the San Francisco tuple SHOULD be placed ahead of the 302 Sydney tuple following rule #8. 304 4. Geodetic Coordinate Representation 306 The geodetic examples provided previously were all based around the 307 gml:location element which uses the gml:coordinates elements (inside 308 the gml:Point element) and this representation has several drawbacks. 309 Firstly, it has been deprecated in later versions of GML (3.1 and 310 beyond) making it inadvisable to use for new applications. Secondly, 311 the format of the coordinates type is opaque and so can be difficult 312 to parse and interpret to ensure consistent results, as the same 313 geodetic location can be expressed in a variety of ways. An 314 alternative is to use the gml:position and gml:pos elements. These 315 elements have a structured format, in that each field is represented 316 as a double, and a single space exists between each field. Such a 317 format does not introduce the same degree of misinterpretation. A 318 suggested representation therefore for expressing geodetic 319 coordinates for emergency call routing would be: 321 322 323 37.775 -122.422 324 325 327 The coordinate reference system (CRS) indicates which numbers in the 328 sequence equate to latitude, longitude etc, and in addition to this 329 the CRS also provides an indication of direction represented by the 330 sign of the number. For example, in WGS-84 (represented as CRS: 331 4326), as shown in the code snippet above, the format is latitude 332 followed by longitude. A positive value for latitude represents a 333 location north of the equator while a negative value represents a 334 location south of the equator. Similarly for longitude, a positive 335 value represents a location east of Greenwich, while a negative value 336 represents a location west of Greenwich. 338 EPSG 4326 is the two dimensional WGS-84 representation, if we wanted 339 to represented this in three dimensions, that is with an altitude as 340 well, then we would use EPSG 4979 and the format would be as follows: 342 343 344 37.775 -122.422 22 345 346 348 The format using CRS:4979 is similar to CRS:4326, though we now have 349 an altitude value. Specifically the altitude is provided in metres 350 above the geoid, which will not be useful for general routing 351 applications since the geoid is generally neither ground-level nor 352 sea-level. However, for more specialized geographic applications it 353 may be useful. 355 Revisiting the final version of Section 3.2, but using gml:position 356 and gml:pos, has the following structure: 358 359 363 364 365 366 367 368 369 37.775 -122.422 370 371 372 373 US 374 2 375 376 377 378 379 380 381 2003-06-22T20:57:29Z 382 383 385 5. 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 5.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 529 530 532 42.535651 -73.224473 42.538018 -73.230411 533 534 535 536 538 42.5463 -73.2512 539 540 546 547 1938.5 548 549 550 63.7 551 552 553 118.4 554 555 556 557 559 42.554016 -73.230007 42.556220 -73.223952 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 2004-12-01T09:28:43+10:00 576 577 579 This representation poses a few potential problems over the 3GPP 580 representation . In the 3GPP representation the point is absolute, 581 and everything else is defined relative to this point, ensuring that 582 the band is indeed bounded. The representation of arc band above 583 does not share all of these properties. In the GML arc band 584 representation above, the point and radii are relative, but the 585 bounding lines of the starting and finishing angles are not, these 586 are necessarily defined as independent line segments. By having to 587 define the arc enclosures as individual line segments it is possible 588 to define an unbounded arc band which would consist of two arcs some 589 arbitrary distance apart with two lines that may or may not intersect 590 them. 592 A second concern with this representing uncertainty using this 593 method, is that there is no explicit statement or way of indicating 594 to the receiving application what type of uncertainty is being 595 represented. Today several different representations of uncertainty 596 are valid with in the same application, so knowing which type is 597 being used, and how to interpret it is important, and this is 598 particularly true if the shape must also be validated as is the case 599 above. 601 Ensuring the legality of this shape type when represented in GML is 602 more complex than in MLP as the type must first be determined before 603 its validity can be assessed. Users of this shape type may be better 604 served by a formal shape definition being introduced into GeoPriv so 605 that these problems can be more readily overcome. 607 5.2 Ellipsoid Point With Uncertainty Circle 609 This shape type is used extensively over the North American NENA 610 defined E2 interface for transporting mobile geodetic location from 611 the MPC/GMLC to the ALI and subsequently the PSAPs. In 3GPP this is 612 defined as a WGS-84 point (ellipsoid point), and a radius or 613 uncertainty around that point, specified in metres. The 3GPP MLP 614 representation for an ellipsoid point with uncertainty is defined as 615 follows: 617 618 619 620 621 622 42.5463 623 -73.2512 624 625 850.24 626 627 628 630 This shape is similarly defined in GML below: 632 633 638 639 640 641 642 643 644 645 646 647 648 649 650 652 42.5463 -73.2512 653 654 655 850.24 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 2004-12-01T09:28:43+10:00 671 672 674 This type does not have all of the problems associated with the arc 675 band representation, in that the radius of the circle is relative to 676 the centre, and so the validation is unnecessary. However it does 677 suffer from the potential problem that the application still needs to 678 determine the type of uncertainty being represented, though this 679 maybe made more clear through the explicit use of the gml: 681 CircleByCenterPoint element. 683 5.3 Polygon 685 A polygon is defined as a set of points to form an enclosed bounded 686 shape. It is here that GML and the 3GPP shapes are most similar. 687 The representation for a polygon in GML is given first: 689 690 695 696 697 698 699 700 701 702 703 705 42.556844 -73.248157 706 42.549631 -73.237283 707 42.539087 -73.240328 708 42.535756 -73.254242 709 42.542969 -73.265115 710 42.553513 -73.262075 711 42.556844 -73.248157 712 713 714 715 716 717 718 719 720 721 722 2004-12-13T14:49:53+10:00 723 724 726 The GML object here is clear in its definition. A gml:LinearRing 727 MUST have a minimum of four points, with the first and last points 728 being the same. The 3GPP MLP representation for a polygon is 729 provided below. 731 732 733 734 735 736 737 738 42.556844 739 -73.248157 740 741 742 42.549631 743 -73.237283 744 745 746 42.539087 747 -73.240328 748 749 750 42.535756 751 -73.254242 752 753 754 42.542969 755 -73.265115 756 757 758 42.553513 759 -73.262075 760 761 762 42.556844 763 -73.248157 764 765 766 767 768 769 771 While these two representations are very similar and precise, they 772 are not widely used at present. If only a coverage area is required 773 without a nominal central point requiring specification, then this 774 form is ideal for representation using GML. 776 6. Baseline Geometry 778 PIDF-LO suggests to use GMLv3 feature.xsd, which provides a subset of 779 the available GML functionality. As a consequence a number of 780 further XML files are implicitly included, namely 781 geometryBasic0d1d.xsd, geometryBasic2d.xsd, temporal.xsd, 782 measure.xsd, units.xsd, gmlBase.xsd, dictionary.xsd, xLinks.xsd and 783 basicTypes.xsd, as being necessary to support. This provides for a 784 vast range of possibilities which would pose significant 785 complications to implementors wish to develop location dependent 786 routing applications. By agreeing to a minimal set of data 787 appropriate for routing, a minimum set of GML that MUST be 788 implemented by a given application type can also be set. This does 789 not preclude the additional functionality from being implemented, 790 merely that it may not be understood by some nodes. 792 6.1 Zero Dimensions 794 The minimum supported set of elements is position/Point/pos provided 795 by geometryBasic0d1d.xsd. 797 Thus a point location has only one representation as follows: 799 800 801 4.5 -36.2 802 803 805 The and objects MUST NOT be used since they are 806 deprecated in GML 3.1 and their functionality can be substituted with 807 the above-described elements. 809 Note that pos allows altitude to be expressed based on the selected 810 Coordinate Reference Systems (e.g., EPSG:4979 or EPSG:4326). Most 811 Coordinate Reference Systems use altitude above the geoid and not 812 altitude above the ground. 814 6.2 One Dimensions 816 Support for one dimensional shapes (such as the LineString or the 817 posList object) is not required except as a part of two dimensional 818 shapes. 820 geometryBasic0d1d.xsd provides these geometric properties and 821 objects. 823 6.3 Two Dimensions 825 The examples previously used were all contructed using elements from 826 this schema which reuse functionality from geometryBasic2d.xsd. As 827 was described earlier the arcband definition in GML is problematic 828 for producing a closed solid and SHOULD consequently be avoided. As 829 a result of this, elements required exclusively for representing the 830 arcband shape have not been included in the minimum supported element 831 set. The minimum element set is therefore restricted to circle and 832 polygon. 834 Circle: 836 extentOf/ 837 Polygon/ 838 exterior/ 839 Ring/ 840 curveMember/ 841 Curve/ 842 segments/ 843 CircleByCentrePoint/ -> Circle 844 pos 845 radius 847 Alternatively it would be possible to use the following structure to 848 express a circle using the element with three pos 849 elements as well. However, the usage of pos and radius, as shown 850 above, is inline with the model used by the 3GPP. 852 Polygon: 854 extentOf/ 855 Polygon/ 856 exterior/ 857 LinearRing/ 858 pos or posList -> Polygon 860 6.4 Three Dimensions 862 Support for three dimensions is not required 864 6.5 Envelopes 866 The Envelope element is a representation of a bounding box and can be 867 expressed in two or three dimensions. Defining a space using the 868 Envelope element should be done with extreme caution due to 869 continuity problems at the extremities of the CRS. In WGS-84, two 870 envelopes are required at the 180th meridian. The minimum set of 871 elements required to support an Envelope are: 873 boundBy/ 874 Envelope/ 875 upperCorner/ 876 Point/ 877 Pos 878 lowerCorner/ 879 Point/ 880 Pos/ 882 6.6 Temporal Dimensions 884 Support for temporal elements is not required 886 6.7 Units of Measure 888 The base SI units as a minimum MUST be supported. For measures of 889 distance this is metres. The EPSG URN for metres is: 891 metres = urn:ogc:def:uom:EPSG:9001:6.6 893 Angles are frequently expressed in terms of both degrees and radians, 894 consequently both MUST be implemented. 896 degrees = urn:ogc:def:uom:EPSG:9102:6.6 897 radians = urn:ogc:def:uom:EPSG:9101:6.6 899 Further units of measurement are not required. 901 6.8 Coordinate Reference System (CRS) 903 There are a very large number of coordinate reference systems in 904 existence today, but many are, however, not in widespread use. 905 Existing communications protocols such as those used in both the 906 ANSI, 3GPP and NENA standards (see [7], [8], [9]) have standardized 907 on WGS-84. It is recommended for routing purpose that only WGS-84 908 coordinate types MUST be implemented and further that this set be 909 resatricted to the following: 911 WGS84(2D) = urn:ogc:def:crs:EPSG:4326:6.6 912 WGS84(3D) = urn:ogc:def:crs:EPSG:4979:6.6 914 7. Recommendations 916 As a summary this document gives a few recommendations on the usage 917 of location information in PIDF-LO. Nine rules specified in 918 Section 3 give guidelines on the ambiguity of PIDF-LO with regard to 919 the occurrence of multiple location information. It is recommend 920 that gml:position, gml:pos types be used to specify locations when 921 locations are needed for routing and specifically emergency routing. 922 Enhancements to GMLv3 feature.xsd may need to be defined to allow 923 complex shapes types to be specified in a way that makes them easy to 924 distinguish and validate. This is particularly important if the data 925 is to be used during the decision making process of routing signaling 926 messages. 928 Only a limited subset of GML functionality from the feature.xsd 929 schema is necessary to describe a geodetic location with sufficient 930 precision to allow a routing decision to be made. Restricting both 931 the amount of GML that MUST be implemented, and the number of 932 variations in which this data can be expressed significantly reduces 933 the likelihood of interoperability issues in the future. Precedents 934 exist in the other communications protocols for restricting CRS types 935 and representations for the sake of simplicity and interoperability, 936 and the recommendation is made to adopt similar restrictions for 937 mandatory implementable components of GeoPriv. 939 8. Security Considerations 941 The primary security considerations relate to how location 942 information is conveyed and used, which are outside the scope of this 943 document. This document is intended to serve only as a set of 944 guidelines as to which elements MUST or SHOULD be implemented by 945 systems wishing to perform location dependent routing. The 946 ramification of such recommendations is that they extend to devices 947 and clients that wish to make use of such services. 949 9. IANA Considerations 951 This document does not introduce any IANA considerations. 953 10. Acknowledgments 955 The authors would like to thank the GEOPRIV working group for their 956 discussions in the context of PIDF-LO. Furthermore, we would like to 957 thanks Jon Peterson as the author of PIDF-LO and Nadine Abbott for 958 her constructive comments in clarifying some aspects of the document. 960 11. Open Issues 962 A future version of this document will describe how geospatial 963 location information carried inside DHCP (see [6]) can be mapped to 964 GMLv3 elements. Three issues need to addressed with regard to this 965 mapping: 967 Coordinate Reference System (CRS): [6] specifies three CRSs, namely 968 datum = 1 seems to map to epsg:4327 (used as the srsName of the 969 gml:Point structure), datum = 2 and datum = 3 seem to point to the 970 same CRS (epsg:4269). 972 Geospatial Location Information: Location information as specified in 973 [6] might either specify a point or an area (based on the usage of 974 latitude resolution, longitude resolution and altitude 975 resolution). If the altitude attribute is not used then either a 976 Point or a Circle structure could be used. 978 Altitude: Altitude can be expressed in two ways: meters and floors. 979 While the mapping of meters from the location information carried 980 in DHCP to GML is easy. Expressing floors is more difficult and 981 might require the usage of civic together with geospatial elements 982 in PIDF-LO. 984 12. References 986 12.1 Normative references 988 [1] Peterson, J., "A Presence-based GEOPRIV Location Object Format", 989 draft-ietf-geopriv-pidf-lo-03 (work in progress), 990 September 2004. 992 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 993 Levels", March 1997. 995 12.2 Informative References 997 [3] Peterson, J., "A Presence Architecture for the Distribution of 998 GEOPRIV Location Objects", draft-ietf-geopriv-pres-02 (work in 999 progress), September 2004. 1001 [4] "Mobile Location Protocol (MLP), OMA, Candidate Version 3.1", 1002 March 2004. 1004 [5] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 1005 and DHCPv6) Option for Civic Addresses Configuration 1006 Information", draft-ietf-geopriv-dhcp-civil-06 (work in 1007 progress), May 2005. 1009 [6] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 1010 Configuration Protocol Option for Coordinate-based Location 1011 Configuration Information", RFC 3825, July 2004. 1013 [7] "TR-45 J-STD-036-AD-2 Enhanced Wireless 9-1-1 Phase 2". 1015 [8] "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project; 1016 Technical Specification Group Code Network; Universal Geographic 1017 Area Description (GAD)". 1019 [9] "NENA Standard for the Implementation of the Wireless Emergency 1020 Service Protocol E2 Interface". 1022 Authors' Addresses 1024 James Winterbottom 1025 Nortel 1026 Wollongong 1027 NSW Australia 1029 Email: winterb@nortel.com 1030 Martin Thomson 1031 Nortel 1032 Wollongong 1033 NSW Australia 1035 Email: martin.thomson@nortel.com 1037 Hannes Tschofenig 1038 Siemens 1039 Otto-Hahn-Ring 6 1040 Munich, Bavaria 81739 1041 Germany 1043 Email: Hannes.Tschofenig@siemens.com 1045 Intellectual Property Statement 1047 The IETF takes no position regarding the validity or scope of any 1048 Intellectual Property Rights or other rights that might be claimed to 1049 pertain to the implementation or use of the technology described in 1050 this document or the extent to which any license under such rights 1051 might or might not be available; nor does it represent that it has 1052 made any independent effort to identify any such rights. Information 1053 on the procedures with respect to rights in RFC documents can be 1054 found in BCP 78 and BCP 79. 1056 Copies of IPR disclosures made to the IETF Secretariat and any 1057 assurances of licenses to be made available, or the result of an 1058 attempt made to obtain a general license or permission for the use of 1059 such proprietary rights by implementers or users of this 1060 specification can be obtained from the IETF on-line IPR repository at 1061 http://www.ietf.org/ipr. 1063 The IETF invites any interested party to bring to its attention any 1064 copyrights, patents or patent applications, or other proprietary 1065 rights that may cover technology that may be required to implement 1066 this standard. Please address the information to the IETF at 1067 ietf-ipr@ietf.org. 1069 Disclaimer of Validity 1071 This document and the information contained herein are provided on an 1072 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1073 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1074 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1075 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1076 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1077 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1079 Copyright Statement 1081 Copyright (C) The Internet Society (2005). This document is subject 1082 to the rights, licenses and restrictions contained in BCP 78, and 1083 except as set forth therein, the authors retain all their rights. 1085 Acknowledgment 1087 Funding for the RFC Editor function is currently provided by the 1088 Internet Society.