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