idnits 2.17.1 draft-winterbottom-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.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1048. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1025. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1032. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1038. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- ** There are 4 instances of lines with control characters in the document. ** 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 59: '... GML that MUST be implemented by app...' RFC 2119 keyword, line 147: '... A GeoPriv tuple MUST completely defin...' RFC 2119 keyword, line 150: '...tion description SHOULD reside in a se...' RFC 2119 keyword, line 153: '... document (PIDF) MUST only be done if ...' RFC 2119 keyword, line 157: '... 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 (February 14, 2005) is 7010 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-04 -- Obsolete informational reference (is this intentional?): RFC 3825 (ref. '6') (Obsoleted by RFC 6225) Summary: 8 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: August 18, 2005 Nortel 5 H. Tschofenig 6 Siemens 7 February 14, 2005 9 GEOPRIV PIDF-LO Usage Clarification, Considerations and 10 Recommendations 11 draft-winterbottom-geopriv-pdif-lo-profile-00.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 18, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 The GeoPriv PIDF-LO specification provides a flexible and versatile 47 means to represent location information. There are, however, 48 circumstances that arise when information needs to be constrained in 49 how it is represented so that the number of options that need to be 50 implemented in order to make use of it are reduced. There is growing 51 interest in being able to use location information contained in a 52 PIDF-LO for message and call routing applications. For such 53 applications to interoperate successfully location information will 54 need to be normative and more constrained than is currently described 55 in the PIDF-LO specification. This paper makes recommendations on 56 how to constrain, represent and interpret locations in a PIDF-LO. It 57 further looks at existing communications standards that make use of 58 geodetic information for routing purposes and recommends a subset of 59 GML that MUST be implemented by applications to allow message routing 60 to occur. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Using Location Information . . . . . . . . . . . . . . . . . 5 67 3.1 Single Civic Location Information . . . . . . . . . . . . 6 68 3.2 Civic and Geospatial Location Information . . . . . . . . 6 69 3.3 Manual/Automatic Configuration of Location Information . . 8 70 4. Geodetic Coordinate Representation . . . . . . . . . . . . . 9 71 5. Uncertainty in Location Representation . . . . . . . . . . . 11 72 5.1 Arc band . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 5.2 Ellipsoid Point With Uncertainty Circle . . . . . . . . . 15 74 5.3 Polygon . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 6. Baseline Geometry . . . . . . . . . . . . . . . . . . . . . 20 76 6.1 Zero Dimensions . . . . . . . . . . . . . . . . . . . . . 20 77 6.2 One Dimensions . . . . . . . . . . . . . . . . . . . . . . 20 78 6.3 Two Dimensions . . . . . . . . . . . . . . . . . . . . . . 21 79 6.4 Three Dimensions . . . . . . . . . . . . . . . . . . . . . 21 80 6.5 Envelopes . . . . . . . . . . . . . . . . . . . . . . . . 21 81 6.6 Temporal Dimensions . . . . . . . . . . . . . . . . . . . 22 82 6.7 Units of Measure . . . . . . . . . . . . . . . . . . . . . 22 83 6.8 Coordinate Reference System (CRS) . . . . . . . . . . . . 22 84 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . 23 85 8. Security Considerations . . . . . . . . . . . . . . . . . . 24 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25 87 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 26 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 89 11.1 Normative references . . . . . . . . . . . . . . . . . . 27 90 11.2 Informative References . . . . . . . . . . . . . . . . . 27 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27 92 Intellectual Property and Copyright Statements . . . . . . . 29 94 1. Introduction 96 PIDF-LO [1] which was developed by the GEOPRIV working group, is the 97 IETF recommended way encoding location information and privacy 98 policies. Location information in PIDF-LO may be described in a 99 geospatial manner based on a subset of GMLv3, or as civic location 100 information. PIDF-LO may be used in a variety of ways. For example, 101 [3] motivates the usage of PIDF-LO in presence based systems. 102 Further usages are envisioned in the context of emergency services 103 and other location based routing applications. This document details 104 the usage of GMLv3 in PIDF-LO by incorporating implementation 105 experience. Recommendations for formats and conventions are provided 106 where interoperability might be problematic. For the sake of 107 compatibility, ease of use and removal of inherent ambiguity apparent 108 in GML the functionality of other geospatial systems, such as the 109 3GPP MLP standard [4], are examined. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [2]. 117 3. Using Location Information 119 The PIDF format provides for an unbounded number of tuples. The 120 geopriv element resides inside the status component of a tuple, hence 121 a single PIDF document may contain an arbitrary number of location 122 objects some or all of which may be contradictory or complementary. 123 The actual location information is contained inside a 124 element, and there may be one or more actual locations described 125 inside the element. 127 Graphically, the structure of the PIDF/PIDF-LO can be depicted as 128 follows: 130 PIDF document 131 tuple 1 132 status 133 geopriv 134 location-info 135 civicAddress 136 location 137 usage-rules 138 tuple 2 139 tuple 3 141 All of these potential sources and storage places for location lead 142 to confusion for the generators, conveyors and users of location 143 information. Practical experience within the United States National 144 Emergency Number Association (NENA) in trying to solve these 145 ambiguities led the following conventions being adopted: 147 Rule #1: A GeoPriv tuple MUST completely define a specific location. 149 Rule #2: Where a location can be uniquely described in more than one 150 way, each location description SHOULD reside in a separate tuple. 152 Rule #3: Providing more than one location in a single presence 153 document (PIDF) MUST only be done if all objects describe the same 154 location. 156 Rule #4: Providing more than one location in a single 157 element SHOULD be avoided where possible. 159 Rule #5: When providing more than one location in a single 160 element they MUST be provided by a common source. 161 If you have more than one location in the element, 162 then the combination (complex of) these elements defines the 163 complete location. 165 Rule #6: Providing more than one location in a single 166 element SHOULD only be done if they form a complex to describe the 167 same location. For example, a geodetic location describing a 168 point, and a civic location indicating the floor in a building. 170 Rule #7: Where a location complex is provided in a single 171 element, the higher precision locations MUST be 172 provided first. For example, a geodetic location describing a 173 point, and a civic location indicating the floor MUST be 174 represented with the point first followed by the civic location. 176 Rule #8: Where a PIDF document contains more than one tuple 177 containing a status element with a geopriv location element , the 178 priority of tuples SHOULD be based on tuple position within the 179 PIDF document. That is to say, the tuple with the highest 180 priority location occurs earliest in the PIDF document. Initial 181 priority SHOULD be determined by the originating UA, the final 182 priority MAY be determined by a proxy along the way. 184 Rule #9: Where multiple PIDF documents are contained within a single 185 request, document selection SHOULD be based on document order. 187 The following examples illustrate the useful of these rules. 189 3.1 Single Civic Location Information 191 Jane is at a coffee shop on the ground floor of a large shopping 192 mall. Jane turns on her laptop and connects to the coffee-shop's 193 WiFi hotspot, Jane obtains a complete civic address for her current 194 location, for example using [5]. She constructs a Location Object 195 which consists of a single PIDF document, with a single geopriv 196 tuple, with a single location residing in the 197 element. This is largely unambiguous, and if this location is sent 198 over the network, providing it understands civic addresses, correct 199 handling of any request should be possible. 201 3.2 Civic and Geospatial Location Information 203 Mike is visiting his Seattle office and connects his laptop into the 204 Ethernet port in a spare cube. Mike's computer receives a location 205 over DHCP as defined in [6]. In this case the location is a geodetic 206 location, with the altitude represented as a building floor number. 207 This is constructed by Mike's computer into the following PIDF 208 document: 210 211 215 216 217 218 219 220 US 221 2 222 223 224 225 226 227 228 2003-06-22T20:57:29Z 229 230 231 232 233 234 235 236 37:46:30N 122:25:10W 237 238 239 240 241 242 243 244 2003-06-22T20:57:29Z 245 246 248 So the resulting PIDF document contains two geopriv elements each in 249 a separate PIDF tuple element, the first being a civic address made 250 up of only country and floor, the second containing the received 251 geodetic information. If the location is required for emergency 252 routing purposes, which information does a SIP proxy use? Applying 253 rule #8, we will likely fail, or at a minimum need to fall back to 254 the second tuple describing the geodetic location, a routing by the 255 second floor somewhere in the US is not particularly descriptive. If 256 rule #6 and #7 are applied, then the PIDF-LO document would look 257 like: 259 260 264 265 266 268 269 270 271 37:46:30N 122:25:10W 272 273 274 275 US 276 2 277 278 279 280 281 282 283 2003-06-22T20:57:29Z 284 285 287 It is now clear that the main location of user is a geodetic location 288 at latitude 37:46:30 North and longitude 122:25:10 West. Further 289 that the user is on the second floor of the building located at those 290 coordinates. 292 3.3 Manual/Automatic Configuration of Location Information 294 Erin has a predefined civic location stored in her laptop, since she 295 normally lives in Sydney, the address in her address is for her 296 Sydney-based apartment. Erin decides to visit sunny San Francisco, 297 and when she gets there she plugs in her laptop and makes a call. 298 The location sent to the local proxy is her Sydney address, her local 299 outbound SIP proxy inserts a new PIDF document asserting her new 300 location (or returns an error message with the current location 301 information). Using rule #9, the resulting PIDF order should be San 302 Francisco document first, followed by Sydney document. If the San 303 Francisco proxy were to add the location to Erin's existing PIDF 304 document, then the San Francisco tuple SHOULD be placed ahead of the 305 Sydney tuple following rule #8. 307 4. Geodetic Coordinate Representation 309 The geodetic examples provided previously were all based around the 310 gml:location element which uses the gml:coordinates elements (inside 311 the gml:Point element) and this representation has several drawbacks. 312 Firstly, it has been deprecated in later versions of GML (3.1 and 313 beyond) making it inadvisable to use for new applications. Secondly, 314 the format of the coordinates type is opaque and so can be difficult 315 to parse and interpret to ensure consistent results, as the same 316 geodetic location can be expressed in a variety of ways. An 317 alternative is to use the gml:position and gml:pos elements. These 318 elements have a structured format, in that each field is represented 319 as a double, and a single space exists between each field. Such a 320 format does not introduce the same degree of misinterpretation. A 321 suggested representation therefore for expressing geodetic 322 coordinates for emergency call routing would be: 324 325 326 37.775 -122.422 327 328 330 The coordinate reference system (CRS) indicates which numbers in the 331 sequence equate to latitude, longitude etc, and in addition to this 332 the CRS also provides an indication of direction represented by the 333 sign of the number. For example, in WGS-84 (represented as 334 CRS:4326), as shown in the code snippet above, the format is latitude 335 followed by longitude. A positive value for latitude represents a 336 location north of the equator while a negative value represents a 337 location south of the equator. Similarly for longitude, a positive 338 value represents a location east of Greenwich, while a negative value 339 represents a location west of Greenwich. 341 EPSG 4326 is the two dimensional WGS-84 representation, if we wanted 342 to represented this in three dimensions, that is with an altitude as 343 well, then we would use EPSG 4979 and the format would be as follows: 345 346 347 37.775 -122.422 22 348 349 351 The format using CRS:4979 is similar to CRS:4326, though we now have 352 an altitude value. Specifically the altitude is provided in metres 353 above the geoid, which will not be useful for general routing 354 applications since the geoid is generally neither ground-level nor 355 sea-level. However, for more specialized geographic applications it 356 may be useful. 358 Revisiting the final version of Section 3.2, but using gml:position 359 and gml:pos, has the following structure: 361 362 366 367 368 369 370 371 372 37.775 -122.422 373 374 375 376 US 377 2 378 379 380 381 382 383 384 2003-06-22T20:57:29Z 385 386 388 5. Uncertainty in Location Representation 390 The cellular mobile world today makes extensive use of geodetic based 391 location information for emergency and other location-based 392 applications. Generally these locations are expressed as a point 393 (either in two or three dimensions) and an area or volume of 394 uncertainty around the point. In theory, the area or volume 395 represents a coverage in which the user has a relatively high 396 probability of being found, and the point is a convenient means of 397 defining the centroid for the area or volume. In practice, most 398 systems today use the point as an absolute value and ignore the 399 uncertainty. It is difficult to determine if systems have been 400 implement in this manner for simplicity, and even more difficult to 401 predict if uncertainty will play a more important role in the future. 402 An important decision is whether an uncertainty area should be 403 specified. 405 There are six common ways to represent location and uncertainty, but 406 are listed below for completeness: 407 o Arc band 408 o Ellipsoid point with uncertainty circle 409 o Polygon 410 o Ellipsoid point with altitude 411 o Ellipsoid point with uncertainty ellipse 412 o Ellipsoid point with altitude and uncertainty ellipsoid 414 GML was designed to provide a very flexible abstraction on which 415 specific representations of geometric and geographic schemes could be 416 extended. Representing some of the above shapes is difficult if not 417 impossible using base GML. However, only a subset of GML, namely 418 feature.xsd, is mandatory for a PIDF-LO implementation. Extending 419 GML to easily represent these shapes may lead to interoperability 420 issues and so is not recommended. The authors of this document were 421 unable to find a means to express either an ellipse or and ellipsoid 422 using only the elements defined in feature.xsd. 424 The following sections describe four shapes that can be defined in 425 GML, and show the equivalent representation in 3GPP MLP [4]. 427 5.1 Arc band 429 Arc band is used primarily where timing advance (TA) information is 430 known. Timing advance is a mechanism used in wireless communications 431 to help ensure that handsets and base-stations remained synchronized. 432 Timing advance is stepped based on signal propagation and is fairly 433 deterministic, for GSM each increase in TA value represents 553.85 434 metres. 436 The arc band type was developed to represent the area between two 437 successive TA values and an antenna opening. This is presented in 438 3GPP as a point, two radii, and two angles representing the start and 439 the stop of the angles for the opening. 441 ,..__ 442 / `-. 443 / `-. 444 / `. 445 / \ 446 /__ \ 447 . `-. \ 448 start. `. \ 449 angle \ . 450 . | | 451 o ' | 452 . / ' 453 . / ; 454 stop . .,' / 455 angle `. / 456 `. / 457 `. ,' 458 `. ,' 459 `' 461 462 463 464 465 466 42.5463 467 -73.2512 468 469 1938.5 470 2492.3 471 63.7 472 118.4 473 474 475 477 The GML representation of this is below: 479 480 485 486 487 488 489 490 491 492 493 494 495 496 497 499 42.5463 -73.2512 500 501 502 2492.3 503 504 519 520 63.7 521 522 523 118.4 524 525 526 527 529 42.535651 -73.224473 42.538018 -73.230411 530 531 532 533 535 42.5463 -73.2512 536 537 543 544 1938.5 545 546 547 63.7 548 549 550 118.4 551 552 553 554 556 42.554016 -73.230007 42.556220 -73.223952 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 2004-12-01T09:28:43+10:00 572 573 575 This representation poses a few potential problems over the 3GPP 576 representation . In the 3GPP representation the point is absolute, 577 and everything else is defined relative to this point, ensuring that 578 the band is indeed bounded. The representation of arc band above 579 does not share all of these properties. In the GML arc band 580 representation above, the point and radii are relative, but the 581 bounding lines of the starting and finishing angles are not, these 582 are necessarily defined as independent line segments. By having to 583 define the arc enclosures as individual line segments it is possible 584 to define an unbounded arc band which would consist of two arcs some 585 arbitrary distance apart with two lines that may or may not intersect 586 them. 588 A second concern with this representing uncertainty using this 589 method, is that there is no explicit statement or way of indicating 590 to the receiving application what type of uncertainty is being 591 represented. Today several different representations of uncertainty 592 are valid with in the same application, so knowing which type is 593 being used, and how to interpret it is important, and this is 594 particularly true if the shape must also be validated as is the case 595 above. 597 Ensuring the legality of this shape type when represented in GML is 598 more complex than in MLP as the type must first be determined before 599 its validity can be assessed. Users of this shape type may be better 600 served by a formal shape definition being introduced into GeoPriv so 601 that these problems can be more readily overcome. 603 5.2 Ellipsoid Point With Uncertainty Circle 605 This shape type is used extensively over the North American NENA 606 defined E2 interface for transporting mobile geodetic location from 607 the MPC/GMLC to the ALI and subsequently the PSAPs. In 3GPP this is 608 defined as a WGS-84 point (ellipsoid point), and a radius or 609 uncertainty around that point, specified in metres. The 3GPP MLP 610 representation for an ellipsoid point with uncertainty is defined as 611 follows: 613 614 615 616 617 618 42.5463 619 -73.2512 620 621 850.24 622 623 625 627 This shape is similarly defined in GML below: 629 630 635 636 637 638 639 640 641 642 643 644 645 646 647 649 42.5463 -73.2512 650 651 652 850.24 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 2004-12-01T09:28:43+10:00 668 669 671 This type does not have all of the problems associated with the arc 672 band representation, in that the radius of the circle is relative to 673 the centre, and so the validation is unnecessary. However it does 674 suffer from the potential problem that the application still needs to 675 determine the type of uncertainty being represented, though this 676 maybe made more clear through the explicit use of the 677 gml:CircleByCenterPoint element. 679 5.3 Polygon 681 A polygon is defined as a set of points to form an enclosed bounded 682 shape. It is here that GML and the 3GPP shapes are most similar. 683 The representation for a polygon in GML is given first: 685 686 691 692 693 694 695 696 697 698 699 701 42.556844 -73.248157 702 42.549631 -73.237283 703 42.539087 -73.240328 704 42.535756 -73.254242 705 42.542969 -73.265115 706 42.553513 -73.262075 707 42.556844 -73.248157 708 709 710 711 712 713 714 715 716 717 718 2004-12-13T14:49:53+10:00 720 721 723 The GML object here is clear in its definition. A gml:LinearRing 724 MUST have a minimum of four points, with the first and last points 725 being the same. The 3GPP MLP representation for a polygon is 726 provided below. 728 729 730 731 732 733 734 735 42.556844 736 -73.248157 737 738 739 42.549631 740 -73.237283 741 742 743 42.539087 744 -73.240328 745 746 747 42.535756 748 -73.254242 749 750 751 42.542969 752 -73.265115 753 754 755 42.553513 756 -73.262075 757 758 759 42.556844 760 -73.248157 761 762 763 764 765 766 767 While these two representations are very similar and precise, they 768 are not widely used at present. If only a coverage area is required 769 without a nominal central point requiring specification, then this 770 form is ideal for representation using GML. 772 6. Baseline Geometry 774 PIDF-LO suggests to use GMLv3 feature.xsd, which provides a subset of 775 the available GML functionality. As a consequence a number of 776 further XML files are implicitly included, namely 777 geometryBasic0d1d.xsd, geometryBasic2d.xsd, temporal.xsd, 778 measure.xsd, units.xsd, gmlBase.xsd, dictionary.xsd, xLinks.xsd and 779 basicTypes.xsd, as being necessary to support. This provides for a 780 vast range of possibilities which would pose significant 781 complications to implementors wish to develop location dependent 782 routing applications. By agreeing to a minimal set of data 783 appropriate for routing, a minimum set of GML that MUST be 784 implemented by a given application type can also be set. This does 785 not preclude the additional functionality from being implemented, 786 merely that it may not be understood by some nodes. 788 6.1 Zero Dimensions 790 The minimum supported set of elements is position/Point/pos provided 791 by geometryBasic0d1d.xsd. 793 Thus a point location has only one representation as follows: 795 796 797 4.5 -36.2 798 799 801 The and objects MUST NOT be used since they are 802 deprecated in GML 3.1 and their functionality can be substituted with 803 the above-described elements. 805 Note that pos allows altitude to be expressed based on the selected 806 Coordinate Reference Systems (e.g., EPSG:4979 or EPSG:4326). Most 807 Coordinate Reference Systems use altitude above the geoid and not 808 altitude above the ground. 810 6.2 One Dimensions 812 Support for one dimensional shapes (such as the LineString or the 813 posList object) is not required except as a part of two dimensional 814 shapes. 816 geometryBasic0d1d.xsd provides these geometric properties and 817 objects. 819 6.3 Two Dimensions 821 The examples previously used were all contructed using elements from 822 this schema which reuse functionality from geometryBasic2d.xsd. As 823 was described earlier the arcband definition in GML is problematic 824 for producing a closed solid and SHOULD consequently be avoided. As 825 a result of this, elements required exclusively for representing the 826 arcband shape have not been included in the minimum supported element 827 set. The minimum element set is therefore restricted to circle and 828 polygon. 830 Circle: 832 extentOf/ 833 Polygon/ 834 exterior/ 835 Ring/ 836 curveMember/ 837 Curve/ 838 segments/ 839 CircleByCentrePoint/ -> Circle 840 pos 841 radius 843 Alternatively it would be possible to use the following structure to 844 express a circle using the element with three pos 845 elements as well. However, the usage of pos and radius, as shown 846 above, is inline with the model used by the 3GPP. 848 Polygon: 850 extentOf/ 851 Polygon/ 852 exterior/ 853 LinearRing/ 854 pos or posList -> Polygon 856 6.4 Three Dimensions 858 Support for three dimensions is not required 860 6.5 Envelopes 862 The Envelope element is a representation of a bounding box and can be 863 expressed in two or three dimensions. Defining a space using the 864 Envelope element should be done with extreme caution due to 865 continuity problems at the extremities of the CRS. In WGS-84, two 866 envelopes are required at the 180th meridian. The minimum set of 867 elements required to support an Envelope are: 869 boundBy/ 870 Envelope/ 871 upperCorner/ 872 Point/ 873 Pos 874 lowerCorner/ 875 Point/ 876 Pos/ 878 6.6 Temporal Dimensions 880 Support for temporal elements is not required 882 6.7 Units of Measure 884 The base SI units as a minimum MUST be supported. For measures of 885 distance this is metres. The EPSG URN for metres is: 887 metres = urn:ogc:def:uom:EPSG:9001:6.6 889 Angles are frequently expressed in terms of both degrees and radians, 890 consequently both MUST be implemented. 892 degrees = urn:ogc:def:uom:EPSG:9102:6.6 893 radians = urn:ogc:def:uom:EPSG:9101:6.6 895 Further units of measurement are not required. 897 6.8 Coordinate Reference System (CRS) 899 There are a very large number of coordinate reference systems in 900 existence today, but many are, however, not in widespread use. 901 Existing communications protocols such as those used in both the 902 ANSI, 3GPP and NENA standards (see [7], [8], [9]) have standardized 903 on WGS-84. It is recommended for routing purpose that only WGS-84 904 coordinate types MUST be implemented and further that this set be 905 resatricted to the following: 907 WGS84(2D) = urn:ogc:def:crs:EPSG:4326:6.6 908 WGS84(3D) = urn:ogc:def:crs:EPSG:4979:6.6 910 7. Recommendations 912 As a summary this document gives a few recommendations on the usage 913 of location information in PIDF-LO. Nine rules specified in 914 Section 3 give guidelines on the ambiguity of PIDF-LO with regard to 915 the occurrence of multiple location information. It is recommend 916 that gml:position, gml:pos types be used to specify locations when 917 locations are needed for routing and specifically emergency routing. 918 Enhancements to GMLv3 feature.xsd may need to be defined to allow 919 complex shapes types to be specified in a way that makes them easy to 920 distinguish and validate. This is particularly important if the data 921 is to be used during the decision making process of routing signaling 922 messages. 924 Only a limited subset of GML functionality from the feature.xsd 925 schema is necessary to describe a geodetic location with sufficient 926 precision to allow a routing decision to be made. Restricting both 927 the amount of GML that MUST be implemented, and the number of 928 variations in which this data can be expressed significantly reduces 929 the likelihood of interoperability issues in the future. Precedents 930 exist in the other communications protocols for restricting CRS types 931 and representations for the sake of simplicity and interoperability, 932 and the recommendation is made to adopt similar restrictions for 933 mandatory implementable components of GeoPriv. 935 8. Security Considerations 937 The primary security considerations relate to how location 938 information is conveyed and used, which are outside the scope of this 939 document. This document is intended to serve only as a set of 940 guidelines as to which elements MUST or SHOULD be implemented by 941 systems wishing to perform location dependent routing. The 942 ramification of such recommendations is that they extend to devices 943 and clients that wish to make use of such services. 945 9. IANA Considerations 947 This document does not introduce any IANA considerations. 949 10. Acknowledgments 951 The authors would like to thank the GEOPRIV working group for their 952 discussions in the context of PIDF-LO. Furthermore, we would like to 953 thanks Jon Peterson as the author of PIDF-LO and Nadine Abbott for 954 her constructive comments in clarifying some aspects of the document. 956 11. References 958 11.1 Normative references 960 [1] Peterson, J., "A Presence-based GEOPRIV Location Object Format", 961 Internet-Draft draft-ietf-geopriv-pidf-lo-03, September 2004. 963 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 964 Levels", March 1997. 966 11.2 Informative References 968 [3] Peterson, J., "A Presence Architecture for the Distribution of 969 GEOPRIV Location Objects", 970 Internet-Draft draft-ietf-geopriv-pres-02, September 2004. 972 [4] "Mobile Location Protocol (MLP), OMA, Candidate Version 3.1", 973 March 2004. 975 [5] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 976 and DHCPv6) Option for Civic Addresses Configuration 977 Information", Internet-Draft draft-ietf-geopriv-dhcp-civil-04, 978 October 2004. 980 [6] Polk, J., Schnizlein, J. and M. Linsner, "Dynamic Host 981 Configuration Protocol Option for Coordinate-based Location 982 Configuration Information", RFC 3825, July 2004. 984 [7] "TR-45 J-STD-036-AD-2 Enhanced Wireless 9-1-1 Phase 2". 986 [8] "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project; 987 Technical Specification Group Code Network; Universal Geographic 988 Area Description (GAD)". 990 [9] "NENA Standard for the Implementation of the Wireless Emergency 991 Service Protocol E2 Interface". 993 Authors' Addresses 995 James Winterbottom 996 Nortel 997 Wollongong 998 NSW Australia 1000 Email: winterb@nortel.com 1001 Martin Thomson 1002 Nortel 1003 Wollongong 1004 NSW Australia 1006 Email: martin.thomson@nortel.com 1008 Hannes Tschofenig 1009 Siemens 1010 Otto-Hahn-Ring 6 1011 Munich, Bavaria 81739 1012 Germany 1014 Email: Hannes.Tschofenig@siemens.com 1016 Intellectual Property Statement 1018 The IETF takes no position regarding the validity or scope of any 1019 Intellectual Property Rights or other rights that might be claimed to 1020 pertain to the implementation or use of the technology described in 1021 this document or the extent to which any license under such rights 1022 might or might not be available; nor does it represent that it has 1023 made any independent effort to identify any such rights. Information 1024 on the procedures with respect to rights in RFC documents can be 1025 found in BCP 78 and BCP 79. 1027 Copies of IPR disclosures made to the IETF Secretariat and any 1028 assurances of licenses to be made available, or the result of an 1029 attempt made to obtain a general license or permission for the use of 1030 such proprietary rights by implementers or users of this 1031 specification can be obtained from the IETF on-line IPR repository at 1032 http://www.ietf.org/ipr. 1034 The IETF invites any interested party to bring to its attention any 1035 copyrights, patents or patent applications, or other proprietary 1036 rights that may cover technology that may be required to implement 1037 this standard. Please address the information to the IETF at 1038 ietf-ipr@ietf.org. 1040 Disclaimer of Validity 1042 This document and the information contained herein are provided on an 1043 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1044 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1045 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1046 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1047 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1048 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1050 Copyright Statement 1052 Copyright (C) The Internet Society (2005). This document is subject 1053 to the rights, licenses and restrictions contained in BCP 78, and 1054 except as set forth therein, the authors retain all their rights. 1056 Acknowledgment 1058 Funding for the RFC Editor function is currently provided by the 1059 Internet Society.