idnits 2.17.1 draft-ietf-geopriv-pdif-lo-profile-05.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 on line 1043. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1054. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1061. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1067. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 55: '... GML that MUST be implemented by app...' RFC 2119 keyword, line 233: '... geopriv element MUST describe a discr...' RFC 2119 keyword, line 236: '...ocation description SHOULD reside in a...' RFC 2119 keyword, line 240: '... document (PIDF) MUST only be done if ...' RFC 2119 keyword, line 245: '... info> element SHOULD be avoided whe...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 856 has weird spacing: '... 201 element, and there may be one or more actual locations described 202 inside the element. 204 Graphically, the structure of the PIDF/PIDF-LO can be depicted as 205 follows: 207 PIDF document 208 tuple 1 209 status 210 geopriv 211 location-info 212 civicAddress 213 location 214 usage-rules 215 geopriv 2 216 geopriv 3 217 . 218 . 219 . 221 tuple 2 222 tuple 3 224 All of these potential sources and storage places for location lead 225 to confusion for the generators, conveyors and users of location 226 information. Practical experience within the United States National 227 Emergency Number Association (NENA) in trying to solve these 228 ambiguities led to a set of conventions being adopted. These rules 229 do not have any particular order, but should be followed by creators 230 and users of location information conatined in a PIDF-LO to ensure 231 that a consistent interpretation of the data can be achieved. 233 Rule #1: A geopriv element MUST describe a discrete location. 235 Rule #2: Where a discrete location can be uniquely described in more 236 than one way, each location description SHOULD reside in a 237 separate tuple. 239 Rule #3: Providing more than one location in a single presence 240 document (PIDF) MUST only be done if all objects describe the same 241 location. This may occur if a Target's location is determined 242 using a series of different techniques. 244 Rule #4: Providing more than one location in a single element SHOULD be avoided where possible. 247 Rule #5: When providing more than one location in a single 248 element the locations MUST be provided by a common 249 source. 251 Rule #6: Providing more than one location in a single element SHOULD only be done if they form a complex to 253 describe the same location. For example, a geodetic location 254 describing a point, and a civic location indicating the floor in a 255 building. 257 Rule #7: Where a location complex is provided in a single element, the coarse location information MUST be provided 259 first. For example, a geodetic location describing an area, and a 260 civic location indicating the floor should be represented with the 261 area first followed by the civic location. 263 Rule #8: Where a PIDF document contains more than one tuple 264 containing a status element with a geopriv location element , the 265 priority of tuples SHOULD be based on tuple position within the 266 PIDF document. That is to say, the tuple with the highest 267 priority location occurs earliest in the PIDF document. 269 Rule #9: Where multiple PIDF documents can be sent of received 270 together, say in a multi-part MIME body, and current location 271 information is required by the recipient, then document selection 272 SHOULD be based on document order, with the first document be 273 considered first. 275 The following examples illustrate the application of these rules. 277 5.1. Single Civic Location Information 279 Jane is at a coffee shop on the ground floor of a large shopping 280 mall. Jane turns on her laptop and connects to the coffee-shop's 281 WiFi hotspot, Jane obtains a complete civic address for her current 282 location, for example using the DHCP civic mechanism defined in [4]. 283 A Location Object is constructed consisting of a single PIDF 284 document, with a single geopriv tuple, and a single location residing 285 in the element. This document is unambiguous, and 286 should be interpreted consitently by receiving nodes if sent over the 287 network. 289 5.2. Civic and Geospatial Location Information 291 Mike is visiting his Seattle office and connects his laptop into the 292 Ethernet port in a spare cube. In this case the location is a 293 geodetic location, with the altitude represented as a building floor 294 number. The main location of user is inside the rectangle bounded by 295 the geodetic coordinates specified. Further that the user is on the 296 second floor of the building located at these coordinates. Applying 297 rules #6 and #7 are applied, the PIDF-LO document creates a complex 298 as shown below. 300 301 306 307 308 309 310 312 313 314 37.775 -122.4194 315 37.555 -122.4194 316 37.555 -122.4264 317 37.775 -122.4264 318 37.775 -122.4194 319 320 321 322 323 2 324 325 326 327 328 329 2003-06-22T20:57:29Z 330 331 333 5.3. Manual/Automatic Configuration of Location Information 335 Loraine has a predefined civic location stored in her laptop, since 336 she normally lives in Sydney, the address is her address is for her 337 Sydney-based apartment. Loraine decides to visit sunny San 338 Francisco, and when she gets there she plugs in her laptop and makes 339 a call. Loraine's laptop receives a new location from the visited 340 network in San Francisco. As this system cannot be sure that the 341 pre-existing and new location describe the same place, Loraine's 342 computer generates a new PIDF-LO and will use this to represent 343 Loraine's location. If Loraine's computer were to add the new 344 location to her existing PIDF location document (breaking rule #3), 345 then the correct information may still be interpreted by location 346 recipient providing Loraine's system applies rule #9. In this case 347 the resulting order of location information in the PIDF document 348 should be San Francisco first, followed by Sydney. Since the 349 information is provided by different sources, rule #8 should also be 350 applied and the information placed in different tuples with San 351 Francisco first. 353 6. Geodetic Coordinate Representation 355 The geodetic examples provided in RFC 4119 [2] are illustrated using 356 the gml:location element which uses the gml:coordinates elements 357 (inside the gml:Point element) and this representation has several 358 drawbacks. Firstly, it has been deprecated in later versions of GML 359 (3.1 and beyond) making it inadvisable to use for new applications. 360 Secondly, the format of the coordinates type is opaque and so can be 361 difficult to parse and interpret to ensure consistent results, as the 362 same geodetic location can be expressed in a variety of ways. The 363 PIDF-LO Geodetic Shapes specification [7] provides a specific GML 364 profile for expressing commonly used shapes using simple GML 365 representations. The shapes defined in [7] are the recommended 366 shapes to ensure interoperability between location based 367 applications. 369 7. Geodetic Shape Representation 371 The cellular mobile world today makes extensive use of geodetic based 372 location information for emergency and other location-based 373 applications. Generally these locations are expressed as a point 374 (either in two or three dimensions) and an area or volume of 375 uncertainty around the point. In theory, the area or volume 376 represents a coverage in which the user has a relatively high 377 probability of being found, and the point is a convenient means of 378 defining the centroid for the area or volume. In practice, most 379 systems use the point as an absolute value and ignore the 380 uncertainty. It is difficult to determine if systems have been 381 implement in this manner for simplicity, and even more difficult to 382 predict if uncertainty will play a more important role in the future. 383 An important decision is whether an uncertainty area should be 384 specified. 386 The PIDF-LO Geodetic Shapes specification [7] defines eight shape 387 types most of which are easily translated in shapes definitions used 388 in other applications and protocol, such as Open Mobile Alliance 389 (OMA) Mobile Location Protocol (MLP). For completeness the shape 390 defined in [7] are listed below: 392 o Point (2d or 3d) 394 o Polygon (2d) 396 o Circle (2d) 398 o Ellipse (2d) 400 o Arc band (2d) 402 o Sphere (3d circle) 404 o Ellipsoid (3d) 406 o Prism (3d polygon) 408 The GeoShape specification [7] also describes a standard set of 409 coordinate reference systems (CRS), unit of measure and conventions 410 relating to lines and distances. GeoShape mandates the use the 411 WGS-84 Coordinate reference system and restricts usage to EPSG-4326 412 for two dimensional (2d) shape representations and EPSG-4979 for 413 three dimensional (3d) volume representations. Distance and heights 414 are expressed in meters using EPSG-9001. 416 7.1. Polygon Restriction 418 The Polygon shape type defined in [7] intentionally does not place 419 any constraints on the number of vertices that may be included to 420 define the bounds of the Polygon. This allows arbitrarily complex 421 shapes to be defined and conveyed in a PIDF-LO. However where 422 location information is to be used in real-time processing 423 applications, such as location dependent routing, having arbitrarily 424 complex shapes consisting of tens or even hundreds of points may 425 result in significant performance impacts. To mitigate this risk it 426 is recommended that Polygons be restricted to a maximum of 16 points 427 when the location information is intended for use in real-time 428 applications. This limit of 16 points is chosen to allow moderately 429 complex shape definitions while at the same time enabling 430 interworking with other location transporting protocols such as those 431 defined in 3GPP ([8]) and OMA where the 16 point limit is already 432 imposed. 434 Polygons are defined with the minimum distance between two adjacent 435 vertices (geodesic). A connecting line SHALL NOT cross another 436 connecting line of the same Polygon. Polygons SHOULD be defined with 437 the upward normal pointing up, this is accomplished by defining the 438 vertices in counter-clockwise direction. 440 7.2. Emergency Shape Representations 442 In some parts of the world cellular networks constraints are placed 443 on the shape types that can be used to represent the location of an 444 emergency caller. These restrictions, while to some extend are 445 artificial, may pose significant interoperability problems in 446 emergency networks were they to be unilaterally lifted. The largest 447 impact likely being on Public Safety Answer Point (PSAP) where 448 multiple communication networks report emergency data. Wholesale 449 swap-out or upgrading of this equipment is deemed to be complex and 450 costly and has resulted in a number of countries, most notably the 451 United States, to adopt migratory standards towards emergency IP 452 telephony support. Where these migratory standards are implemented 453 restrictions on acceptable geodetic shape types to represent the 454 location of an emergency caller may exist. Conversion from one shape 455 type to another should be avoided to eliminate the introduction of 456 errors in reported location. 458 In North America the migratory VoIP emergency services standard (i2) 459 [11] reuses the NENA E2 interface [12] which restriction geodetic 460 shape representation to a point, a point with an uncertain circle, a 461 point with an altitude and an uncertainty circle. The NENA 462 recommended shapes can be represented in a PIDF-LO using the GeoShape 463 Point, GeoShape Circle, and GeoShape Sphere definitions respectively. 465 8. Recommendations 467 As a summary, this document gives a few recommendations on the usage 468 of location information in PIDF-LO. Nine rules specified in 469 Section 5 give guidelines on avoiding ambiguity in PIDF-LO 470 interpretations when multiple locations may be provided to a Target 471 or location recipient. 473 It is recommend that only the shape types and shape representations 474 described in [7] be used to express geodetic locations for exchange 475 between general applications. By standardizing geodetic data 476 representation interoperability issues are mitigated. 478 It is recommended that GML Polygons be restricted to a maximum of 16 479 points when used in location-dependent routing and other real-time 480 applications to mitigate possible performance issues. This allows 481 for interoperability with other location protocols where this 482 restriction applies. 484 Geodetic location may require restricted shape definitions in regions 485 where migratory emergency IP telephony implementations are deployed. 486 Where the acceptable shape types are not understood restrictions to 487 Point, Circle and Sphere representations should be used to 488 accommodate most existing deployments. 490 Conversions from one geodetic shape type to another should be avoided 491 where data is considered critical and the introduction of errors 492 considered unacceptable. 494 If geodetic information is to be provided via DHCP, then a minimum 495 resolution of 20 bits SHOULD be specified for both the Latitude and 496 Longitude fields to achieve sub 100 meter precision. 498 9. Security Considerations 500 The primary security considerations relate to how location 501 information is conveyed and used, which are outside the scope of this 502 document. This document is intended to serve only as a set of 503 guidelines as to which elements MUST or SHOULD be implemented by 504 systems wishing to perform location dependent routing. The 505 ramification of such recommendations is that they extend to devices 506 and clients that wish to make use of such services. 508 10. IANA Considerations 510 This document does not introduce any IANA considerations. 512 11. Acknowledgments 514 The authors would like to thank the GEOPRIV working group for their 515 discussions in the context of PIDF-LO, in particular Carl Reed, Ron 516 Lake, James Polk and Henning Schulzrinne. Furthermore, we would like 517 to thank Jon Peterson as the author of PIDF-LO and Nadine Abbott for 518 her constructive comments in clarifying some aspects of the document. 520 12. References 522 12.1. Normative references 524 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 525 Levels", March 1997. 527 [2] Peterson, J., "A Presence-based GEOPRIV Location Object Format", 528 RFC 4119, December 2005. 530 [3] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 531 Configuration Protocol Option for Coordinate-based Location 532 Configuration Information", RFC 3825, July 2004. 534 [4] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 535 and DHCPv6) Option for Civic Addresses Configuration 536 Information", draft-ietf-geopriv-dhcp-civil-09 (work in 537 progress), January 2006. 539 [5] Thomson, M. and J. Winterbottom, "Revised Civic Location Format 540 for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-04 (work in 541 progress), September 2006. 543 [6] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 544 Polk, "Geopriv Requirements", RFC 3693, February 2004. 546 [7] Thomson, M., "draft-thomson-geopriv-geo-shape, Geodetic Shapes 547 for the Representation of Uncertainty in PIDF-LO", January 2006. 549 12.2. Informative References 551 [8] "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project; 552 Technical Specification Group Code Network; Universal 553 Geographic Area Description (GAD)". 555 [9] Schulzrinne, H., "Common Policy: A Document Format for 556 Expressing Privacy Preferences", 557 draft-ietf-geopriv-common-policy-11 (work in progress), 558 August 2006. 560 [10] "TR-45 J-STD-036-AD-2 Enhanced Wireless 9-1-1 Phase 2". 562 [11] "abbrev"i2">NENA VoIP-Packet Technical Committee, Interim VoIP 563 Architecture for Enhanced 9-1-1 Services (i2), NENA 08-001, Dec 564 2005". 566 [12] "NENA Standard for the Implementation of the Wireless Emergency 567 Service Protocol E2 Interface, NENA 05-001, Dec 2003". 569 Appendix A. Uncertainty in The RFC-3825 LCI Representation 571 RFC-3825 [3] defines a binary geodetic representation referred to as 572 Location Configuration Information LCI. The way that LCI represents 573 uncertainty is through a resolution parameter that indicates how many 574 binary digits of each axis are significant or accurate. This is 575 explained in detail in [3] with a series of examples, with a further 576 example provided in Appendix B of this document. In short LCI 577 describes a rectangular prism that is aligned along the north-south/ 578 east-west/up-down axes. 580 This appendix should be regarded as informative only and provides 581 guidance on aspects concerning the interpretation of uncertainty as 582 it applies to the binary geodetic LCI representation defined in RFC- 583 3825 [3]. 585 A.1. Conversion From LCI Form 587 From the example in RFC 3825, 38.89868 degrees is encoded into a 588 34bit twos-complement number: 590 000100110.1110011000001111111001000 592 The resolution value for this axis indicates how many of thess bits 593 are actually significant. A resolution of 18 indicates that the last 594 16 bits of the number could be either 1 or zero: 596 000100110.111001100xxxxxxxxxxxxxxxx 598 To determine the uncertainty assume a range from the minimum possible 599 value (all zeros for the last 16 bits) to the maximum (all ones): 601 000100110.1110011000000000000000000 to 602 000100110.1110011001111111111111111 604 This yields the range in the example to be between 38.8984375 degrees 605 and 38.9003906 degrees (rounded to 7 decimal places). 607 A.2. Conversion To LCI Form 609 Converting location information into the LCI format involves 610 converting the original shape to a rectangular prism. To do this 611 determine the minimum and maximum values for each of the axes: 612 latitude, longitude and altitude. This results in a slightly 613 increased area, but the overall effect is minimal. 615 +----------.....----------+ 616 | _d^^^^^^^^^b_ | 617 | .d''yyyyyyyyyyy``b. | 618 | .p'yyyyyyyyyyyyyyyyy`q. | 619 |.d'yyyyyyyyyyyyyyyyyyy`b.| 620 .d'yyyyyyyyyyyyyyyyyyyyy`b. 621 ::yyyyyyyyyyyyyyyyyyyyyyy:: 622 :: ................... :: 623 ::vvvvvvvvvvvvvvvvvvvvvvv:: 624 `p.vvvvvvvvvvvvvvvvvvvvv.q' 625 |`p.vvvvvvvvvvvvvvvvvvv.q'| 626 | `b.vvvvvvvvvvvvvvvvv.d' | 627 | `q..vvvvvvvvvv..p' <-+----Area Increase 628 | ^q........p^ | 629 +---------''''------------+ 631 It's important to note the resulting area cannot be less that the 632 starting area. This is because the starting area represents a set of 633 points and the Target may reside at anyone of these points with equal 634 probability. If the area is cropped there is a risk that the 635 Target's position will be one of the discarded points yielding an 636 incorrect result. In general the increases in area are minimal, for 637 a circular area, as shown, the increase ratio is 4:pi; a square 638 building will at most double the size of the area. 640 A.2.1. Example 1 642 Looking at a random example from 32.98004 degrees to 32.98054397 643 degrees the approximate distance is 56 meters. Converting each value 644 into a 34-bit twos-complement number yields the following: 646 000100000.1111101011100011111001110 to 647 000100000.1111101100000100111011100 648 ^^^^^^^^^^^^^^^^^ 650 To ensure that the encoded value represents the full range from the 651 lowest to highest value, take the common stem as marked this above. 652 There are 16 common bits between low and high. To check, convert the 653 value back by making the last 18 bits either 0 or 1 as described 654 earlier. This leads to a range from 32.9765625 degrees to 32.9843745 655 degrees, which is approximately 870 meters a significant increase 656 over the original 56 meters. 658 A.2.2. Example 2 660 Take the range from 31.9999985 degrees to 32.00000274 degrees, which 661 is about 0.5 meters in distances ranging around 32 degrees. This 662 results in the following binary values: 664 000011111.1111111111111111111001110 to 665 000100000.0000000000000000001011100 666 ^^^ 668 Only 3 bits are common to both values which yields an encoded range 669 from 0 to 64 degrees, or a distance of 3,500 kilometers. 671 A.3. Problem 673 The LCI encoding breaks when the uncertainty that is being 674 represented causes a change in a relatively significant binary digit. 675 This results in an expanded uncertainty, possibly very large, 676 depending on which binary digit changes. In many cases the change 677 will be in lower-order digits, which will result in a relatively 678 small increase in uncertainty, but certain values will yield an 679 almost useless location see Appendix A.2.2. 681 This problem is exacerbated at the three zero points - the Greenwich 682 Meridian, Equator and at the surface of the geoid (altitude). In 683 these cases, if the input uncertainty spans the zero point, the 684 resolution value ends up as zero; that is, it indicates that there is 685 no useful information for that parameter. 687 The original uncertainty has very little bearing on this problem - a 688 small value can be increased to any value. More precise location 689 determination technologies only reduce the probability of large 690 problems occurring, although the nature of the encoding is such that 691 any uncertainty can be greatly increased. 693 A.4. Conclusion 695 Uncertainty is a reality of location and important for a number of 696 applications. LCI's limited form means that adapting existing 697 uncertainty information, for example a circle as in Appendix A.2.2, 698 results in a small error. The introduction of this small encoding 699 error is, however, insignificant when compared to the error that can 700 be introduced by the way that the resolution parameter is 701 interpreted. 703 Appendix B. Creating a PIDF-LO from DHCP Geo Encoded Data 705 This appendix is informative only. 707 RFC 3825 [3] describes a means by which an end point may learn it 708 location from information encoded into DHCP option 123. The 709 following section describes how and end point can take this 710 information and represent it in a well formed PIDF-LO describing this 711 geodetic location. 713 The location information described in RFC 3825 consists of a 714 latitude, longitude, altitude and datum. 716 B.1. Latitude and Longitude 718 The latitude and longitude values are represented in degrees and 719 decimal degrees. Latitude values are positive if north of the 720 equator, and negative if south of the equator. Similarly 721 longitudinal values are positive if east of the Greenwich meridian, 722 and negative if west of the Greenwich meridian. 724 The latitude and longitude values are each 34 bit long fields 725 consisting of a 9 bit integer component and a 25 bit fraction 726 component, with negative numbers being represented in 2s complement 727 notation. The latitude and longitude fields are each proceeded by a 728 6 bit resolution field, the LaRes for latitude, and the LoRes for 729 longitude. The value in the LaRes field indicates the number of 730 significant bits to interpret in the Latitude field, while the value 731 in the LoRes field indicates the number of significant bits to 732 interpret in the Longitude field. 734 For example, if you are in Wollongong Australia which is located at 735 34 Degrees 25 minutes South and 150 degrees 32 minutes East, this 736 would translate to -34.41667, 150.53333 in decimal degrees. If these 737 numbers are translated to their full 34 bit representations, then we 738 arrive the following: 740 Latitude = 111011101.1001010101010101000111010 742 Longitude = 0100101101000100010001000010100001 744 RFC 3825, uses the LaRes and LoRes values to specify a lower and 745 upper boundary for location thereby specifying an area. The size of 746 the area specified is directly related to the value specified in the 747 LaRes and LoRes fields. 749 Using the previous example, if LaRes is set 7, then lower latitude 750 boundary can be calculated as -256+128+64+16+8+4, which is -36 751 degrees, the upper boundary then becomes -256+128+64+16+8+4+2+1 which 752 is -35 degrees. LoRes may be used similarly for Longitude. 754 So what level of precision is useful? Well, certain types of 755 applications and regulations call for different levels of precision, 756 and the required precision may vary depending on how the location was 757 determined. For cellular 911 calls in the United States, for 758 example, if the network measures the location then the caller should 759 be within 100 meters, while if the handset does the measurement then 760 the location should be within 50 meters. Since DHCP is a network 761 based mechanism we will benchmark off 100 meters (approximately 330 762 ft) which is still a large area. 764 For simplicity we shall assume that we are defining a square, in 765 which we are equally to appear anywhere. The greatest distance 766 through this square is across the diagonal, so we make this 100 767 meters. 769 +----------------------+ 770 | _/| 771 | _/ | 772 | _/ | 773 | _/ | 774 | _/ | 775 | 100_/ metres | 776 | _/ | 777 | _/ | 778 | _/ | 779 | _/ | 780 |_/ | 781 +----------------------+ 783 The distance between the top and the bottom and the left and the 784 right is the same, the area being a square, and this works out to be 785 70.7 meters. When expressed in decimal degrees, the third point 786 after the decimal place represents about 100 meter precision, this 787 equates to 10 binary places of fractional part. A 70 meter distance 788 is required, so 11 fractional binary digits are necessary resulting 789 in a total of 20 bits of precision. 791 With -34.4167, 150.5333 encoded with 20 bits of precision for the 792 LaRes and LoRes, the corners of the enclosing square are: 794 Point 1 (-34.4170, 150.5332) 795 Point 2 (-34.4170, 150.5337) 796 Point 3 (-34.4165, 150.5332) 797 Point 4 (-34.4165, 150.5337) 799 B.2. Altitude 801 The altitude elements define how the altitude is encoded and to what 802 level of precision. The units for altitude are either meters, or 803 floors, with the actual measurement being encoded in a similar manner 804 to those for latitude and longitude, but with 22 bit integer, and 8 805 bit fractional components. 807 B.3. Generating the PIDF-LO 809 If altitude is not required, or is expressed in floors then a 810 geodetic location expressed by a polygon SHOULD be used, with points 811 expressed in a counter-clockwise direction. If the altitude is 812 expressed in floors and is required, the altitude SHOULD be expressed 813 as a civic floor number as part of the same element. 814 In the example above the GML for the location would be expressed as 815 follows: 817 819 820 821 -34.4165 150.5332 822 -34.4170 150.5532 823 -34.4170 150.5537 824 -34.4165 150.5337 825 -34.4165 150.5332 826 827 828 830 No Altitude 832 If a floor number of say 3 were included, then the location-info 833 element would contain the above information and the following: 835 837 2 839 841 Civic Altitude 843 When altitude is expressed as an integer and fractional component, as 844 with the latitude and longitude, it expresses a range which requires 845 the prism form to be used. Care must be taken to ensure that the 846 points are defined in a counter-clockwise direction to ensure that 847 the upward normal points up. 849 Extending the previous example to include an altitude expressed in 850 metres rather than floors. AltRes is set to a value of 19, and the 851 Altitude value is set to 34. Using similar techniques as shown in 852 the latitude and longitude section, a range of altitudes between 32 853 meters and 40 meters is described. The prism would therefore be 854 defined as follows: 856 859 860 861 862 863 -34.4165 150.5332 32 864 -34.4170 150.5532 32 865 -34.4170 150.5537 32 866 -34.4165 150.5337 32 867 -34.4165 150.5332 32 868 869 870 871 872 873 8 874 875 877 The Method value SHOULD be set to Wiremap. 879 The timestamp value SHOULD be set to the time that location was 880 retrieved from the DHCP server. 882 The client application MAY insert any usage rules that are pertinent 883 to the user of the device and that comply with [9]. A guideline is 884 that the any retention-expiry value SHOULD NOT exceed the current 885 lease time. 887 The Provided-By element SHOULD NOT be populated as this is not 888 provided by the source of the location information. 890 The 3 completed PIDF-LO representations are provided below, and 891 represent a location without altitude, a location with a civic 892 altitude, and a location represented as a 3 dimensional rectangular 893 prism. 895 896 902 903 904 905 906 907 908 909 -34.4165 150.5332 910 -34.4170 150.5532 911 -34.4170 150.5537 912 -34.4165 150.5337 913 -34.4165 150.5332 914 915 916 917 918 919 Wiremap 920 921 922 2005-07-05T14:49:53+10:00 923 924 926 Geodetic Location Only PIDF-LO 928 929 936 937 938 939 940 941 942 943 -34.4165 150.5332 944 -34.4170 150.5532 945 -34.4170 150.5537 946 -34.4165 150.5337 947 -34.4165 150.5332 948 949 950 951 952 2 953 954 955 956 Wiremap 957 958 959 2005-07-05T14:49:53+10:00 960 961 963 Geodetic Location with Civic Floor PIDF-LO 965 966 972 973 974 975 976 977 978 979 980 981 -34.4165 150.5332 32 982 -34.4170 150.5532 32 983 -34.4170 150.5537 32 984 -34.4165 150.5337 32 985 -34.4165 150.5332 32 986 987 988 989 990 991 8 992 993 994 995 996 Wiremap 997 998 999 2005-07-05T14:49:53+10:00 1000 1001 1003 Rectangular Prism PIDF-LO 1005 Authors' Addresses 1007 James Winterbottom 1008 Andrew Corporation 1009 Wollongong 1010 NSW Australia 1012 Email: james.winterbottom@andrew.com 1014 Martin Thomson 1015 Andrew Corporation 1016 Wollongong 1017 NSW Australia 1019 Email: martin.thomson@andrew.com 1021 Hannes Tschofenig 1022 Siemens 1023 Otto-Hahn-Ring 6 1024 Munich, Bavaria 81739 1025 Germany 1027 Email: Hannes.Tschofenig@siemens.com 1029 Full Copyright Statement 1031 Copyright (C) The Internet Society (2006). 1033 This document is subject to the rights, licenses and restrictions 1034 contained in BCP 78, and except as set forth therein, the authors 1035 retain all their rights. 1037 This document and the information contained herein are provided on an 1038 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1039 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1040 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1041 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1042 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1043 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1045 Intellectual Property 1047 The IETF takes no position regarding the validity or scope of any 1048 Intellectual Property Rights or other rights that might be claimed to 1049 pertain to the implementation or use of the technology described in 1050 this document or the extent to which any license under such rights 1051 might or might not be available; nor does it represent that it has 1052 made any independent effort to identify any such rights. Information 1053 on the procedures with respect to rights in RFC documents can be 1054 found in BCP 78 and BCP 79. 1056 Copies of IPR disclosures made to the IETF Secretariat and any 1057 assurances of licenses to be made available, or the result of an 1058 attempt made to obtain a general license or permission for the use of 1059 such proprietary rights by implementers or users of this 1060 specification can be obtained from the IETF on-line IPR repository at 1061 http://www.ietf.org/ipr. 1063 The IETF invites any interested party to bring to its attention any 1064 copyrights, patents or patent applications, or other proprietary 1065 rights that may cover technology that may be required to implement 1066 this standard. Please address the information to the IETF at 1067 ietf-ipr@ietf.org. 1069 Acknowledgment 1071 Funding for the RFC Editor function is provided by the IETF 1072 Administrative Support Activity (IASA).