idnits 2.17.00 (12 Aug 2021) /tmp/idnits12247/draft-ietf-geopriv-pdif-lo-profile-14.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, updated by RFC 4748 on line 1136. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1147. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1154. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1160. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4119, but the abstract doesn't seem to directly say this. It does mention RFC4119 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC4119, updated by this document, for RFC5378 checks: 2004-01-14) -- 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 (November 25, 2008) is 4918 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. 'GeoShape' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 Updates: 4119 (if approved) Andrew Corporation 5 Intended status: Standards Track H. Tschofenig 6 Expires: May 29, 2009 Nokia Siemens Networks 7 November 25, 2008 9 GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations 10 draft-ietf-geopriv-pdif-lo-profile-14 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 May 29, 2009. 37 Abstract 39 The Presence Information Data Format Location Object (PIDF-LO) 40 specification provides a flexible and versatile means to represent 41 location information. There are, however, circumstances that arise 42 when information needs to be constrained in how it is represented. 43 In these circumstances the range of options that need to be 44 implemented are reduced. There is growing interest in being able to 45 use location information contained in a PIDF-LO for routing 46 applications. To allow successful interoperability between 47 applications, location information needs to be normative and more 48 tightly constrained than is currently specified in the RFC 4119 49 (PIDF-LO). This document makes recommendations on how to constrain, 50 represent and interpret locations in a PIDF-LO. This further 51 recommends a subset of Geography Markup Language (GML) 3.1.1 that is 52 mandatory to implement by applications involved in location based 53 routing. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Using Location Information . . . . . . . . . . . . . . . . . . 6 60 3.1. Single Civic Location Information . . . . . . . . . . . . 9 61 3.2. Civic and Geospatial Location Information . . . . . . . . 9 62 3.3. Manual/Automatic Configuration of Location Information . . 10 63 3.4. Multiple Location Objects in a Single PIDF-LO . . . . . . 11 64 4. Geodetic Coordinate Representation . . . . . . . . . . . . . . 13 65 5. Geodetic Shape Representation . . . . . . . . . . . . . . . . 14 66 5.1. Polygon Restrictions . . . . . . . . . . . . . . . . . . . 15 67 5.2. Shape Examples . . . . . . . . . . . . . . . . . . . . . . 16 68 5.2.1. Point . . . . . . . . . . . . . . . . . . . . . . . . 16 69 5.2.2. Polygon . . . . . . . . . . . . . . . . . . . . . . . 18 70 5.2.3. Circle . . . . . . . . . . . . . . . . . . . . . . . . 20 71 5.2.4. Ellipse . . . . . . . . . . . . . . . . . . . . . . . 21 72 5.2.5. Arc Band . . . . . . . . . . . . . . . . . . . . . . . 22 73 5.2.6. Sphere . . . . . . . . . . . . . . . . . . . . . . . . 24 74 5.2.7. Ellipsoid . . . . . . . . . . . . . . . . . . . . . . 25 75 5.2.8. Prism . . . . . . . . . . . . . . . . . . . . . . . . 27 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 78 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 80 9.1. Normative references . . . . . . . . . . . . . . . . . . . 32 81 9.2. Informative References . . . . . . . . . . . . . . . . . . 32 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 83 Intellectual Property and Copyright Statements . . . . . . . . . . 35 85 1. Introduction 87 The Presence Information Data Format Location Object (PIDF-LO) 88 [RFC4119] is the recommended way of encoding location information and 89 associated privacy policies. Location information in a PIDF-LO may 90 be described in a geospatial manner based on a subset of Geography 91 Markup Language (GML) 3.1.1 [OGC-GML3.1.1], or as civic location 92 information [RFC5139]. A GML profile for expressing geodetic shapes 93 in a PIDF-LO is described in [GeoShape]. Uses for PIDF-LO are 94 envisioned in the context of numerous location based applications. 95 This document makes recommendations for formats and conventions to 96 make interoperability less problematic. 98 The PIDF-LO provides a general presence format for representing 99 location information, and permits specification of location 100 information relating to a whole range of aspects of a Target. The 101 general presence data model is described in [RFC4479] and caters for 102 a presence document to describe different aspects of the reachability 103 of a presentity. Continuing this approach, a presence document may 104 contain several GEOPRIV objects that specify different locations and 105 aspects of reachability relating to a presentity. This degree of 106 flexibility is important, and recommendations in this document make 107 no attempt to forbid the usage of a PIDF-LO in this manner. This 108 document provides a specific set of guidelines for building presence 109 documents when it is important to unambiguously convey exactly one 110 location. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 The definition for "Target" is taken from [RFC3693]. 120 In this document a "discrete location" is defined as a place, point, 121 area or volume in which a Target can be found. 123 The term "compound location" is used to describe location information 124 represented by a composite of both civic and geodetic information. 125 An example of compound location might be a geodetic polygon 126 describing the perimeter of a building and a civic element 127 representing the floor in the building. 129 The term "method" in this document refers to the mechanism used to 130 determine the location of a Target. This may be something employed 131 by a location information server (LIS), or by the Target itself. It 132 specifically does not refer to the location configuration protocol 133 (LCP) used to deliver location information either to the Target or 134 the Recipient. 136 The term "source" is used to refer to the LIS, node or device from 137 which a Recipient (Target or Third-Party) obtains location 138 information. 140 3. Using Location Information 142 The PIDF format provides for an unbounded number of , 143 , and elements. Each of these elements contains a 144 single element that may contain more than one 145 element as a child. Each element must contain at least the 146 following two child elements: element and element. One or more elements containing location information 148 are contained inside a element. 150 Hence, a single PIDF document may contain an arbitrary number of 151 location objects some or all of which may be contradictory or 152 complementary. Graphically, the structure of a PIDF-LO document can 153 be depicted as shown in Figure 1. 155 156 157 -- #1 158 159 -- #1 160 161 location element #1 162 location element #2 163 ... 164 location element #n 165 166 167 -- #2 168 -- #3 169 ... 170 -- #m 171 172 173 174 -- #1 175 176 location element(s) 177 178 179 -- #2 180 ... 181 -- #m 182 183 184 -- #1 185 186 location element(s) 187 188 189 -- #2 190 ... 191 -- #m 192 193 -- #2 194 -- #2 195 -- #2 196 ... 197 -- #o 198 200 Figure 1: Structure of a PIDF-LO Document 202 All of these potential sources and storage places for location lead 203 to confusion for the generators, conveyors and consumers of location 204 information. Practical experience within the United States National 205 Emergency Number Association (NENA) in trying to solve these 206 ambiguities led to a set of conventions being adopted. These rules 207 do not have any particular order, but should be followed by creators 208 and consumers of location information contained in a PIDF-LO to 209 ensure that a consistent interpretation of the data can be achieved. 211 Rule #1: A element MUST describe a discrete location. 213 Rule #2: Where a discrete location can be uniquely described in more 214 than one way, each location description SHOULD reside in a 215 separate , , or element; only one geopriv 216 element per tuple. 218 Rule #3: Providing more than one element in a single 219 presence document (PIDF) MUST only be done if the locations refer 220 to the same place or are put into different element types. For 221 example, one location in a , a second location in a 222 element, and a third location in a element. 224 This may occur if a Target's location is determined using a 225 series of different techniques, or the Target wishes to 226 represent her location as well as the location of her PC. In 227 general avoid putting more than one location into a document 228 unless it makes sense to do so. 230 Rule #4: Providing more than one location chunk in a single 231 element SHOULD be avoided where possible. Rule #5 232 and Rule #6 provide further refinement. 234 Rule #5: When providing more than one location chunk in a single 235 element the locations MUST be provided by a common 236 source at the same time and by the same location determination 237 method. 239 Rule #6: Providing more than one location chunk in a single 240 element SHOULD only be used for representing 241 compound location referring to the same place. 243 For example, a geodetic location describing a point, and a 244 civic location indicating the floor in a building. 246 Rule #7: Where compound location is provided in a single element, the coarse location information MUST be provided 248 first. 250 For example, a geodetic location describing an area, and a 251 civic location indicating the floor should be represented with 252 the area first followed by the civic location. 254 Rule #8: Where a PIDF document contains more than one 255 element, the priority of interpretation is given to the first 256 element in the document containing a location. If no 257 element containing a location is present in the document, 258 then priority is given to the first element containing a 259 location. Locations contained in tuples SHOULD only be 260 used as a last resort. 262 Rule #9: Where multiple PIDF documents can be sent or received 263 together, say in a multi-part MIME body, and current location 264 information is required by the recipient, then document selection 265 SHOULD be based on document order, with the first document 266 considered first. 268 The following examples illustrate the application of these rules. 270 3.1. Single Civic Location Information 272 Jane is at a coffee shop on the ground floor of a large shopping 273 mall. Jane turns on her laptop and connects to the coffee-shop's 274 WiFi hotspot, Jane obtains a complete civic address for her current 275 location, for example using the DHCP civic mechanism defined in 276 [RFC4776]. A Location Object is constructed consisting of a single 277 PIDF document, with a single or element, a single 278 element, a single element, and a single location 279 chunk residing in the element. This document is 280 unambiguous, and should be interpreted consistently by receiving 281 nodes if sent over the network. 283 3.2. Civic and Geospatial Location Information 285 Mike is visiting his Seattle office and connects his laptop into the 286 Ethernet port in a spare cube. In this case location information is 287 geodetic location, with the altitude represented as a building floor 288 number. Mike's main location is the point specified by the geodetic 289 coordinates. Further, Mike is on the second floor of the building 290 located at these coordinates. Applying rules #6 and #7, the 291 resulting compound location information is shown in Figure 2. 293 299 300 301 302 303 -43.5723 153.21760 304 305 306 2 307 308 309 310 Wiremap 311 312 mac:8asd7d7d70cf 313 2007-06-22T20:57:29Z 314 315 317 Figure 2 319 3.3. Manual/Automatic Configuration of Location Information 321 Loraine has a predefined civic location stored in her laptop, since 322 she normally lives in Sydney, the address is for her Sydney-based 323 apartment. Loraine decides to visit sunny San Francisco, and when 324 she gets there she plugs in her laptop and makes a call. Loraine's 325 laptop receives a new location from the visited network in San 326 Francisco. As this system cannot be sure that the pre-existing, and 327 new location, both describe the same place, Loraine's computer 328 generates a new PIDF-LO and will use this to represent Loraine's 329 location. If Loraine's computer were to add the new location to her 330 existing PIDF location document (breaking rule #3), then the correct 331 information may still be interpreted by the Location Recipient 332 providing Loraine's system applies rule #9. In this case the 333 resulting order of location information in the PIDF document should 334 be San Francisco first, followed by Sydney. Since the information is 335 provided by different sources, rule #8 should also be applied and the 336 information placed in different tuples with the tuple containing the 337 San Francisco location first. 339 3.4. Multiple Location Objects in a Single PIDF-LO 341 Vanessa has her PC with her at the park, but due to a 342 misconfiguration, her PC reports her location as being in the office. 343 The resulting PIDF-LO will have a element showing the 344 location of Vanessa's PC as the park, and a element saying 345 that Vanessa is in her office. 347 354 355 356 357 358 AU 359 NSW 360 Wollongong 361 North Wollongong 362 363 FlindersStreet 364 Campbell Street 365 366 Gilligan's Island 367 Corner 368 Video Rental Store 369 2500 370 Westerns and Classics 371 store 372 Private Box 15 373 374 375 376 GPS 377 378 mac:1234567890ab 379 2007-06-22T20:57:29Z 380 381 382 383 384 385 -34.410649 150.87651 386 387 30 388 389 390 391 392 Manual 393 394 2007-06-24T12:28:04Z 395 396 398 Figure 3 400 4. Geodetic Coordinate Representation 402 The geodetic examples provided in RFC 4119 [RFC4119] are illustrated 403 using the element, which uses the 404 element inside the element and this representation has 405 several drawbacks. Firstly, it has been deprecated in later versions 406 of GML (3.1 and beyond) making it inadvisable to use for new 407 applications. Secondly, the format of the coordinates type is opaque 408 and so can be difficult to parse and interpret to ensure consistent 409 results, as the same geodetic location can be expressed in a variety 410 of ways. The PIDF-LO Geodetic Shapes specification [GeoShape] 411 provides a specific GML profile for expressing commonly used shapes 412 using simple GML representations. The shapes defined in [GeoShape] 413 are the recommended shapes to ensure interoperability. 415 5. Geodetic Shape Representation 417 The cellular mobile world today makes extensive use of geodetic based 418 location information for emergency and other location-based 419 applications. Generally these locations are expressed as a point 420 (either in two or three dimensions) and an area or volume of 421 uncertainty around the point. In theory, the area or volume 422 represents a coverage in which the user has a relatively high 423 probability of being found, and the point is a convenient means of 424 defining the centroid for the area or volume. In practice, most 425 systems use the point as an absolute value and ignore the 426 uncertainty. It is difficult to determine if systems have been 427 implemented in this manner for simplicity, and even more difficult to 428 predict if uncertainty will play a more important role in the future. 429 An important decision is whether an uncertainty area should be 430 specified. 432 The PIDF-LO Geodetic Shapes specification [GeoShape] defines eight 433 shape types most of which are easily translated into shapes 434 definitions used in other applications and protocols, such as Open 435 Mobile Alliance (OMA) Mobile Location Protocol (MLP). For 436 completeness the shapes defined in [GeoShape] are listed below: 438 o Point (2d and 3d) 440 o Polygon (2d) 442 o Circle (2d) 444 o Ellipse (2d) 446 o Arc band (2d) 448 o Sphere (3d) 450 o Ellipsoid (3d) 452 o Prism (3d) 454 The above-listed shapes MUST be implemented. 456 The GeoShape specification [GeoShape] also describes a standard set 457 of coordinate reference systems (CRS), unit of measure (UoM) and 458 conventions relating to lines and distances. The use of the world 459 geodetic system 1984 (WGS84) [WGS84] coordinate reference system and 460 the usage of European petroleum survey group (EPSG) code 4326 (as 461 identified by the URN urn:ogc:def:crs:EPSG::4326, [CRS-URN]) for two 462 dimensional (2d) shape representations and EPSG 4979 (as identified 463 by the URN urn:ogc:def:crs:EPSG::4979) for three dimensional (3d) 464 volume representations is mandated. Distance and heights are 465 expressed in meters using EPSG 9001 (as identified by the URN 466 urn:ogc:def:uom:EPSG::9001). Angular measures MUST use either 467 degrees or radians. Measures in degrees MUST be identified by the 468 URN urn:ogc:def:uom:EPSG::9102, measures in radians MUST be 469 identified by the URN urn:ogc:def:uom:EPSG::9101. Angles 470 representing bearings are measured in a clockwise direction from 471 Northing, as defined by the WGS84 CRS, not magnetic north. 473 Implementations MUST specify the CRS using the srsName attribute on 474 the outermost geometry element. The CRS MUST NOT be respecified or 475 changed for any sub-elements. The srsDimension attribute SHOULD be 476 omitted, since the number of dimensions in these CRSs is known. A 477 CRS MUST be specified using the above URN notation only; 478 implementations do not need to support user-defined CRSs. 480 Numerical values for coordinates and measures are expressed using the 481 lexical representation for "double" defined in 482 [W3C.REC-xmlschema-2-20041028]. Leading zeros and trailing zeros 483 past the decimal point are not significant; for instance "03.07500" 484 is equivalent to "3.075". 486 It is RECOMMENDED that uncertainty is expressed at a confidence of 487 95% or higher. Specifying a convention for confidence enables better 488 use of uncertainty values. 490 5.1. Polygon Restrictions 492 The Polygon shape type defined in [GeoShape] intentionally does not 493 place any constraints on the number of vertices that may be included 494 to define the bounds of a polygon. This allows arbitrarily complex 495 shapes to be defined and conveyed in a PIDF-LO. However, where 496 location information is to be used in real-time processing 497 applications, such as location dependent routing, having arbitrarily 498 complex shapes consisting of tens or even hundreds of points could 499 result in significant performance impacts. To mitigate this risk 500 Polygon shapes SHOULD be restricted to a maximum of 15 points (16 501 including the repeated point) when the location information is 502 intended for use in real-time applications. This limit of 15 points 503 is chosen to allow moderately complex shape definitions while at the 504 same time enabling interoperation with other location transporting 505 protocols such as those defined in 3GPP (see [3GPP-TS-23_032]) and 506 OMA where the 15 point limit is already imposed. 508 The edges of a polygon are defined by the shortest path between two 509 points in space (not a geodesic curve). Two dimensional points MAY 510 be interpreted as having a zero valure for their altitude component. 512 To avoid significant errors arising from potential geodesic 513 interpolation, the length between adjacent vertices SHOULD be 514 restricted to a maximum of 130km. More information relating to this 515 restriction is provided in [GeoShape]. 517 A connecting line SHALL NOT cross another connecting line of the same 518 Polygon. 520 Polygons MUST be defined with the upward normal pointing up. This is 521 accomplished by defining the vertices in a counter-clockwise 522 direction. 524 Points specified in a polygon using 3 dimensional coordinates MUST 525 all have the same altitude. 527 5.2. Shape Examples 529 This section provides some examples of where some of the more complex 530 shapes are used, how they are determined, and how they are 531 represented in a PIDF-LO. Complete details on all of the GeoShape 532 types are provided in [GeoShape]. 534 5.2.1. Point 536 The point shape type is the simplest form of geodetic location 537 information (LI), which is natively supported by GML. The gml:Point 538 element is used when there is no known uncertainty. A point also 539 forms part of a number of other geometries. A point may be specified 540 using either WGS 84 (latitude, longitude) or WGS 84 (latitude, 541 longitude, altitude). Figure 4 shows a 2d point: 543 549 550 551 552 553 -34.407 150.883 554 555 556 557 Wiremap 558 559 mac:1234567890ab 560 2007-06-22T20:57:29Z 561 562 564 Figure 4 566 Figure 5 shows a 3d point: 568 573 574 575 576 578 -34.407 150.883 24.8 579 580 581 582 Wiremap 583 584 mac:1234567890ab 585 2007-06-22T20:57:29Z 586 587 589 Figure 5 591 5.2.2. Polygon 593 The polygon shape may be used to represent a building outline or 594 coverage area. The first and last points of the polygon have to be 595 the same. For example, looking at the hexagon in Figure 6 with 596 vertices, A, B, C, D, E, and F. The resulting polygon will be defined 597 with 7 points, with the first and last points both having the 598 coordinates of point A. 600 F--------------E 601 / \ 602 / \ 603 / \ 604 A D 605 \ / 606 \ / 607 \ / 608 B--------------C 610 Figure 6 612 616 617 618 619 620 621 622 623 43.311 -73.422 624 43.111 -73.322 625 43.111 -73.222 626 43.311 -73.122 627 43.411 -73.222 628 43.411 -73.322 629 43.311 -73.422 630 631 632 633 634 635 Wiremap 636 637 638 2007-06-22T20:57:29Z 639 640 642 Figure 7 644 In addition to the form shown in Figure 7 GML supports a posList 645 which provides a more compact representation for the coordinates of 646 the Polygon vertices than the discrete pos elements. The more 647 compact form is shown in Figure 8. Both forms are permitted. 649 653 654 655 656 657 658 659 660 661 43.311 -73.422 43.111 -73.322 662 43.111 -73.222 43.311 -73.122 663 43.411 -73.222 43.411 -73.322 664 43.311 -73.422 665 666 667 668 669 670 671 Wiremap 672 673 674 2007-06-22T20:57:29Z 675 676 678 Figure 8 680 5.2.3. Circle 682 The circular area is used for coordinates in two-dimensional CRSs to 683 describe uncertainty about a point. The definition is based on the 684 one-dimensional geometry in GML, gml:CircleByCenterPoint. The centre 685 point of a circular area is specified by using a two dimensional CRS; 686 in three dimensions, the orientation of the circle cannot be 687 specified correctly using this representation. A point with 688 uncertainty that is specified in three dimensions should use the 689 Sphere shape type. 691 696 697 698 699 700 701 42.5463 -73.2512 702 703 850.24 704 705 706 707 708 OTDOA 709 710 711 712 714 Figure 9 716 5.2.4. Ellipse 718 An elliptical area describes an ellipse in two dimensional space. 719 The ellipse is described by a center point, the length of its semi- 720 major and semi-minor axes, and the orientation of the semi-major 721 axis. Like the circular area (Circle), the ellipse MUST be specified 722 using the two dimensional CRS. 724 729 730 731 732 733 734 42.5463 -73.2512 735 736 1275 737 738 739 670 740 741 742 43.2 743 744 745 746 747 Device-Assisted_A-GPS 748 749 750 2007-06-22T20:57:29Z 751 752 754 Figure 10 756 The gml:pos element indicates the position of the center, or origin, 757 of the ellipse. The gs:semiMajorAxis and gs:semiMinorAxis elements 758 are the length of the semi-major and semi-minor axes respectively. 759 The gs:orientation element is the angle by which the semi-major axis 760 is rotated from the first axis of the CRS towards the second axis. 761 For WGS 84, the orientation indicates rotation from Northing to 762 Easting, which, if specified in degrees, is roughly equivalent to a 763 compass bearing (if magnetic north were the same as the WGS north 764 pole). Note: An ellipse with equal major and minor axis lengths is a 765 circle. 767 5.2.5. Arc Band 769 The arc band shape type is commonly generated in wireless systems 770 where timing advance or code offsets sequences are used to compensate 771 for distances between handsets and the access point. The arc band is 772 represented as two radii emanating from a central point, and two 773 angles which represent the starting angle and the opening angle of 774 the arc. In a cellular environment the central point is nominally 775 the location of the cell tower, the two radii are determined by the 776 extent of the timing advance, and the two angles are generally 777 provisioned information. 779 For example, Paul is using a cellular wireless device and is 7 timing 780 advance symbols away from the cell tower. For a GSM-based network 781 this would place Paul roughly between 3,594 meters and 4,148 meters 782 from the cell tower, providing the inner and outer radius values. If 783 the start angle is 20 degrees from north, and the opening angle is 784 120 degrees, an arc band representing Paul's location would look 785 similar to Figure 11. 787 N ^ ,.__ 788 | a(s) / `-. 789 | 20 / `-. 790 |--. / `. 791 | `/ \ 792 | /__ \ 793 | . `-. \ 794 | . `. \ 795 |. \ \ . 796 ---c-- a(o) -- | | --> 797 |. / 120 ' | E 798 | . / ' 799 | . / ; 800 .,' / 801 r(i)`. / 802 (3594m) `. / 803 `. ,' 804 `. ,' 805 r(o)`' 806 (4148m) 808 Figure 11 810 The resulting PIDF-LO is shown in Figure 12. 812 817 818 819 820 821 822 -43.5723 153.21760 823 824 3594 825 826 827 4148 828 829 830 20 831 832 833 20 834 835 836 837 838 TA-NMR 839 840 841 2007-06-22T20:57:29Z 842 843 845 Figure 12 847 An important note to make on the arc band is that the center point 848 used in the definition of the shape is not included in resulting 849 enclosed area, and that Target may be anywhere in the defined area of 850 the arc band. 852 5.2.6. Sphere 854 The sphere is a volume that provides the same information as a circle 855 in three dimensions. The sphere has to be specified using a three 856 dimensional CRS. Figure 13 shows the sphere shape, which is 857 identical to the circle example, except for the addition of an 858 altitude in the provided coordinates. 860 865 866 867 868 869 870 42.5463 -73.2512 26.3 871 872 850.24 873 874 875 876 877 Device-Based_A-GPS 878 879 880 881 883 Figure 13 885 5.2.7. Ellipsoid 887 The ellipsoid is the volume most commonly produced by GPS systems. 888 It is used extensively in navigation systems and wireless location 889 networks. The ellipsoid is constructed around a central point 890 specified in three dimensions, and three axies perpendicular to one 891 another are extended outwards from this point. These axies are 892 defined as the semi-major (M) axis, the semi-minor (m) axis, and the 893 vertical (v) axis respectively. An angle is used to express the 894 orientation of the ellipsoid. The orientation angle is measured in 895 degrees from north, and represents the direction of the semi-major 896 axis from the center point. 898 \ 899 _.-\""""^"""""-._ 900 .' \ | `. 901 / v m \ 902 | \ | | 903 | -c ----M---->| 904 | | 905 \ / 906 `._ _.' 907 `-...........-' 909 Figure 14 911 A PIDF-LO containing an ellipsoid appears as shown in Figure 15. 913 918 919 920 921 922 923 42.5463 -73.2512 26.3 924 925 7.7156 926 927 928 3.31 929 930 931 28.7 932 933 934 90 935 936 937 938 939 Hybrid_A-GPS 940 941 942 2007-06-22T20:57:29Z 943 944 945 Figure 15 947 5.2.8. Prism 949 A prism may be used to represent a section of a building or range of 950 floors of building. The prism extrudes a polygon by providing a 951 height element. It consists of a base made up of coplanar points 952 defined in 3 dimensions all at the same altitude. The prism is then 953 an extrusion from this base to the value specified in the height 954 element. The height of the Prism MUST be a positive value. The 955 first and last points of the polygon have to be the same. 957 For example, looking at the cube in Figure 16. If the prism is 958 extruded from the bottom up, then the polygon forming the base of the 959 prism is defined with the points A, B, C, D, A. The height of the 960 prism is the distance between point A and point E in meters. 962 G-----F 963 /| /| 964 / | / | 965 H--+--E | 966 | C--|--B 967 | / | / 968 |/ |/ 969 D-----A 971 Figure 16 973 The resulting PIDF-LO is shown in Figure 17. 975 980 981 982 983 984 985 986 987 988 989 990 42.556844 -73.248157 36.6 991 42.656844 -73.248157 36.6 992 42.656844 -73.348157 36.6 993 42.556844 -73.348157 36.6 994 42.556844 -73.248157 36.6 995 996 997 998 999 1000 1001 2.4 1002 1003 1004 1005 1006 Wiremap 1007 1008 1009 2007-06-22T20:57:29Z 1010 1011 1013 Figure 17 1015 6. Security Considerations 1017 The primary security considerations relate to how location 1018 information is conveyed and used, which are outside the scope of this 1019 document. This document is intended to serve only as a set of 1020 guidelines as to which elements MUST or SHOULD be implemented by 1021 systems wishing to perform location dependent routing. The 1022 ramification of such recommendations is that they extend to devices 1023 and clients that wish to make use of such services. 1025 7. IANA Considerations 1027 This document does not introduce any IANA considerations. 1029 8. Acknowledgments 1031 The authors would like to thank the GEOPRIV working group for their 1032 discussions in the context of PIDF-LO, in particular Carl Reed, Ron 1033 Lake, James Polk, Henning Schulzrinne, Jerome Grenier, Roger Marshall 1034 and Robert Sparks. Furthermore, we would like to thank Jon Peterson 1035 as the author of PIDF-LO and Nadine Abbott for her constructive 1036 comments in clarifying some aspects of the document. 1038 Thanks to Karen Navas for pointing out some omissions in the 1039 examples. 1041 9. References 1043 9.1. Normative references 1045 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1046 Requirement Levels", BCP 14, RFC 2119, March 1997. 1048 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 1049 Format", RFC 4119, December 2005. 1051 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, 1052 July 2006. 1054 [GeoShape] 1055 Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape 1056 Application Schema for use by the Internet Engineering 1057 Task Force (IETF)", Candidate OpenGIS Implementation 1058 Specification 06-142r1, Version: 1.0, April 2007. 1060 [OGC-GML3.1.1] 1061 Portele, C., Cox, S., Daisy, P., Lake, R., and A. 1062 Whiteside, "Geography Markup Language (GML) 3.1.1", 1063 OGC 03-105r1, July 2003. 1065 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 1066 Format for Presence Information Data Format Location 1067 Object (PIDF-LO)", RFC 5139, February 2008. 1069 [W3C.REC-xmlschema-2-20041028] 1070 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 1071 Second Edition", World Wide Web Consortium 1072 Recommendation REC-xmlschema-2-20041028, October 2004, 1073 . 1075 9.2. Informative References 1077 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 1078 (DHCPv4 and DHCPv6) Option for Civic Addresses 1079 Configuration Information", RFC 4776, November 2006. 1081 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 1082 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 1084 [3GPP-TS-23_032] 1085 "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project; 1086 Technical Specification Group Code Network; Universal 1087 Geographic Area Description (GAD)". 1089 [CRS-URN] Whiteside, A., "GML 3.1.1 Common CRSs Profile", OGC 03- 1090 105r1, November 2005. 1092 [WGS84] US National Imagery and Mapping Agency, "Department of 1093 Defense (DoD) World Geodetic System 1984 (WGS 84), Third 1094 Edition", NIMA TR8350.2, January 2000. 1096 Authors' Addresses 1098 James Winterbottom 1099 Andrew Corporation 1100 Wollongong 1101 NSW Australia 1103 Email: james.winterbottom@andrew.com 1105 Martin Thomson 1106 Andrew Corporation 1107 Wollongong 1108 NSW Australia 1110 Email: martin.thomson@andrew.com 1112 Hannes Tschofenig 1113 Nokia Siemens Networks 1114 Linnoitustie 6 1115 Espoo 02600 1116 Finland 1118 Phone: +358 (50) 4871445 1119 Email: Hannes.Tschofenig@gmx.net 1120 URI: http://www.tschofenig.priv.at 1122 Full Copyright Statement 1124 Copyright (C) The IETF Trust (2008). 1126 This document is subject to the rights, licenses and restrictions 1127 contained in BCP 78, and except as set forth therein, the authors 1128 retain all their rights. 1130 This document and the information contained herein are provided on an 1131 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1132 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1133 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1134 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1135 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1136 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1138 Intellectual Property 1140 The IETF takes no position regarding the validity or scope of any 1141 Intellectual Property Rights or other rights that might be claimed to 1142 pertain to the implementation or use of the technology described in 1143 this document or the extent to which any license under such rights 1144 might or might not be available; nor does it represent that it has 1145 made any independent effort to identify any such rights. Information 1146 on the procedures with respect to rights in RFC documents can be 1147 found in BCP 78 and BCP 79. 1149 Copies of IPR disclosures made to the IETF Secretariat and any 1150 assurances of licenses to be made available, or the result of an 1151 attempt made to obtain a general license or permission for the use of 1152 such proprietary rights by implementers or users of this 1153 specification can be obtained from the IETF on-line IPR repository at 1154 http://www.ietf.org/ipr. 1156 The IETF invites any interested party to bring to its attention any 1157 copyrights, patents or patent applications, or other proprietary 1158 rights that may cover technology that may be required to implement 1159 this standard. Please address the information to the IETF at 1160 ietf-ipr@ietf.org.