idnits 2.17.00 (12 Aug 2021) /tmp/idnits65084/draft-ietf-geopriv-pdif-lo-profile-07.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 981. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 992. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 999. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1005. 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 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 169: '...geopriv> element MUST describe a discr...' RFC 2119 keyword, line 172: '...ocation description SHOULD reside in a...' RFC 2119 keyword, line 176: '... document (PIDF) MUST only be done if ...' RFC 2119 keyword, line 183: '...on-info> element SHOULD be avoided whe...' RFC 2119 keyword, line 187: '...nt the locations MUST be provided by a...' (17 more instances...) -- 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 ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [1], but that reference does not seem to mention RFC 2119 either. (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 (April 28, 2007) is 5502 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: '7' is defined on line 934, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: draft-ietf-geopriv-revised-civic-lo has been published as RFC 5139 -- Obsolete informational reference (is this intentional?): RFC 3825 (ref. '7') (Obsoleted by RFC 6225) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 11 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: October 30, 2007 Nokia Siemens Networks 7 April 28, 2007 9 GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations 10 draft-ietf-geopriv-pdif-lo-profile-07.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 October 30, 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 successfully 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 . . . . . . . . . . . . . . . . . . . . . . . . 15 73 5.2.4. Ellipse . . . . . . . . . . . . . . . . . . . . . . . 16 74 5.2.5. Arc Band . . . . . . . . . . . . . . . . . . . . . . . 18 75 5.2.6. Sphere . . . . . . . . . . . . . . . . . . . . . . . . 19 76 5.2.7. Ellipsoid . . . . . . . . . . . . . . . . . . . . . . 20 77 5.2.8. Prism . . . . . . . . . . . . . . . . . . . . . . . . 22 78 6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 25 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 81 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 83 10.1. Normative references . . . . . . . . . . . . . . . . . . . 29 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 86 Intellectual Property and Copyright Statements . . . . . . . . . . 31 88 1. Introduction 90 The Presence Information Data Format Location Object (PIDF-LO) [2] is 91 the recommended way of encoding location information and associated 92 privacy policies. Location information in a PIDF-LO may be described 93 in a geospatial manner based on a subset of GMLv3, or as civic 94 location information [5]. A GML profile for expressing geodetic 95 shapes in a PIDF-LO is described in [3]. Uses for PIDF-LO are 96 envisioned in the context of numerous location based applications. 97 This document makes recommendations for formats and conventions to 98 make interoperability less problematic. 100 2. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [1]. 106 The definition for "Target" is taken from [6]. 108 In this document a "discrete location" is defined as a place, point, 109 area or volume in which a Target can be found. It must be described 110 with sufficient precision to address the requirements of an intended 111 application. 113 The term "compound location" is used to describe location information 114 represented by a composite of both civic and geodetic information. 115 An example of compound location might be a geodetic polygon 116 describing the perimeter of a building and a civic element 117 representing the floor in the building. 119 3. Using Location Information 121 The PIDF format provides for an unbounded number of elements. 122 Each element contains a single element that may 123 contain more than one element as a child element. Each 124 element must contain at least the following two child 125 elements: element and element. One or 126 more chunks of location information are contained inside a element. 129 Hence, a single PIDF document may contain an arbitrary number of 130 location objects some or all of which may be contradictory or 131 complementary. Graphically, the structure of a PIDF-LO document can 132 be depicted as shown in Figure 1. 134 135 136 -- #1 137 138 -- #1 139 140 location chunk #1 141 location chunk #2 142 ... 143 location chunk #n 144 145 146 -- #2 147 -- #3 148 ... 149 -- #m 150 151 152 -- #2 153 -- #3 154 ... 155 -- #o 156 158 Figure 1: Structure of a PIDF-LO Document 160 All of these potential sources and storage places for location lead 161 to confusion for the generators, conveyors and consumers of location 162 information. Practical experience within the United States National 163 Emergency Number Association (NENA) in trying to solve these 164 ambiguities led to a set of conventions being adopted. These rules 165 do not have any particular order, but should be followed by creators 166 and consumers of location information contained in a PIDF-LO to 167 ensure that a consistent interpretation of the data can be achieved. 169 Rule #1: A element MUST describe a discrete location. 171 Rule #2: Where a discrete location can be uniquely described in more 172 than one way, each location description SHOULD reside in a 173 separate element. 175 Rule #3: Providing more than one location chunk in a single presence 176 document (PIDF) MUST only be done if all objects refer to the same 177 place. 179 This may occur if a Target's location is determined using a 180 series of different techniques. 182 Rule #4: Providing more than one location chunk in a single 183 element SHOULD be avoided where possible. Rule #5 184 and Rule #6 provide further refinement. 186 Rule #5: When providing more than one location chunk in a single 187 element the locations MUST be provided by a common 188 source at the same time and by the same location determination 189 method. 191 Rule #6: Providing more than one location chunk in a single 192 element SHOULD only be used for representing 193 compound location referring to the same place. 195 For example, a geodetic location describing a point, and a 196 civic location indicating the floor in a building. 198 Rule #7: Where compound location is provided in a single element, the coarse location information MUST be provided 200 first. 202 For example, a geodetic location describing an area, and a 203 civic location indicating the floor should be represented with 204 the area first followed by the civic location. 206 Rule #8: Where a PIDF document contains more than one 207 element containing a element with a element, 208 the priority of tuples SHOULD be based on position of the 209 element within the PIDF document. That is to say, the tuple with 210 the highest priority location occurs earliest in the PIDF 211 document. 213 Rule #9: Where multiple PIDF documents can be sent or received 214 together, say in a multi-part MIME body, and current location 215 information is required by the recipient, then document selection 216 SHOULD be based on document order, with the first document be 217 considered first. 219 The following examples illustrate the application of these rules. 221 3.1. Single Civic Location Information 223 Jane is at a coffee shop on the ground floor of a large shopping 224 mall. Jane turns on her laptop and connects to the coffee-shop's 225 WiFi hotspot, Jane obtains a complete civic address for her current 226 location, for example using the DHCP civic mechanism defined in [4]. 227 A Location Object is constructed consisting of a single PIDF 228 document, with a single element, a single element, a 229 single element, and a single location chunk residing in the 230 element. This document is unambiguous, and should be 231 interpreted consistently by receiving nodes if sent over the network. 233 3.2. Civic and Geospatial Location Information 235 Mike is visiting his Seattle office and connects his laptop into the 236 Ethernet port in a spare cube. In this case location information is 237 geodetic location, with the altitude represented as a building floor 238 number. Mike's main location is the point specified by the geodetic 239 coordinates. Further, Mike is on the second floor of the building 240 located at these coordinates. Applying rules #6 and #7 are applied, 241 the resulting compound location information is shown below. 243 244 249 250 251 252 253 -43.5723 153.21760 255 256 257 2 258 259 260 261 262 263 2003-06-22T20:57:29Z 264 265 267 3.3. Manual/Automatic Configuration of Location Information 269 Loraine has a predefined civic location stored in her laptop, since 270 she normally lives in Sydney, the address is for her Sydney-based 271 apartment. Loraine decides to visit sunny San Francisco, and when 272 she gets there she plugs in her laptop and makes a call. Loraine's 273 laptop receives a new location from the visited network in San 274 Francisco. As this system cannot be sure that the pre-existing, and 275 new location, describe the same place, Loraine's computer generates a 276 new PIDF-LO and will use this to represent Loraine's location. If 277 Loraine's computer were to add the new location to her existing PIDF 278 location document (breaking rule #3), then the correct information 279 may still be interpreted by the Location Recipient providing 280 Loraine's system applies rule #9. In this case the resulting order 281 of location information in the PIDF document should be San Francisco 282 first, followed by Sydney. Since the information is provided by 283 different sources, rule #8 should also be applied and the information 284 placed in different tuples with the tuple containing the San 285 Francisco location first. 287 4. Geodetic Coordinate Representation 289 The geodetic examples provided in RFC 4119 [2] are illustrated using 290 the element, which uses the element 291 inside the element and this representation has several 292 drawbacks. Firstly, it has been deprecated in later versions of GML 293 (3.1 and beyond) making it inadvisable to use for new applications. 294 Secondly, the format of the coordinates type is opaque and so can be 295 difficult to parse and interpret to ensure consistent results, as the 296 same geodetic location can be expressed in a variety of ways. The 297 PIDF-LO Geodetic Shapes specification [3] provides a specific GML 298 profile for expressing commonly used shapes using simple GML 299 representations. The shapes defined in [3] are the recommended 300 shapes to ensure interoperability. 302 5. Geodetic Shape Representation 304 The cellular mobile world today makes extensive use of geodetic based 305 location information for emergency and other location-based 306 applications. Generally these locations are expressed as a point 307 (either in two or three dimensions) and an area or volume of 308 uncertainty around the point. In theory, the area or volume 309 represents a coverage in which the user has a relatively high 310 probability of being found, and the point is a convenient means of 311 defining the centroid for the area or volume. In practice, most 312 systems use the point as an absolute value and ignore the 313 uncertainty. It is difficult to determine if systems have been 314 implemented in this manner for simplicity, and even more difficult to 315 predict if uncertainty will play a more important role in the future. 316 An important decision is whether an uncertainty area should be 317 specified. 319 The PIDF-LO Geodetic Shapes specification [3] defines eight shape 320 types most of which are easily translated into shapes definitions 321 used in other applications and protocols, such as Open Mobile 322 Alliance (OMA) Mobile Location Protocol (MLP). For completeness the 323 shapes defined in [3] are listed below: 325 o Point (2d and 3d) 327 o Polygon (2d) 329 o Circle (2d) 331 o Ellipse (2d) 333 o Arc band (2d) 335 o Sphere (3d) 337 o Ellipsoid (3d) 339 o Prism (3d) 341 All above-listed shapes are mandatory to implement. 343 The GeoShape specification [3] also describes a standard set of 344 coordinate reference systems (CRS), unit of measure (UoM) and 345 conventions relating to lines and distances. The use of the WGS-84 346 coordinate reference system and the usage of EPSG-4326 (as identified 347 by the URN urn:ogc:def:crs:EPSG::4326) for two dimensional (2d) shape 348 representations and EPSG-4979 (as identified by the URN 349 urn:ogc:def:crs:EPSG::4979) for three dimensional (3d) volume 350 representations is mandated. Distance and heights are expressed in 351 meters using EPSG-9001 (as identified by the URN 352 urn:ogc:def:uom:EPSG::9001). Angular measures MUST use either 353 degrees or radians. Measures in degrees MUST be identified by the 354 URN urn:ogc:def:uom:EPSG::9102, measures in radians MUST be 355 identified by the URN urn:ogc:def:uom:EPSG::9101 357 Implementations MUST specify the CRS using the srsName attribute on 358 the outermost geometry element. The CRS MUST NOT be respecified or 359 changed for any sub-elements. The srsDimension attribute SHOULD be 360 omitted, since the number of dimensions in these CRSs is known. A 361 CRS MUST be specified using the above URN notation only, 362 implementations do not need to support user-defined CRSs. 364 It is RECOMMENDED that where uncertainty is included, a confidence of 365 68% (or one standard deviation) is used. Specifying a convention for 366 confidence enables better use of uncertainty values. 368 5.1. Polygon Restrictions 370 The Polygon shape type defined in [3] intentionally does not place 371 any constraints on the number of vertices that may be included to 372 define the bounds of a polygon. This allows arbitrarily complex 373 shapes to be defined and conveyed in a PIDF-LO. However, where 374 location information is to be used in real-time processing 375 applications, such as location dependent routing, having arbitrarily 376 complex shapes consisting of tens or even hundreds of points could 377 result in significant performance impacts. To mitigate this risk it 378 is recommended that Polygon shapes be restricted to a maximum of 15 379 points (16 including the repeated point) when the location 380 information is intended for use in real-time applications. This 381 limit of 15 points is chosen to allow moderately complex shape 382 definitions while at the same time enabling interoperation with other 383 location transporting protocols such as those defined in 3GPP (see 384 [8]) and OMA where the 15 point limit is already imposed. 386 Polygons are defined with the minimum distance between two adjacent 387 vertices (geodesic). A connecting line SHALL NOT cross another 388 connecting line of the same Polygon. Polygons SHOULD be defined with 389 the upward normal pointing up, this is accomplished by defining the 390 vertices in counter-clockwise direction. 392 Points specified in a polygon MUST be coplanar, and it is RECOMMENDED 393 that where points are specified in 3 dimensions that all points 394 maintain the same altitude. 396 5.2. Shape Examples 398 This section provides some examples of where some of the more complex 399 shapes are used, how they are determined, and how they are 400 represented in a PIDF-LO. Complete details on all of the Geoshape 401 types are provided in [3]. 403 5.2.1. Point 405 The point shape type is the simplest form of geodetic LI, which is 406 natively supported by GML. The gml:Point element is used when there 407 is no known uncertainty. A point also forms part of a number of 408 other geometries. A point may be specified using either WGS 84 409 (latitude, longitude) or WGS 84 (latitude, longitude, altitude). The 410 next example shows a 2d point: 412 413 419 420 421 422 423 425 -34.407 150.883 426 427 428 429 430 431 2007-06-22T20:57:29Z 432 433 435 The next example shows a 3d point: 437 438 444 445 446 447 448 450 -34.407 150.883 24.8 451 452 453 454 455 456 2007-06-22T20:57:29Z 457 458 460 5.2.2. Polygon 462 The polygon shape may be used to represent a building outline or 463 coverage area. The first and last points of the polygon have to be 464 the same. For example, looking at the octagon below with vertices, 465 A, H, G, F, E, D, C, B, A. The resulting polygon will be defined with 466 9 points, with the first and last points both having the coordinates 467 of point A. 469 B-------------C 470 / \ 471 / \ 472 / \ 473 A D 474 | | 475 | | 476 | | 477 | | 478 H E 479 \ / 480 \ / 481 \ / 482 G--------------F 484 485 491 492 493 494 495 496 497 498 43.311 -73.422 499 43.211 -73.422 500 43.111 -73.322 501 43.111 -73.222 502 43.211 -73.122 503 43.311 -73.122 504 43.411 -73.222 505 43.411 -73.322 506 43.311 -73.422 507 508 509 510 511 512 513 514 2007-06-22T20:57:29Z 515 516 518 5.2.3. Circle 520 The circular area is used for coordinates in two-dimensional CRSs to 521 describe uncertainty about a point. The definition is based on the 522 one-dimensional geometry in GML, gml:CircleByCenterPoint. The centre 523 point of a circular area is specified by using a two dimensional CRS; 524 in three dimensions, the orientation of the circle cannot be 525 specified correctly using this representation. A point with 526 uncertainty that is specified in three dimensions should use the 527 Sphere shape type. 529 530 536 537 538 539 540 541 542 42.5463 -73.2512 543 544 545 850.24 546 547 548 549 550 551 552 554 5.2.4. Ellipse 556 An elliptical area describes an ellipse in two dimensional space. 557 The ellipse is described by a center point, the length of its semi- 558 major and semi-minor axes, and the orientation of the semi-major 559 axis. Like the circular area (Circle), the ellipse MUST be specified 560 using a two dimensional CRS. 562 563 569 570 571 572 573 574 575 42.5463 -73.2512 576 577 578 1275 579 580 581 670 582 583 584 43.2 585 586 587 588 589 590 591 2003-06-22T20:57:29Z 592 593 595 The gml:pos element indicates the position of the center, or origin, 596 of the ellipse. The gs:semiMajorAxis and gs:semiMinorAxis elements 597 are the length of the semi-major and semi-minor axes respectively. 598 The gs:orientation element is the angle by which the semi-major axis 599 is rotated from the first axis of the CRS towards the second axis. 600 For WGS 84, the orientation indicates rotation from Northing to 601 Easting, which, if specified in degrees, is roughly equivalent to a 602 compass bearing (if magnetic north were the same as the WGS north 603 pole). Note: An ellipse with equal major and minor axis lengths is a 604 circle. 606 5.2.5. Arc Band 608 The arc band shape type is commonly generated in wireless systems 609 where timing advance or code offsets sequences are used to compensate 610 for distances between handsets and the access point. The arc band is 611 represented as two radii emanating from a central point, and two 612 angles which represent the starting angle and the opening angle of 613 the arc. In a cellular environment the central point is nominally 614 the location of the cell tower, the two radii are determined by the 615 extent of the timing advance, and the two angles are generally 616 provisioned information. 618 For example, Paul is using a cellular wireless device and is 7 timing 619 advance symbols away from the cell tower. For a GSM-based network 620 this would place Paul roughly between 3,594 meters and 4,148 meters 621 from the cell tower, providing the inner and outer radius values. If 622 the start angle is 20 degrees from north, and the opening angle is 623 120 degrees, an arc band representing Paul's location would look 624 similar to the figure below. 626 N ^ ,.__ 627 | a(s) / `-. 628 | 20 / `-. 629 |--. / `. 630 | `/ \ 631 | /__ \ 632 | . `-. \ 633 | . `. \ 634 |. \ \ . 635 ---c-- a(o) -- | | --> 636 |. / 120 ' | E 637 | . / ' 638 | . / ; 639 .,' / 640 r(i)`. / 641 (3594m) `. / 642 `. ,' 643 `. ,' 644 r(o)`' 645 (4148m) 647 The resulting PIDF-LO is reflected below. 649 650 656 657 658 659 660 661 662 -43.5723 153.21760 663 664 665 3594 666 667 668 4148 669 670 671 20 672 673 674 20 675 676 677 678 679 680 681 2003-06-22T20:57:29Z 682 683 685 An important note to make on the arc band is that the center point 686 used in the definition of the shape is not included in resulting 687 enclosed area, and that Target may be anywhere in the defined area of 688 the arc band. 690 5.2.6. Sphere 692 The sphere is a volume that provides the same information as a circle 693 in three dimensions. The sphere has to be specified using a three 694 dimensional CRS. The following example shows a sphere shape, which 695 is identical to the circle example, except for the addition of an 696 altitude in the provided coordinates. 698 699 705 706 707 708 709 710 711 42.5463 -73.2512 26.3 712 713 714 850.24 715 716 717 718 719 720 721 723 5.2.7. Ellipsoid 725 The ellipsoid is the volume most commonly produced by GPS systems. 726 It is used extensively in navigation systems and wireless location 727 networks. The ellipsoid is constructed around a central point 728 specified in three dimensions, and three axies perpendicular to one 729 another are extended outwards from this point. These axies are 730 defined as the semi-major (M) axis, the semi-minor (m) axis, and the 731 vertical (v) axis respectively. An angle is used to express the 732 orientation of the ellipsoid. The orientation angle is measured in 733 degrees from north, and represents the direction of the semi-major 734 axis from the center point. 736 \ 737 _.-\""""^"""""-._ 738 .' \ | `. 739 / v m \ 740 | \ | | 741 | -c ----M---->| 742 | | 743 \ / 744 `._ _.' 745 `-...........-' 747 A PIDF-LO containing an ellipsoid would like something like the 748 sample below. 750 751 757 758 759 760 761 762 763 42.5463 -73.2512 26.3 764 765 766 7.7156 767 768 769 3.31 770 771 772 28.7 773 774 775 90 776 777 778 779 780 781 782 2003-06-22T20:57:29Z 783 784 786 5.2.8. Prism 788 A prism may be used to represent a section of a building or range of 789 floors of building. The prism extrudes a polygon by providing a 790 height element. It consists of a base made up of coplanar 3 points 791 defined in 3 dimensions all at the same altitude. The prism is then 792 an extrusion from this base to the value specified in the height 793 element. If the height is negative, then the prism is extruded from 794 the top down, while a positive height extrudes from the bottom up. 795 The first and last points of the polygon have to be the same. 797 For example, looking at the cube below. If the prism is extruded 798 from the bottom up, then the polygon forming the base of the prism is 799 defined with the points A, B, C, D, A. The height of the prism is the 800 distance between point A and point E in meters. The resulting 801 PIDF-LO is provided below. 803 G-----F 804 /| /| 805 / | / | 806 H--+--E | 807 | C--|--B 808 | / | / 809 |/ |/ 810 D-----A 812 813 819 820 821 822 823 824 825 826 827 828 829 42.556844 -73.248157 36.6 830 42.656844 -73.248157 36.6 831 42.656844 -73.348157 36.6 832 42.556844 -73.348157 36.6 833 42.556844 -73.248157 36.6 834 835 836 837 838 839 840 2.4 841 842 843 844 845 846 847 2007-06-22T20:57:29Z 848 849 851 6. Recommendations 853 As a summary, this document gives a few recommendations on the usage 854 of location information in PIDF-LO. Nine rules specified in 855 Section 3 give guidelines on avoiding ambiguity in PIDF-LO 856 interpretations when multiple locations may be provided to a Target 857 or location recipient. 859 It is recommended that only the shape types and shape representations 860 described in [3] be used to express geodetic locations for exchange 861 between general applications. By standardizing geodetic data 862 representation interoperability issues are mitigated. 864 It is recommended that GML Polygons be restricted to a maximum of 16 865 points when used in location-dependent routing and other real-time 866 applications to mitigate possible performance issues. This allows 867 for interoperability with other location protocols where this 868 restriction applies. 870 Geodetic location may require restricted shape definitions in regions 871 where migratory emergency IP telephony implementations are deployed. 872 Where the acceptable shape types are not understood restrictions to 873 Point, Circle and Sphere representations should be used to 874 accommodate most existing deployments. 876 Conversions from one geodetic shape type to another should be avoided 877 where data is considered critical and the introduction of errors 878 considered unacceptable. 880 In the absence of any application specific knowledge shapes and 881 volumes should assumed to have a corresponding confidence value of 882 68% when associated representing a Target's location. 884 7. Security Considerations 886 The primary security considerations relate to how location 887 information is conveyed and used, which are outside the scope of this 888 document. This document is intended to serve only as a set of 889 guidelines as to which elements MUST or SHOULD be implemented by 890 systems wishing to perform location dependent routing. The 891 ramification of such recommendations is that they extend to devices 892 and clients that wish to make use of such services. 894 8. IANA Considerations 896 This document does not introduce any IANA considerations. 898 9. Acknowledgments 900 The authors would like to thank the GEOPRIV working group for their 901 discussions in the context of PIDF-LO, in particular Carl Reed, Ron 902 Lake, James Polk and Henning Schulzrinne. Furthermore, we would like 903 to thank Jon Peterson as the author of PIDF-LO and Nadine Abbott for 904 her constructive comments in clarifying some aspects of the document. 906 10. References 908 10.1. Normative references 910 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 911 Levels", March 1997. 913 [2] Peterson, J., "A Presence-based GEOPRIV Location Object Format", 914 RFC 4119, December 2005. 916 [3] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape Application 917 Schema for use by the Internet Engineering Task Force (IETF)", 918 Candidate OpenGIS Implementation Specification 06-142, Version: 919 0.0.9, December 2006. 921 10.2. Informative References 923 [4] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 924 and DHCPv6) Option for Civic Addresses Configuration 925 Information", RFC 4776, November 2006. 927 [5] Thomson, M. and J. Winterbottom, "Revised Civic Location Format 928 for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in 929 progress), February 2007. 931 [6] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 932 Polk, "Geopriv Requirements", RFC 3693, February 2004. 934 [7] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 935 Configuration Protocol Option for Coordinate-based Location 936 Configuration Information", RFC 3825, July 2004. 938 [8] "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project; 939 Technical Specification Group Code Network; Universal Geographic 940 Area Description (GAD)". 942 Authors' Addresses 944 James Winterbottom 945 Andrew Corporation 946 Wollongong 947 NSW Australia 949 Email: james.winterbottom@andrew.com 951 Martin Thomson 952 Andrew Corporation 953 Wollongong 954 NSW Australia 956 Email: martin.thomson@andrew.com 958 Hannes Tschofenig 959 Nokia Siemens Networks 960 Otto-Hahn-Ring 6 961 Munich, Bavaria 81739 962 Germany 964 Email: Hannes.Tschofenig@nsn.com 965 URI: http://www.tschofenig.com 967 Full Copyright Statement 969 Copyright (C) The IETF Trust (2007). 971 This document is subject to the rights, licenses and restrictions 972 contained in BCP 78, and except as set forth therein, the authors 973 retain all their rights. 975 This document and the information contained herein are provided on an 976 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 977 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 978 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 979 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 980 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 981 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 983 Intellectual Property 985 The IETF takes no position regarding the validity or scope of any 986 Intellectual Property Rights or other rights that might be claimed to 987 pertain to the implementation or use of the technology described in 988 this document or the extent to which any license under such rights 989 might or might not be available; nor does it represent that it has 990 made any independent effort to identify any such rights. Information 991 on the procedures with respect to rights in RFC documents can be 992 found in BCP 78 and BCP 79. 994 Copies of IPR disclosures made to the IETF Secretariat and any 995 assurances of licenses to be made available, or the result of an 996 attempt made to obtain a general license or permission for the use of 997 such proprietary rights by implementers or users of this 998 specification can be obtained from the IETF on-line IPR repository at 999 http://www.ietf.org/ipr. 1001 The IETF invites any interested party to bring to its attention any 1002 copyrights, patents or patent applications, or other proprietary 1003 rights that may cover technology that may be required to implement 1004 this standard. Please address the information to the IETF at 1005 ietf-ipr@ietf.org. 1007 Acknowledgment 1009 Funding for the RFC Editor function is provided by the IETF 1010 Administrative Support Activity (IASA).