idnits 2.17.1 draft-ietf-geopriv-pdif-lo-profile-06.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 799. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 810. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 817. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 823. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 55: '... GML that MUST be implemented by app...' RFC 2119 keyword, line 155: '... geopriv element MUST describe a discr...' RFC 2119 keyword, line 158: '...ocation description SHOULD reside in a...' RFC 2119 keyword, line 162: '... document (PIDF) MUST only be done if ...' RFC 2119 keyword, line 167: '... info> element SHOULD be avoided whe...' (9 more instances...) 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. -- 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 (March 5, 2007) is 6259 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: '10' is defined on line 757, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 4676 (ref. '3') (Obsoleted by RFC 4776) == Outdated reference: A later version (-07) exists of draft-ietf-geopriv-revised-civic-lo-05 ** Downref: Normative reference to an Informational RFC: RFC 3693 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Obsolete informational reference (is this intentional?): RFC 3825 (ref. '10') (Obsoleted by RFC 6225) Summary: 5 errors (**), 0 flaws (~~), 4 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 Expires: September 6, 2007 Andrew Corporation 5 H. Tschofenig 6 Siemens Networks GmbH & Co KG 7 March 5, 2007 9 GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations 10 draft-ietf-geopriv-pdif-lo-profile-06.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 September 6, 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 PIDF-LO. This 53 document makes recommendations on how to constrain, represent and 54 interpret locations in a PIDF-LO. It further recommends a subset of 55 GML that MUST be implemented by applications involved in location 56 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. Complex Shape Examples . . . . . . . . . . . . . . . . . . 12 70 5.2.1. Polygon Representation and Usage . . . . . . . . . . . 12 71 5.2.2. Prism Representation and Usage . . . . . . . . . . . . 14 72 5.2.3. Arc Band Respresentation and Usage . . . . . . . . . . 16 73 5.2.4. Ellipsoid Representation and Usage . . . . . . . . . . 18 74 5.3. Emergency Shape Representations . . . . . . . . . . . . . 20 75 6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 22 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 78 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 80 10.1. Normative references . . . . . . . . . . . . . . . . . . . 26 81 10.2. Informative References . . . . . . . . . . . . . . . . . . 26 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 83 Intellectual Property and Copyright Statements . . . . . . . . . . 28 85 1. Introduction 87 The Presence Information Data Format Location Object (PIDF-LO) [2] is 88 the IETF 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 GMLv3, or as 91 civic location information [4]. A GML profile for expressing 92 geodetic shapes in a PIDF-LO is described in [6]. Uses for PIDF-LO 93 are envisioned in the context of numerous location based 94 applications. This document makes recommendations for formats and 95 conventions to make interoperability less problematic. 97 2. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [1]. 103 The definition for "Target" is taken from [5]. 105 In this document a "discrete location" is defined as a place, point, 106 area or volume in which a Target can be found. It must be described 107 with sufficient precision to address the requirements of an intended 108 application. 110 The term "location complex" is used to describe location information 111 represented by a composite of both civic and geodetic information. 112 An example of a location complex might be a geodetic polygon 113 describing the perimeter of a building and a civic element 114 representing the floor in the building. 116 3. Using Location Information 118 The PIDF format provides for an unbounded number of tuples. The 119 geopriv element resides inside the status component of a tuple, hence 120 a single PIDF document may contain an arbitrary number of location 121 objects some or all of which may be contradictory or complementary. 122 The actual location information is contained inside a 123 element, and there may be one or more actual locations described 124 inside the element. 126 Graphically, the structure of the PIDF-LO can be depicted as follows: 128 PIDF document 129 tuple 1 130 status 131 geopriv 132 location-info 133 civicAddress 134 geodetic 135 location... 136 usage-rules 137 geopriv 2 138 geopriv 3 139 . 140 . 141 . 143 tuple 2 144 tuple 3 146 All of these potential sources and storage places for location lead 147 to confusion for the generators, conveyors and users of location 148 information. Practical experience within the United States National 149 Emergency Number Association (NENA) in trying to solve these 150 ambiguities led to a set of conventions being adopted. These rules 151 do not have any particular order, but should be followed by creators 152 and users of location information contained in a PIDF-LO to ensure 153 that a consistent interpretation of the data can be achieved. 155 Rule #1: A geopriv element MUST describe a discrete location. 157 Rule #2: Where a discrete location can be uniquely described in more 158 than one way, each location description SHOULD reside in a 159 separate tuple. 161 Rule #3: Providing more than one location in a single presence 162 document (PIDF) MUST only be done if all objects describe the same 163 location. This may occur if a Target's location is determined 164 using a series of different techniques. 166 Rule #4: Providing more than one location in a single element SHOULD be avoided where possible. 169 Rule #5: When providing more than one location in a single 170 element the locations MUST be provided by a common 171 source at the same time and by the same method. 173 Rule #6: Providing more than one location in a single element SHOULD only be done if they form a complex to 175 describe the same location. For example, a geodetic location 176 describing a point, and a civic location indicating the floor in a 177 building. 179 Rule #7: Where a location complex is provided in a single element, the coarse location information MUST be provided 181 first. For example, a geodetic location describing an area, and a 182 civic location indicating the floor should be represented with the 183 area first followed by the civic location. 185 Rule #8: Where a PIDF document contains more than one tuple 186 containing a status element with a geopriv location element , the 187 priority of tuples SHOULD be based on tuple position within the 188 PIDF document. That is to say, the tuple with the highest 189 priority location occurs earliest in the PIDF document. 191 Rule #9: Where multiple PIDF documents can be sent or received 192 together, say in a multi-part MIME body, and current location 193 information is required by the recipient, then document selection 194 SHOULD be based on document order, with the first document be 195 considered first. 197 The following examples illustrate the application of these rules. 199 3.1. Single Civic Location Information 201 Jane is at a coffee shop on the ground floor of a large shopping 202 mall. Jane turns on her laptop and connects to the coffee-shop's 203 WiFi hotspot, Jane obtains a complete civic address for her current 204 location, for example using the DHCP civic mechanism defined in [3]. 205 A Location Object is constructed consisting of a single PIDF 206 document, with a single geopriv tuple, and a single location residing 207 in the element. This document is unambiguous, and 208 should be interpreted consistently by receiving nodes if sent over 209 the network. 211 3.2. Civic and Geospatial Location Information 213 Mike is visiting his Seattle office and connects his laptop into the 214 Ethernet port in a spare cube. In this case the location is a 215 geodetic location, with the altitude represented as a building floor 216 number. Mike's main location is the point specified by the geodetic 217 coordinates. Further, Mike is on the second floor of the building 218 located at these coordinates. Applying rules #6 and #7 are applied, 219 the PIDF-LO document creates a complex as shown below. 221 222 227 228 229 230 231 -43.5723 153.21760 233 234 235 2 236 237 238 239 240 241 2003-06-22T20:57:29Z 242 243 245 3.3. Manual/Automatic Configuration of Location Information 247 Loraine has a predefined civic location stored in her laptop, since 248 she normally lives in Sydney, the address is for her Sydney-based 249 apartment. Loraine decides to visit sunny San Francisco, and when 250 she gets there she plugs in her laptop and makes a call. Loraine's 251 laptop receives a new location from the visited network in San 252 Francisco. As this system cannot be sure that the pre-existing, and 253 new location, describe the same place, Loraine's computer generates a 254 new PIDF-LO and will use this to represent Loraine's location. If 255 Loraine's computer were to add the new location to her existing PIDF 256 location document (breaking rule #3), then the correct information 257 may still be interpreted by location recipient providing Loraine's 258 system applies rule #9. In this case the resulting order of location 259 information in the PIDF document should be San Francisco first, 260 followed by Sydney. Since the information is provided by different 261 sources, rule #8 should also be applied and the information placed in 262 different tuples with the tuple containing the San Francisco location 263 first. 265 4. Geodetic Coordinate Representation 267 The geodetic examples provided in RFC 4119 [2] are illustrated using 268 the gml:location element which uses the gml:coordinates elements 269 (inside the gml:Point element) and this representation has several 270 drawbacks. Firstly, it has been deprecated in later versions of GML 271 (3.1 and beyond) making it inadvisable to use for new applications. 272 Secondly, the format of the coordinates type is opaque and so can be 273 difficult to parse and interpret to ensure consistent results, as the 274 same geodetic location can be expressed in a variety of ways. The 275 PIDF-LO Geodetic Shapes specification [6] provides a specific GML 276 profile for expressing commonly used shapes using simple GML 277 representations. The shapes defined in [6] are the recommended 278 shapes to ensure interoperability between location based 279 applications. 281 5. Geodetic Shape Representation 283 The cellular mobile world today makes extensive use of geodetic based 284 location information for emergency and other location-based 285 applications. Generally these locations are expressed as a point 286 (either in two or three dimensions) and an area or volume of 287 uncertainty around the point. In theory, the area or volume 288 represents a coverage in which the user has a relatively high 289 probability of being found, and the point is a convenient means of 290 defining the centroid for the area or volume. In practice, most 291 systems use the point as an absolute value and ignore the 292 uncertainty. It is difficult to determine if systems have been 293 implemented in this manner for simplicity, and even more difficult to 294 predict if uncertainty will play a more important role in the future. 295 An important decision is whether an uncertainty area should be 296 specified. 298 The PIDF-LO Geodetic Shapes specification [6] defines eight shape 299 types most of which are easily translated into shapes definitions 300 used in other applications and protocols, such as Open Mobile 301 Alliance (OMA) Mobile Location Protocol (MLP). For completeness the 302 shapes defined in [6] are listed below: 304 o Point (2d or 3d) 306 o Polygon (2d) 308 o Circle (2d) 310 o Ellipse (2d) 312 o Arc band (2d) 314 o Sphere (3d) 316 o Ellipsoid (3d) 318 o Prism (3d) 320 The GeoShape specification [6] also describes a standard set of 321 coordinate reference systems (CRS), unit of measure (UoM) and 322 conventions relating to lines and distances. GeoShape mandates the 323 use the WGS-84 Coordinate reference system and restricts usage to 324 EPSG-4326 for two dimensional (2d) shape representations and EPSG- 325 4979 for three dimensional (3d) volume representations. Distance and 326 heights are expressed in meters using EPSG-9001. 328 It is RECOMMENDED that where uncertainty is included, a confidence of 329 68% (or one standard deviation) is used. Specifying a convention for 330 confidence enables better use of uncertainty values. 332 5.1. Polygon Restrictions 334 The Polygon shape type defined in [6] intentionally does not place 335 any constraints on the number of vertices that may be included to 336 define the bounds of the Polygon. This allows arbitrarily complex 337 shapes to be defined and conveyed in a PIDF-LO. However where 338 location information is to be used in real-time processing 339 applications, such as location dependent routing, having arbitrarily 340 complex shapes consisting of tens or even hundreds of points could 341 result in significant performance impacts. To mitigate this risk it 342 is recommended that Polygons be restricted to a maximum of 15 343 discrete points (16 including the repeated point) when the location 344 information is intended for use in real-time applications. This 345 limit of 15 points is chosen to allow moderately complex shape 346 definitions while at the same time enabling interoperation with other 347 location transporting protocols such as those defined in 3GPP ([7]) 348 and OMA where the 15 point limit is already imposed. 350 Polygons are defined with the minimum distance between two adjacent 351 vertices (geodesic). A connecting line SHALL NOT cross another 352 connecting line of the same Polygon. Polygons SHOULD be defined with 353 the upward normal pointing up, this is accomplished by defining the 354 vertices in counter-clockwise direction. 356 Points specified in a polygon must be coplanar, and it is recommended 357 that where points are specified in 3 dimensions that all points 358 maintain the same altitude. 360 5.2. Complex Shape Examples 362 This section provides some examples of where some of the more complex 363 shapes are used, how they are determined, and how they are 364 represented in a PIDF-LO. Complete details on all of the Geoshape 365 types are provided in [6]. 367 5.2.1. Polygon Representation and Usage 369 The polygon shape may be used to represent a building outline or 370 coverage area. The first and last points of the polygon must be the 371 same to form a closed shape. For example looking at the octagon 372 below with vertices, A,H,G,F,E,D,C,B,A. The resulting polygon will be 373 defined with 9 points, with the first and last points both having the 374 coordinates of point A. 376 B-------------C 377 / \ 378 / \ 379 / \ 380 A D 381 | | 382 | | 383 | | 384 | | 385 H E 386 \ / 387 \ / 388 \ / 389 G--------------F 391 392 398 399 400 401 402 403 404 405 43.311 -73.422 406 43.211 -73.422 407 43.111 -73.322 408 43.111 -73.222 409 43.211 -73.122 410 43.311 -73.122 411 43.411 -73.222 412 43.411 -73.322 413 43.311 -73.422 414 415 416 417 418 419 420 421 2007-06-22T20:57:29Z 422 423 425 5.2.2. Prism Representation and Usage 427 A prsim may be used to represent a section of a building or range of 428 floors of building. The prism extrudes a polygon by providing a 429 height element. It consists of a base made up of coplanar 3 points 430 defined in 3 dimensions all at the same altitude. The prism is then 431 an extrusion from this base to the value specified in the height 432 element. If the height is negative, then the prism is extruded from 433 the top down, while a positive height extrudes from the bottom up. 434 The first and last points of the polygon must be the same to form a 435 closed shape. 437 For example looking at the cube below. If the prism is extruded from 438 the bottom up, then the polygon forming the base of the prism is 439 defined with the points A, B, C, D, A. The height of the prism is the 440 distance between point A and point E in meters. The resulting 441 PIDF-LO is provided below. 443 G-----F 444 /| /| 445 / | / | 446 H--+--E | 447 | C--|--B 448 | / | / 449 |/ |/ 450 D-----A 452 453 459 460 461 462 463 464 465 466 467 468 469 42.556844 -73.248157 36.6 470 42.656844 -73.248157 36.6 471 42.656844 -73.348157 36.6 472 42.556844 -73.348157 36.6 473 42.556844 -73.248157 36.6 474 475 476 477 478 479 480 2.4 481 482 483 484 485 486 487 2007-06-22T20:57:29Z 488 489 491 5.2.3. Arc Band Respresentation and Usage 493 The arc band shape type is commonly generated in wireless systems 494 where timing advance or code offsets sequences are used to compensate 495 for distances between handsets and the access point. The arc band is 496 represented as two radii emanating from a central point, and two 497 angles which represent the starting angle and the opening angle of 498 the arc. In a cellular environment the central point is nominally 499 the location of the cell tower, the two radii are determined by the 500 extent of the timing advance, and the two angles are generally 501 provisioned information. 503 For example, Paul is using a cellular wireless device and is 7 timing 504 advance symbols away from the cell tower. For a GSM-based network 505 this would place Paul roughly between 3,594 meters and 4,148 meters 506 from the cell tower, providing the inner and outer radius values. If 507 the start angle is 20 degrees from north, and the opening angle is 508 120 degrees, an arc band representing Paul's location would look 509 similar to the figure below. 511 N ^ ,.__ 512 | a(s) / `-. 513 | 20 / `-. 514 |--. / `. 515 | `/ \ 516 | /__ \ 517 | . `-. \ 518 | . `. \ 519 |. \ \ . 520 ---c-- a(o) -- | | --> 521 |. / 120 ' | E 522 | . / ' 523 | . / ; 524 .,' / 525 r(i)`. / 526 (3594m) `. / 527 `. ,' 528 `. ,' 529 r(o)`' 530 (4148m) 532 The resulting PIDF-LO is reflected below. 534 535 541 542 543 544 545 546 547 -43.5723 153.21760 548 549 550 3594 551 552 553 4148 554 555 556 20 557 558 559 20 560 561 562 563 564 565 566 2003-06-22T20:57:29Z 567 568 570 An important note to make on the arc band is that the center point 571 used in the definition of the shape is not included in resulting 572 enclosed area, and that Target may be anywhere in the defined area of 573 the arc band. 575 5.2.4. Ellipsoid Representation and Usage 577 The ellipsoid is the volume most commonly produced by GPS systems. 578 It is used extensively in navigation systems and wireless location 579 networks. The ellipsoid is constructed around a central point 580 specified in three dimensions, and three axies perpendicular to one 581 another are extended outwards from this point. These axies are 582 defined as the semi-major (M) axis, the semi-minor (m) axis, and the 583 vertical (v) axis respectively. An angle is used to express the 584 orientation of the ellipsoid. The orientation angle is measured in 585 degrees from north, and represents the direction of the semi-major 586 axis from the center point. 588 \ 589 _.-\""""^"""""-._ 590 .' \ | `. 591 / v m \ 592 | \ | | 593 | -c ----M---->| 594 | | 595 \ / 596 `._ _.' 597 `-...........-' 599 A PIDF-LO containing an ellipsoid would like something like the 600 sample below. 602 603 609 610 611 612 613 614 615 42.5463 -73.2512 26.3 616 617 618 7.7156 619 620 621 3.31 622 623 624 28.7 625 626 627 90 628 629 630 631 632 633 634 2003-06-22T20:57:29Z 635 636 638 5.3. Emergency Shape Representations 640 In some parts of the world cellular networks constraints are placed 641 on the shape types that can be used to represent the location of an 642 emergency caller. These restrictions, while to some extend are 643 artificial, may pose significant interoperability problems in 644 emergency networks were they to be unilaterally lifted. The largest 645 impact likely being on Public Safety Answer Point (PSAP) where 646 multiple communication networks report emergency data. Wholesale 647 swap-out or upgrading of this equipment is deemed to be complex and 648 costly and has resulted in a number of countries, most notably the 649 United States, to adopt migratory standards towards emergency IP 650 telephony support. Where these migratory standards are implemented 651 restrictions on acceptable geodetic shape types to represent the 652 location of an emergency caller may exist. Conversion from one shape 653 type to another should be avoided to eliminate the introduction of 654 errors in reported location. 656 In North America the migratory VoIP emergency services standard (i2) 657 [8] reuses the NENA E2 interface [9] which restriction geodetic shape 658 representation to a point, a point with an uncertain circle, a point 659 with an altitude and an uncertainty circle. The NENA recommended 660 shapes can be represented in a PIDF-LO using the GeoShape Point, 661 GeoShape Circle, and GeoShape Sphere definitions respectively. 663 6. Recommendations 665 As a summary, this document gives a few recommendations on the usage 666 of location information in PIDF-LO. Nine rules specified in 667 Section 3 give guidelines on avoiding ambiguity in PIDF-LO 668 interpretations when multiple locations may be provided to a Target 669 or location recipient. 671 It is recommended that only the shape types and shape representations 672 described in [6] be used to express geodetic locations for exchange 673 between general applications. By standardizing geodetic data 674 representation interoperability issues are mitigated. 676 It is recommended that GML Polygons be restricted to a maximum of 16 677 points when used in location-dependent routing and other real-time 678 applications to mitigate possible performance issues. This allows 679 for interoperability with other location protocols where this 680 restriction applies. 682 Geodetic location may require restricted shape definitions in regions 683 where migratory emergency IP telephony implementations are deployed. 684 Where the acceptable shape types are not understood restrictions to 685 Point, Circle and Sphere representations should be used to 686 accommodate most existing deployments. 688 Conversions from one geodetic shape type to another should be avoided 689 where data is considered critical and the introduction of errors 690 considered unacceptable. 692 In the absence of any application specific knowledge shapes and 693 volumes should assumed to have a corresponding confidence value of 694 68% when associated representing a Target's location. 696 7. Security Considerations 698 The primary security considerations relate to how location 699 information is conveyed and used, which are outside the scope of this 700 document. This document is intended to serve only as a set of 701 guidelines as to which elements MUST or SHOULD be implemented by 702 systems wishing to perform location dependent routing. The 703 ramification of such recommendations is that they extend to devices 704 and clients that wish to make use of such services. 706 8. IANA Considerations 708 This document does not introduce any IANA considerations. 710 9. Acknowledgments 712 The authors would like to thank the GEOPRIV working group for their 713 discussions in the context of PIDF-LO, in particular Carl Reed, Ron 714 Lake, James Polk and Henning Schulzrinne. Furthermore, we would like 715 to thank Jon Peterson as the author of PIDF-LO and Nadine Abbott for 716 her constructive comments in clarifying some aspects of the document. 718 10. References 720 10.1. Normative references 722 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 723 Levels", March 1997. 725 [2] Peterson, J., "A Presence-based GEOPRIV Location Object 726 Format", RFC 4119, December 2005. 728 [3] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 729 and DHCPv6) Option for Civic Addresses Configuration 730 Information", RFC 4676, October 2006. 732 [4] Thomson, M. and J. Winterbottom, "Revised Civic Location Format 733 for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in 734 progress), February 2007. 736 [5] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 737 Polk, "Geopriv Requirements", RFC 3693, February 2004. 739 [6] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape Application 740 Schema for use by the Internet Engineering Task Force (IETF)", 741 Candidate OpenGIS Implementation Specification 06-142, Version: 742 0.0.9, December 2006. 744 10.2. Informative References 746 [7] "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project; 747 Technical Specification Group Code Network; Universal 748 Geographic Area Description (GAD)". 750 [8] "abbrev"i2">NENA VoIP-Packet Technical Committee, Interim VoIP 751 Architecture for Enhanced 9-1-1 Services (i2), NENA 08-001, Dec 752 2005". 754 [9] "NENA Standard for the Implementation of the Wireless Emergency 755 Service Protocol E2 Interface, NENA 05-001, Dec 2003". 757 [10] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 758 Configuration Protocol Option for Coordinate-based Location 759 Configuration Information", RFC 3825, July 2004. 761 Authors' Addresses 763 James Winterbottom 764 Andrew Corporation 765 Wollongong 766 NSW Australia 768 Email: james.winterbottom@andrew.com 770 Martin Thomson 771 Andrew Corporation 772 Wollongong 773 NSW Australia 775 Email: martin.thomson@andrew.com 777 Hannes Tschofenig 778 Siemens Networks GmbH & Co KG 779 Otto-Hahn-Ring 6 780 Munich, Bavaria 81739 781 Germany 783 Email: Hannes.Tschofenig@siemens.com 785 Full Copyright Statement 787 Copyright (C) The IETF Trust (2007). 789 This document is subject to the rights, licenses and restrictions 790 contained in BCP 78, and except as set forth therein, the authors 791 retain all their rights. 793 This document and the information contained herein are provided on an 794 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 795 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 796 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 797 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 798 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 799 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 801 Intellectual Property 803 The IETF takes no position regarding the validity or scope of any 804 Intellectual Property Rights or other rights that might be claimed to 805 pertain to the implementation or use of the technology described in 806 this document or the extent to which any license under such rights 807 might or might not be available; nor does it represent that it has 808 made any independent effort to identify any such rights. Information 809 on the procedures with respect to rights in RFC documents can be 810 found in BCP 78 and BCP 79. 812 Copies of IPR disclosures made to the IETF Secretariat and any 813 assurances of licenses to be made available, or the result of an 814 attempt made to obtain a general license or permission for the use of 815 such proprietary rights by implementers or users of this 816 specification can be obtained from the IETF on-line IPR repository at 817 http://www.ietf.org/ipr. 819 The IETF invites any interested party to bring to its attention any 820 copyrights, patents or patent applications, or other proprietary 821 rights that may cover technology that may be required to implement 822 this standard. Please address the information to the IETF at 823 ietf-ipr@ietf.org. 825 Acknowledgment 827 Funding for the RFC Editor function is provided by the IETF 828 Administrative Support Activity (IASA).