idnits 2.17.1 draft-ietf-geopriv-pdif-lo-profile-08.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 1021. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1032. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1039. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1045. 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 (June 29, 2007) is 6144 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '8' is defined on line 974, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: A later version (-07) exists of draft-ietf-geopriv-revised-civic-lo-05 -- Obsolete informational reference (is this intentional?): RFC 3825 (ref. '8') (Obsoleted by RFC 6225) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 10 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: December 31, 2007 Nokia Siemens Networks 7 June 29, 2007 9 GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations 10 draft-ietf-geopriv-pdif-lo-profile-08.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 December 31, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 The Presence Information Data Format Location Object (PIDF-LO) 44 specification provides a flexible and versatile means to represent 45 location information. There are, however, circumstances that arise 46 when information needs to be constrained in how it is represented so 47 that the number of options that need to be implemented in order to 48 make use of it are reduced. There is growing interest in being able 49 to use location information contained in a PIDF-LO for routing 50 applications. To allow successful interoperability between 51 applications, location information needs to be normative and more 52 tightly constrained than is currently specified in the RFC 4119 53 (PIDF-LO). This document makes recommendations on how to constrain, 54 represent and interpret locations in a PIDF-LO. It further 55 recommends a subset of GML that is mandatory to implemented by 56 applications involved in location based routing. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Using Location Information . . . . . . . . . . . . . . . . . . 6 63 3.1. Single Civic Location Information . . . . . . . . . . . . 8 64 3.2. Civic and Geospatial Location Information . . . . . . . . 8 65 3.3. Manual/Automatic Configuration of Location Information . . 9 66 4. Geodetic Coordinate Representation . . . . . . . . . . . . . . 10 67 5. Geodetic Shape Representation . . . . . . . . . . . . . . . . 11 68 5.1. Polygon Restrictions . . . . . . . . . . . . . . . . . . . 12 69 5.2. Shape Examples . . . . . . . . . . . . . . . . . . . . . . 13 70 5.2.1. Point . . . . . . . . . . . . . . . . . . . . . . . . 13 71 5.2.2. Polygon . . . . . . . . . . . . . . . . . . . . . . . 14 72 5.2.3. Circle . . . . . . . . . . . . . . . . . . . . . . . . 16 73 5.2.4. Ellipse . . . . . . . . . . . . . . . . . . . . . . . 17 74 5.2.5. Arc Band . . . . . . . . . . . . . . . . . . . . . . . 19 75 5.2.6. Sphere . . . . . . . . . . . . . . . . . . . . . . . . 20 76 5.2.7. Ellipsoid . . . . . . . . . . . . . . . . . . . . . . 21 77 5.2.8. Prism . . . . . . . . . . . . . . . . . . . . . . . . 23 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 80 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 82 9.1. Normative references . . . . . . . . . . . . . . . . . . . 29 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 29 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 85 Intellectual Property and Copyright Statements . . . . . . . . . . 31 87 1. Introduction 89 The Presence Information Data Format Location Object (PIDF-LO) [2] is 90 the recommended way of encoding location information and associated 91 privacy policies. Location information in a PIDF-LO may be described 92 in a geospatial manner based on a subset of GMLv3, or as civic 93 location information [6]. A GML profile for expressing geodetic 94 shapes in a PIDF-LO is described in [4]. Uses for PIDF-LO are 95 envisioned in the context of numerous location based applications. 96 This document makes recommendations for formats and conventions to 97 make interoperability less problematic. 99 The PIDF-LO provides a general presence format for representing 100 location information, and permits specification of location 101 information relating to a whole range of aspects of a Target. The 102 general presence data model is described in [3] and caters for a 103 presence document to describe different aspects of the reachability 104 of a presentity. Continuing this approach, a presence document may 105 contain several geopriv objects that specify different locations and 106 aspects of reachability relating to a presentity. This degree of 107 flexibility is important, and and recommendations in this document 108 make no attempt to forbid the usage of a PIDF-LO in this manner. 109 This document provides a specific set of guidelines for building 110 preence documents when it is important to unambiguously convey 111 exactly one location. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [1]. 119 The definition for "Target" is taken from [7]. 121 In this document a "discrete location" is defined as a place, point, 122 area or volume in which a Target can be found. It must be described 123 with sufficient precision to address the requirements of an intended 124 application. 126 The term "compound location" is used to describe location information 127 represented by a composite of both civic and geodetic information. 128 An example of compound location might be a geodetic polygon 129 describing the perimeter of a building and a civic element 130 representing the floor in the building. 132 The term _method_ is this document refers to the mechanism used to 133 determine the location of a Target. This may be something employed 134 by an LCS, or by the Target itself. It specifically does not refer 135 to the LCP used to deliver location information either to the Target 136 or the Recipient. 138 The term _source_ is used to refer to the LCS, node or device from 139 which a Recipient (Target or Third-Party) obtains location 140 information/ 142 3. Using Location Information 144 The PIDF format provides for an unbounded number of elements. 145 Each element contains a single element that may 146 contain more than one element as a child element. Each 147 element must contain at least the following two child 148 elements: element and element. One or 149 more chunks of location information are contained inside a element. 152 Hence, a single PIDF document may contain an arbitrary number of 153 location objects some or all of which may be contradictory or 154 complementary. Graphically, the structure of a PIDF-LO document can 155 be depicted as shown in Figure 1. 157 158 159 -- #1 160 161 -- #1 162 163 location chunk #1 164 location chunk #2 165 ... 166 location chunk #n 167 168 169 -- #2 170 -- #3 171 ... 172 -- #m 173 174 175 -- #2 176 -- #3 177 ... 178 -- #o 179 181 Figure 1: Structure of a PIDF-LO Document 183 All of these potential sources and storage places for location lead 184 to confusion for the generators, conveyors and consumers of location 185 information. Practical experience within the United States National 186 Emergency Number Association (NENA) in trying to solve these 187 ambiguities led to a set of conventions being adopted. These rules 188 do not have any particular order, but should be followed by creators 189 and consumers of location information contained in a PIDF-LO to 190 ensure that a consistent interpretation of the data can be achieved. 192 Rule #1: A element MUST describe a discrete location. 194 Rule #2: Where a discrete location can be uniquely described in more 195 than one way, each location description SHOULD reside in a 196 separate element. 198 Rule #3: Providing more than one geopriv element in a single 199 presence document (PIDF) MUST only be done if all objects refer to 200 the same place. 202 This may occur if a Target's location is determined using a 203 series of different techniques. 205 Rule #4: Providing more than one location chunk in a single 206 element SHOULD be avoided where possible. Rule #5 207 and Rule #6 provide further refinement. 209 Rule #5: When providing more than one location chunk in a single 210 element the locations MUST be provided by a common 211 source at the same time and by the same location determination 212 method. 214 Rule #6: Providing more than one location chunk in a single 215 element SHOULD only be used for representing 216 compound location referring to the same place. 218 For example, a geodetic location describing a point, and a 219 civic location indicating the floor in a building. 221 Rule #7: Where compound location is provided in a single element, the coarse location information MUST be provided 223 first. 225 For example, a geodetic location describing an area, and a 226 civic location indicating the floor should be represented with 227 the area first followed by the civic location. 229 Rule #8: Where a PIDF document contains more than one 230 element containing a element with a element, 231 the priority of tuples SHOULD be based on position of the 232 element within the PIDF document. That is to say, the tuple with 233 the highest priority location occurs earliest in the PIDF 234 document. 236 Rule #9: Where multiple PIDF documents can be sent or received 237 together, say in a multi-part MIME body, and current location 238 information is required by the recipient, then document selection 239 SHOULD be based on document order, with the first document 240 considered first. 242 The following examples illustrate the application of these rules. 244 3.1. Single Civic Location Information 246 Jane is at a coffee shop on the ground floor of a large shopping 247 mall. Jane turns on her laptop and connects to the coffee-shop's 248 WiFi hotspot, Jane obtains a complete civic address for her current 249 location, for example using the DHCP civic mechanism defined in [5]. 250 A Location Object is constructed consisting of a single PIDF 251 document, with a single element, a single element, a 252 single element, and a single location chunk residing in the 253 element. This document is unambiguous, and should be 254 interpreted consistently by receiving nodes if sent over the network. 256 3.2. Civic and Geospatial Location Information 258 Mike is visiting his Seattle office and connects his laptop into the 259 Ethernet port in a spare cube. In this case location information is 260 geodetic location, with the altitude represented as a building floor 261 number. Mike's main location is the point specified by the geodetic 262 coordinates. Further, Mike is on the second floor of the building 263 located at these coordinates. Applying rules #6 and #7, the 264 resulting compound location information is shown below. 266 267 272 273 274 275 276 -43.5723 153.21760 278 279 280 2 281 282 283 284 285 286 2003-06-22T20:57:29Z 287 288 290 3.3. Manual/Automatic Configuration of Location Information 292 Loraine has a predefined civic location stored in her laptop, since 293 she normally lives in Sydney, the address is for her Sydney-based 294 apartment. Loraine decides to visit sunny San Francisco, and when 295 she gets there she plugs in her laptop and makes a call. Loraine's 296 laptop receives a new location from the visited network in San 297 Francisco. As this system cannot be sure that the pre-existing, and 298 new location, describe the same place, Loraine's computer generates a 299 new PIDF-LO and will use this to represent Loraine's location. If 300 Loraine's computer were to add the new location to her existing PIDF 301 location document (breaking rule #3), then the correct information 302 may still be interpreted by the Location Recipient providing 303 Loraine's system applies rule #9. In this case the resulting order 304 of location information in the PIDF document should be San Francisco 305 first, followed by Sydney. Since the information is provided by 306 different sources, rule #8 should also be applied and the information 307 placed in different tuples with the tuple containing the San 308 Francisco location first. 310 4. Geodetic Coordinate Representation 312 The geodetic examples provided in RFC 4119 [2] are illustrated using 313 the element, which uses the element 314 inside the element and this representation has several 315 drawbacks. Firstly, it has been deprecated in later versions of GML 316 (3.1 and beyond) making it inadvisable to use for new applications. 317 Secondly, the format of the coordinates type is opaque and so can be 318 difficult to parse and interpret to ensure consistent results, as the 319 same geodetic location can be expressed in a variety of ways. The 320 PIDF-LO Geodetic Shapes specification [4] provides a specific GML 321 profile for expressing commonly used shapes using simple GML 322 representations. The shapes defined in [4] are the recommended 323 shapes to ensure interoperability. 325 5. Geodetic Shape Representation 327 The cellular mobile world today makes extensive use of geodetic based 328 location information for emergency and other location-based 329 applications. Generally these locations are expressed as a point 330 (either in two or three dimensions) and an area or volume of 331 uncertainty around the point. In theory, the area or volume 332 represents a coverage in which the user has a relatively high 333 probability of being found, and the point is a convenient means of 334 defining the centroid for the area or volume. In practice, most 335 systems use the point as an absolute value and ignore the 336 uncertainty. It is difficult to determine if systems have been 337 implemented in this manner for simplicity, and even more difficult to 338 predict if uncertainty will play a more important role in the future. 339 An important decision is whether an uncertainty area should be 340 specified. 342 The PIDF-LO Geodetic Shapes specification [4] defines eight shape 343 types most of which are easily translated into shapes definitions 344 used in other applications and protocols, such as Open Mobile 345 Alliance (OMA) Mobile Location Protocol (MLP). For completeness the 346 shapes defined in [4] are listed below: 348 o Point (2d and 3d) 350 o Polygon (2d) 352 o Circle (2d) 354 o Ellipse (2d) 356 o Arc band (2d) 358 o Sphere (3d) 360 o Ellipsoid (3d) 362 o Prism (3d) 364 All above-listed shapes are mandatory to implement. 366 The GeoShape specification [4] also describes a standard set of 367 coordinate reference systems (CRS), unit of measure (UoM) and 368 conventions relating to lines and distances. The use of the WGS-84 369 coordinate reference system and the usage of EPSG-4326 (as identified 370 by the URN urn:ogc:def:crs:EPSG::4326) for two dimensional (2d) shape 371 representations and EPSG-4979 (as identified by the URN 372 urn:ogc:def:crs:EPSG::4979) for three dimensional (3d) volume 373 representations is mandated. Distance and heights are expressed in 374 meters using EPSG-9001 (as identified by the URN 375 urn:ogc:def:uom:EPSG::9001). Angular measures MUST use either 376 degrees or radians. Measures in degrees MUST be identified by the 377 URN urn:ogc:def:uom:EPSG::9102, measures in radians MUST be 378 identified by the URN urn:ogc:def:uom:EPSG::9101 380 Implementations MUST specify the CRS using the srsName attribute on 381 the outermost geometry element. The CRS MUST NOT be respecified or 382 changed for any sub-elements. The srsDimension attribute SHOULD be 383 omitted, since the number of dimensions in these CRSs is known. A 384 CRS MUST be specified using the above URN notation only, 385 implementations do not need to support user-defined CRSs. 387 It is RECOMMENDED that where uncertainty is included, a confidence of 388 68% (or one standard deviation) is used. Specifying a convention for 389 confidence enables better use of uncertainty values. 391 5.1. Polygon Restrictions 393 The Polygon shape type defined in [4] intentionally does not place 394 any constraints on the number of vertices that may be included to 395 define the bounds of a polygon. This allows arbitrarily complex 396 shapes to be defined and conveyed in a PIDF-LO. However, where 397 location information is to be used in real-time processing 398 applications, such as location dependent routing, having arbitrarily 399 complex shapes consisting of tens or even hundreds of points could 400 result in significant performance impacts. To mitigate this risk it 401 is recommended that Polygon shapes be restricted to a maximum of 15 402 points (16 including the repeated point) when the location 403 information is intended for use in real-time applications. This 404 limit of 15 points is chosen to allow moderately complex shape 405 definitions while at the same time enabling interoperation with other 406 location transporting protocols such as those defined in 3GPP (see 407 [9]) and OMA where the 15 point limit is already imposed. 409 Polygons are defined with the minimum distance between two adjacent 410 vertices (geodesic). To avoid the incursion of significant errors 411 length between adjacent vertices SHOULD be restricted to a maximum of 412 130km. More information relating to this restriction is provided in 413 [4]. 415 A connecting line SHALL NOT cross another connecting line of the same 416 Polygon. 418 Polygons SHOULD be defined with the upward normal pointing up, this 419 is accomplished by defining the vertices in counter-clockwise 420 direction. 422 Points specified in a polygon MUST be coplanar, and it is RECOMMENDED 423 that where points are specified in 3 dimensions that all points 424 maintain the same altitude. 426 5.2. Shape Examples 428 This section provides some examples of where some of the more complex 429 shapes are used, how they are determined, and how they are 430 represented in a PIDF-LO. Complete details on all of the Geoshape 431 types are provided in [4]. 433 5.2.1. Point 435 The point shape type is the simplest form of geodetic LI, which is 436 natively supported by GML. The gml:Point element is used when there 437 is no known uncertainty. A point also forms part of a number of 438 other geometries. A point may be specified using either WGS 84 439 (latitude, longitude) or WGS 84 (latitude, longitude, altitude). The 440 next example shows a 2d point: 442 443 449 450 451 452 453 455 -34.407 150.883 456 457 458 459 460 461 2007-06-22T20:57:29Z 462 463 465 The next example shows a 3d point: 467 468 474 475 476 477 478 480 -34.407 150.883 24.8 481 482 483 484 485 486 2007-06-22T20:57:29Z 487 488 490 5.2.2. Polygon 492 The polygon shape may be used to represent a building outline or 493 coverage area. The first and last points of the polygon have to be 494 the same. For example, looking at the octagon below with vertices, 495 A, H, G, F, E, D, C, B, A. The resulting polygon will be defined with 496 9 points, with the first and last points both having the coordinates 497 of point A. 499 B-------------C 500 / \ 501 / \ 502 / \ 503 A D 504 | | 505 | | 506 | | 507 | | 508 H E 509 \ / 510 \ / 511 \ / 512 G--------------F 514 515 521 522 523 524 525 526 527 528 43.311 -73.422 529 43.211 -73.422 530 43.111 -73.322 531 43.111 -73.222 532 43.211 -73.122 533 43.311 -73.122 534 43.411 -73.222 535 43.411 -73.322 536 43.311 -73.422 537 538 539 540 541 542 543 544 2007-06-22T20:57:29Z 545 546 548 Figure 6 550 In addition to the form shown in Figure 6 GML supports a posList 551 which provides a more compact representation for the coordinates of 552 the Polygon vertices than the discrete pos elements. The more 553 compact form is shown in Figure 7. Both forms are permitted. 555 556 562 563 564 565 566 567 568 569 43.311 -73.422 43.211 -73.422 570 43.111 -73.322 43.111 -73.222 571 43.211 -73.122 43.311 -73.122 572 43.411 -73.222 43.411 -73.322 573 43.311 -73.422 574 575 576 577 578 579 580 581 582 2007-06-22T20:57:29Z 583 584 586 Figure 7 588 5.2.3. Circle 590 The circular area is used for coordinates in two-dimensional CRSs to 591 describe uncertainty about a point. The definition is based on the 592 one-dimensional geometry in GML, gml:CircleByCenterPoint. The centre 593 point of a circular area is specified by using a two dimensional CRS; 594 in three dimensions, the orientation of the circle cannot be 595 specified correctly using this representation. A point with 596 uncertainty that is specified in three dimensions should use the 597 Sphere shape type. 599 600 606 607 608 609 610 611 612 42.5463 -73.2512 613 614 615 850.24 616 617 618 619 620 621 622 624 5.2.4. Ellipse 626 An elliptical area describes an ellipse in two dimensional space. 627 The ellipse is described by a center point, the length of its semi- 628 major and semi-minor axes, and the orientation of the semi-major 629 axis. Like the circular area (Circle), the ellipse MUST be specified 630 using the two dimensional CRS. 632 633 639 640 641 642 643 644 645 42.5463 -73.2512 646 647 648 1275 649 650 651 670 652 653 654 43.2 655 656 657 658 659 660 661 2003-06-22T20:57:29Z 662 663 665 The gml:pos element indicates the position of the center, or origin, 666 of the ellipse. The gs:semiMajorAxis and gs:semiMinorAxis elements 667 are the length of the semi-major and semi-minor axes respectively. 668 The gs:orientation element is the angle by which the semi-major axis 669 is rotated from the first axis of the CRS towards the second axis. 670 For WGS 84, the orientation indicates rotation from Northing to 671 Easting, which, if specified in degrees, is roughly equivalent to a 672 compass bearing (if magnetic north were the same as the WGS north 673 pole). Note: An ellipse with equal major and minor axis lengths is a 674 circle. 676 5.2.5. Arc Band 678 The arc band shape type is commonly generated in wireless systems 679 where timing advance or code offsets sequences are used to compensate 680 for distances between handsets and the access point. The arc band is 681 represented as two radii emanating from a central point, and two 682 angles which represent the starting angle and the opening angle of 683 the arc. In a cellular environment the central point is nominally 684 the location of the cell tower, the two radii are determined by the 685 extent of the timing advance, and the two angles are generally 686 provisioned information. 688 For example, Paul is using a cellular wireless device and is 7 timing 689 advance symbols away from the cell tower. For a GSM-based network 690 this would place Paul roughly between 3,594 meters and 4,148 meters 691 from the cell tower, providing the inner and outer radius values. If 692 the start angle is 20 degrees from north, and the opening angle is 693 120 degrees, an arc band representing Paul's location would look 694 similar to the figure below. 696 N ^ ,.__ 697 | a(s) / `-. 698 | 20 / `-. 699 |--. / `. 700 | `/ \ 701 | /__ \ 702 | . `-. \ 703 | . `. \ 704 |. \ \ . 705 ---c-- a(o) -- | | --> 706 |. / 120 ' | E 707 | . / ' 708 | . / ; 709 .,' / 710 r(i)`. / 711 (3594m) `. / 712 `. ,' 713 `. ,' 714 r(o)`' 715 (4148m) 717 The resulting PIDF-LO is reflected below. 719 720 726 727 728 729 730 731 732 -43.5723 153.21760 733 734 735 3594 736 737 738 4148 739 740 741 20 742 743 744 20 745 746 747 748 749 750 751 2003-06-22T20:57:29Z 752 753 755 An important note to make on the arc band is that the center point 756 used in the definition of the shape is not included in resulting 757 enclosed area, and that Target may be anywhere in the defined area of 758 the arc band. 760 5.2.6. Sphere 762 The sphere is a volume that provides the same information as a circle 763 in three dimensions. The sphere has to be specified using a three 764 dimensional CRS. The following example shows a sphere shape, which 765 is identical to the circle example, except for the addition of an 766 altitude in the provided coordinates. 768 769 775 776 777 778 779 780 781 42.5463 -73.2512 26.3 782 783 784 850.24 785 786 787 788 789 790 791 793 5.2.7. Ellipsoid 795 The ellipsoid is the volume most commonly produced by GPS systems. 796 It is used extensively in navigation systems and wireless location 797 networks. The ellipsoid is constructed around a central point 798 specified in three dimensions, and three axies perpendicular to one 799 another are extended outwards from this point. These axies are 800 defined as the semi-major (M) axis, the semi-minor (m) axis, and the 801 vertical (v) axis respectively. An angle is used to express the 802 orientation of the ellipsoid. The orientation angle is measured in 803 degrees from north, and represents the direction of the semi-major 804 axis from the center point. 806 \ 807 _.-\""""^"""""-._ 808 .' \ | `. 809 / v m \ 810 | \ | | 811 | -c ----M---->| 812 | | 813 \ / 814 `._ _.' 815 `-...........-' 817 A PIDF-LO containing an ellipsoid would like something like the 818 sample below. 820 821 827 828 829 830 831 832 833 42.5463 -73.2512 26.3 834 835 836 7.7156 837 838 839 3.31 840 841 842 28.7 843 844 845 90 846 847 848 849 850 851 852 2003-06-22T20:57:29Z 853 854 856 5.2.8. Prism 858 A prism may be used to represent a section of a building or range of 859 floors of building. The prism extrudes a polygon by providing a 860 height element. It consists of a base made up of coplanar points 861 defined in 3 dimensions all at the same altitude. The prism is then 862 an extrusion from this base to the value specified in the height 863 element. If the height is negative, then the prism is extruded from 864 the top down, while a positive height extrudes from the bottom up. 865 The first and last points of the polygon have to be the same. 867 For example, looking at the cube below. If the prism is extruded 868 from the bottom up, then the polygon forming the base of the prism is 869 defined with the points A, B, C, D, A. The height of the prism is the 870 distance between point A and point E in meters. The resulting 871 PIDF-LO is provided below. 873 G-----F 874 /| /| 875 / | / | 876 H--+--E | 877 | C--|--B 878 | / | / 879 |/ |/ 880 D-----A 882 883 889 890 891 892 893 894 895 896 897 898 899 42.556844 -73.248157 36.6 900 42.656844 -73.248157 36.6 901 42.656844 -73.348157 36.6 902 42.556844 -73.348157 36.6 903 42.556844 -73.248157 36.6 904 905 906 907 908 909 910 2.4 911 912 913 914 915 916 917 2007-06-22T20:57:29Z 918 919 921 6. Security Considerations 923 The primary security considerations relate to how location 924 information is conveyed and used, which are outside the scope of this 925 document. This document is intended to serve only as a set of 926 guidelines as to which elements MUST or SHOULD be implemented by 927 systems wishing to perform location dependent routing. The 928 ramification of such recommendations is that they extend to devices 929 and clients that wish to make use of such services. 931 7. IANA Considerations 933 This document does not introduce any IANA considerations. 935 8. Acknowledgments 937 The authors would like to thank the GEOPRIV working group for their 938 discussions in the context of PIDF-LO, in particular Carl Reed, Ron 939 Lake, James Polk, Henning Schulzrinne, Jerome Grenier, Roger Marshall 940 and Robert Sparks. Furthermore, we would like to thank Jon Peterson 941 as the author of PIDF-LO and Nadine Abbott for her constructive 942 comments in clarifying some aspects of the document. 944 9. References 946 9.1. Normative references 948 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 949 Levels", BCP 14, RFC 2119, March 1997. 951 [2] Peterson, J., "A Presence-based GEOPRIV Location Object Format", 952 RFC 4119, December 2005. 954 [3] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006. 956 [4] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape Application 957 Schema for use by the Internet Engineering Task Force (IETF)", 958 Candidate OpenGIS Implementation Specification 06-142, Version: 959 0.0.9, December 2006. 961 9.2. Informative References 963 [5] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 964 and DHCPv6) Option for Civic Addresses Configuration 965 Information", RFC 4776, November 2006. 967 [6] Thomson, M. and J. Winterbottom, "Revised Civic Location Format 968 for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in 969 progress), February 2007. 971 [7] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 972 Polk, "Geopriv Requirements", RFC 3693, February 2004. 974 [8] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 975 Configuration Protocol Option for Coordinate-based Location 976 Configuration Information", RFC 3825, July 2004. 978 [9] "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project; 979 Technical Specification Group Code Network; Universal Geographic 980 Area Description (GAD)". 982 Authors' Addresses 984 James Winterbottom 985 Andrew Corporation 986 Wollongong 987 NSW Australia 989 Email: james.winterbottom@andrew.com 991 Martin Thomson 992 Andrew Corporation 993 Wollongong 994 NSW Australia 996 Email: martin.thomson@andrew.com 998 Hannes Tschofenig 999 Nokia Siemens Networks 1000 Otto-Hahn-Ring 6 1001 Munich, Bavaria 81739 1002 Germany 1004 Email: Hannes.Tschofenig@nsn.com 1005 URI: http://www.tschofenig.com 1007 Full Copyright Statement 1009 Copyright (C) The IETF Trust (2007). 1011 This document is subject to the rights, licenses and restrictions 1012 contained in BCP 78, and except as set forth therein, the authors 1013 retain all their rights. 1015 This document and the information contained herein are provided on an 1016 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1017 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1018 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1019 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1020 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1021 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1023 Intellectual Property 1025 The IETF takes no position regarding the validity or scope of any 1026 Intellectual Property Rights or other rights that might be claimed to 1027 pertain to the implementation or use of the technology described in 1028 this document or the extent to which any license under such rights 1029 might or might not be available; nor does it represent that it has 1030 made any independent effort to identify any such rights. Information 1031 on the procedures with respect to rights in RFC documents can be 1032 found in BCP 78 and BCP 79. 1034 Copies of IPR disclosures made to the IETF Secretariat and any 1035 assurances of licenses to be made available, or the result of an 1036 attempt made to obtain a general license or permission for the use of 1037 such proprietary rights by implementers or users of this 1038 specification can be obtained from the IETF on-line IPR repository at 1039 http://www.ietf.org/ipr. 1041 The IETF invites any interested party to bring to its attention any 1042 copyrights, patents or patent applications, or other proprietary 1043 rights that may cover technology that may be required to implement 1044 this standard. Please address the information to the IETF at 1045 ietf-ipr@ietf.org. 1047 Acknowledgment 1049 Funding for the RFC Editor function is provided by the IETF 1050 Administrative Support Activity (IASA).