Geopriv J. Winterbottom Internet-Draft M. Thomson Expires: August 8, 2006 Andrew Corporation H. Tschofenig Siemens February 4, 2006 GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations draft-ietf-geopriv-pdif-lo-profile-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 8, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The Presence Information Data Format Location Object (PIDF-LO) specification provides a flexible and versatile means to represent location information. There are, however, circumstances that arise when information needs to be constrained in how it is represented so that the number of options that need to be implemented in order to make use of it are reduced. There is growing interest in being able Winterbottom, et al. Expires August 8, 2006 [Page 1] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 to use location information contained in a PIDF-LO for routing applications. To allow successfully interoperability between applications, location information needs to be normative and more tightly constrained than is currently specified in the PIDF-LO. This document makes recommendations on how to constrain, represent and interpret locations in a PIDF-LO. It further looks at existing communications standards that make use of geodetic information for routing purposes and recommends a subset of GML that MUST be implemented by applications to allow location dependent routing to occur. Winterbottom, et al. Expires August 8, 2006 [Page 2] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 Table of Contents 1. CHANGES SINCE LAST TIME . . . . . . . . . . . . . . . . . . . 4 1.1. 01 changes . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Using Location Information . . . . . . . . . . . . . . . . . . 7 4.1. Single Civic Location Information . . . . . . . . . . . . 8 4.2. Civic and Geospatial Location Information . . . . . . . . 9 4.3. Manual/Automatic Configuration of Location Information . . 11 5. Geodetic Coordinate Representation . . . . . . . . . . . . . . 12 6. Uncertainty in Location Representation . . . . . . . . . . . . 14 6.1. Arc band . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Ellipsoid Point With Uncertainty Circle . . . . . . . . . 18 6.3. Polygon . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Baseline Geometry . . . . . . . . . . . . . . . . . . . . . . 24 7.1. Zero Dimensions . . . . . . . . . . . . . . . . . . . . . 24 7.2. One Dimensions . . . . . . . . . . . . . . . . . . . . . . 24 7.3. Two Dimensions . . . . . . . . . . . . . . . . . . . . . . 25 7.4. Three Dimensions . . . . . . . . . . . . . . . . . . . . . 25 7.5. Envelopes . . . . . . . . . . . . . . . . . . . . . . . . 25 7.6. Temporal Dimensions . . . . . . . . . . . . . . . . . . . 26 7.7. Units of Measure . . . . . . . . . . . . . . . . . . . . . 26 7.8. Coordinate Reference System (CRS) . . . . . . . . . . . . 26 8. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 28 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 32 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 13.1. Normative references . . . . . . . . . . . . . . . . . . . 33 13.2. Informative References . . . . . . . . . . . . . . . . . . 33 Appendix A. Creating a PIDF-LO from DHCP Geo Encoded Data . . . . 34 A.1. Latitude and Longitude . . . . . . . . . . . . . . . . . . 34 A.2. Altitude . . . . . . . . . . . . . . . . . . . . . . . . . 36 A.3. Generating the PIDF-LO . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 Intellectual Property and Copyright Statements . . . . . . . . . . 42 Winterbottom, et al. Expires August 8, 2006 [Page 3] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 1. CHANGES SINCE LAST TIME 1.1. 01 changes minor changes to the abstract. Minor changes to the introduction. Added and appendix to take implementers through how to create a PIDF-LO from data received using DHCP option 123 as defined in [3]. Rectified examples to use position and pos rather than location and point. Corrected example 3 so that it does not violate SIP rules. Added addition geopriv elements to the status component of the figure in "Using Location Information" to more accurately reflect the cardinality issues. Revised text in section "Geodection Coordinate Representation. Removed last example as this was addressed with the change to position and pos in previous examples. Winterbottom, et al. Expires August 8, 2006 [Page 4] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 2. Introduction The Presence Information Data Format Location Object (PIDF-LO) [1] is the IETF recommended way of encoding location information and associated privacy policies. Location information in PIDF-LO may be described in a geospatial manner based on a subset of GMLv3, or as civic location information. Uses for PIDF-LO are envisioned in the context of numerous location based applications. This document makes recommendations for formats and conventions to make interoperability less problematic. To enhance clarify formats comparisons between GML and the 3GPP Mobile Location Protocol (MLP) standard [4], are examined. Winterbottom, et al. Expires August 8, 2006 [Page 5] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [2]. Winterbottom, et al. Expires August 8, 2006 [Page 6] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 4. Using Location Information The PIDF format provides for an unbounded number of tuples. The geopriv element resides inside the status component of a tuple, hence a single PIDF document may contain an arbitrary number of location objects some or all of which may be contradictory or complementary. The actual location information is contained inside a element, and there may be one or more actual locations described inside the element. Graphically, the structure of the PIDF/PIDF-LO can be depicted as follows: PIDF document tuple 1 status geopriv location-info civicAddress location usage-rules geopriv 2 geopriv 3 . . . tuple 2 tuple 3 All of these potential sources and storage places for location lead to confusion for the generators, conveyors and users of location information. Practical experience within the United States National Emergency Number Association (NENA) in trying to solve these ambiguities led the following conventions being adopted: Rule #1: A GeoPriv tuple MUST completely define a specific location. Rule #2: Where a location can be uniquely described in more than one way, each location description SHOULD reside in a separate tuple. Winterbottom, et al. Expires August 8, 2006 [Page 7] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 Rule #3: Providing more than one location in a single presence document (PIDF) MUST only be done if all objects describe the same location. Rule #4: Providing more than one location in a single element SHOULD be avoided where possible. Rule #5: When providing more than one location in a single element they MUST be provided by a common source. If you have more than one location in the element, then the combination (complex of)these elements defines the complete location. Rule #6: Providing more than one location in a single element SHOULD only be done if they form a complex to describe the same location. For example, a geodetic location describing a point, and a civic location indicating the floor in a building. Rule #7: Where a location complex is provided in a single element, the higher precision locations MUST be provided first. For example, a geodetic location describing a point, and a civic location indicating the floor MUST be represented with the point first followed by the civic location. Rule #8: Where a PIDF document contains more than one tuple containing a status element with a geopriv location element , the priority of tuples SHOULD be based on tuple position within the PIDF document. That is to say, the tuple with the highest priority location occurs earliest in the PIDF document. Initial priority SHOULD be determined by the originating UA, the final priority MAY be determined by a proxy along the way. Rule #9: Where multiple PIDF documents are contained within a single request, document selection SHOULD be based on document order. The following examples illustrate the useful of these rules. 4.1. Single Civic Location Information Jane is at a coffee shop on the ground floor of a large shopping mall. Jane turns on her laptop and connects to the coffee-shop's WiFi hotspot, Jane obtains a complete civic address for her current Winterbottom, et al. Expires August 8, 2006 [Page 8] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 location, for example using [5]. She constructs a Location Object which consists of a single PIDF document, with a single geopriv tuple, with a single location residing in the element. This is largely unambiguous, and if this location is sent over the network, providing it understands civic addresses, correct handling of any request should be possible. 4.2. Civic and Geospatial Location Information Mike is visiting his Seattle office and connects his laptop into the Ethernet port in a spare cube. Mike's computer receives a location over DHCP as defined in [3]. In this case the location is a geodetic location, with the altitude represented as a building floor number. This is constructed by Mike's computer into the following PIDF document: Winterbottom, et al. Expires August 8, 2006 [Page 9] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 2 2003-06-22T20:57:29Z 37.775 -122.4194 2003-06-22T20:57:29Z The constructed PIDF document contains two geopriv elements each in a separate PIDF tuple, the first being a civic address made up of only floor, the second containing the provided geodetic information. If the location is required for routing purposes, which information is used? Applying rule #8, we will likely fail, or at a minimum need to fall back to the second tuple describing the geodetic location, a route described by floor only is precise enough in the normal case to permit route selection. If rule #6 and #7 are applied, then the revised PIDF-LO document would look creates a complex as shown below. Winterbottom, et al. Expires August 8, 2006 [Page 10] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 37.775 -122.4194 2 2003-06-22T20:57:29Z It is now clear that the main location of user is a geodetic location at latitude 37.775 and longitude -122.4194. Further that the user is on the second floor of the building located at those coordinates. 4.3. Manual/Automatic Configuration of Location Information Erin has a predefined civic location stored in her laptop, since she normally lives in Sydney, the address in her address is for her Sydney-based apartment. Erin decides to visit sunny San Francisco, and when she gets there she plugs in her laptop and makes a call. Erin's laptop receives a new location from the visited network in San Francisco and adds this to her existing PIDF location document. Applying rule #9, the resulting order of location information in the PIDF document should be San Francisco first, followed by Sydney. Since the information is provided by different sources, rule #8 should also be applied and the information places in different tuples with San Francisco first. Winterbottom, et al. Expires August 8, 2006 [Page 11] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 5. Geodetic Coordinate Representation The geodetic examples provided in [1] are illustrated using the gml: location element which uses the gml:coordinates elements (inside the gml:Point element) and this representation has several drawbacks. Firstly, it has been deprecated in later versions of GML (3.1 and beyond) making it inadvisable to use for new applications. Secondly, the format of the coordinates type is opaque and so can be difficult to parse and interpret to ensure consistent results, as the same geodetic location can be expressed in a variety of ways. An alternative is to use the gml:position and gml:pos elements. These elements have a structured format, in that each field is represented as a double, and a single space exists between each field. Such a format does not introduce the same degree of misinterpretation. The recommended representation therefore for expressing geodetic coordinates for location based routing applications would be: 37.775 -122.422 The coordinate reference system (CRS) indicates which numbers in the sequence equate to latitude, longitude etc, and in addition to this the CRS also provides an indication of direction represented by the sign of the number. For example, in WGS-84 (represented as CRS: 4326), as shown in the code snippet above, the format is latitude followed by longitude. A positive value for latitude represents a location north of the equator while a negative value represents a location south of the equator. Similarly for longitude, a positive value represents a location east of Greenwich, while a negative value represents a location west of Greenwich. EPSG 4326 is the two dimensional WGS-84 representation, if we wanted to represented this in three dimensions, that is with an altitude as well, then we would use EPSG 4979 and the format would be as follows: 37.775 -122.422 22 Winterbottom, et al. Expires August 8, 2006 [Page 12] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 The format using CRS:4979 is similar to CRS:4326, though we now have an altitude value. Specifically the altitude is provided in metres above the geoid, which will not be useful for general routing applications since the geoid is generally neither ground-level nor sea-level. However, for more specialized geographic applications it may be useful. Winterbottom, et al. Expires August 8, 2006 [Page 13] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 6. Uncertainty in Location Representation The cellular mobile world today makes extensive use of geodetic based location information for emergency and other location-based applications. Generally these locations are expressed as a point (either in two or three dimensions) and an area or volume of uncertainty around the point. In theory, the area or volume represents a coverage in which the user has a relatively high probability of being found, and the point is a convenient means of defining the centroid for the area or volume. In practice, most systems today use the point as an absolute value and ignore the uncertainty. It is difficult to determine if systems have been implement in this manner for simplicity, and even more difficult to predict if uncertainty will play a more important role in the future. An important decision is whether an uncertainty area should be specified. There are six common ways to represent location and uncertainty, but are listed below for completeness: o Arc band o Ellipsoid point with uncertainty circle o Polygon o Ellipsoid point with altitude o Ellipsoid point with uncertainty ellipse o Ellipsoid point with altitude and uncertainty ellipsoid GML was designed to provide a very flexible abstraction on which specific representations of geometric and geographic schemes could be extended. Representing some of the above shapes is difficult if not impossible using base GML. However, only a subset of GML, namely feature.xsd, is mandatory for a PIDF-LO implementation. Extending GML to easily represent these shapes may lead to interoperability issues and so is not recommended. The authors of this document were unable to find a means to express either an ellipse or and ellipsoid using only the elements defined in feature.xsd. The following sections describe four shapes that can be defined in GML, and show the equivalent representation in 3GPP MLP [4]. 6.1. Arc band Arc band is used primarily where timing advance (TA) information is Winterbottom, et al. Expires August 8, 2006 [Page 14] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 known. Timing advance is a mechanism used in wireless communications to help ensure that handsets and base-stations remained synchronized. Timing advance is stepped based on signal propagation and is fairly deterministic, for GSM each increase in TA value represents 553.85 metres. The arc band type was developed to represent the area between two successive TA values and an antenna opening. This is presented in 3GPP as a point, two radii, and two angles representing the start and the stop of the angles for the opening. ,..__ / `-. / `-. / `. / \ /__ \ . `-. \ start. `. \ angle \ . . | | o ' | . / ' . / ; stop . .,' / angle `. / `. / `. ,' `. ,' `' 42.5463 -73.2512 1938.5 2492.3 63.7 118.4 Winterbottom, et al. Expires August 8, 2006 [Page 15] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 The GML representation of this is below: 42.5463 -73.2512 2492.3 63.7 Winterbottom, et al. Expires August 8, 2006 [Page 16] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 118.4 42.535651 -73.224473 42.538018 -73.230411 42.5463 -73.2512 1938.5 63.7 118.4 42.554016 -73.230007 42.556220 -73.223952 Winterbottom, et al. Expires August 8, 2006 [Page 17] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 2004-12-01T09:28:43+10:00 This representation poses a few potential problems over the 3GPP representation. In the 3GPP representation the point is absolute, and everything else is defined relative to this point, ensuring that the band is indeed bounded. The representation of arc band above does not share all of these properties. In the GML arc band representation above, the point and radii are relative, but the bounding lines of the starting and finishing angles are not, these are necessarily defined as independent line segments. By having to define the arc enclosures as individual line segments it is possible to define an unbounded arc band which would consist of two arcs some arbitrary distance apart with two lines that may or may not intersect them. A second concern with this representing uncertainty using this method, is that there is no explicit statement or way of indicating to the receiving application what type of uncertainty is being represented. Today several different representations of uncertainty are valid with in the same application, so knowing which type is being used, and how to interpret it is important, and this is particularly true if the shape must also be validated as is the case above. Ensuring the legality of this shape type when represented in GML is more complex than in MLP as the type must first be determined before its validity can be assessed. Users of this shape type may be better served by a formal shape definition being introduced into GeoPriv so that these problems can be more readily overcome. 6.2. Ellipsoid Point With Uncertainty Circle This shape type is used extensively over the North American NENA defined E2 interface for transporting mobile geodetic location from the MPC/GMLC to the ALI and subsequently the PSAPs. In 3GPP this is defined as a WGS-84 point (ellipsoid point), and a radius or uncertainty around that point, specified in metres. The 3GPP MLP representation for an ellipsoid point with uncertainty is defined as follows: Winterbottom, et al. Expires August 8, 2006 [Page 18] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 42.5463 -73.2512 850.24 This shape is similarly defined in GML below: Winterbottom, et al. Expires August 8, 2006 [Page 19] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 42.5463 -73.2512 850.24 2004-12-01T09:28:43+10:00 This type does not have all of the problems associated with the arc band representation, in that the radius of the circle is relative to the centre, and so the validation is unnecessary. However it does suffer from the potential problem that the application still needs to determine the type of uncertainty being represented, though this Winterbottom, et al. Expires August 8, 2006 [Page 20] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 maybe made more clear through the explicit use of the gml: CircleByCenterPoint element. 6.3. Polygon A polygon is defined as a set of points to form an enclosed bounded shape. It is here that GML and the 3GPP shapes are most similar. The representation for a polygon in GML is given first: 42.556844 -73.248157 42.549631 -73.237283 42.539087 -73.240328 42.535756 -73.254242 42.542969 -73.265115 42.553513 -73.262075 42.556844 -73.248157 2004-12-13T14:49:53+10:00 Winterbottom, et al. Expires August 8, 2006 [Page 21] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 The GML object here is clear in its definition. A gml:LinearRing MUST have a minimum of four points, with the first and last points being the same. The 3GPP MLP representation for a polygon is provided below. 42.556844 -73.248157 42.549631 -73.237283 42.539087 -73.240328 42.535756 -73.254242 42.542969 -73.265115 42.553513 -73.262075 42.556844 -73.248157 While these two representations are very similar and precise, they Winterbottom, et al. Expires August 8, 2006 [Page 22] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 are not widely used at present. If only a coverage area is required without a nominal central point requiring specification, then this form is ideal for representation using GML. Winterbottom, et al. Expires August 8, 2006 [Page 23] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 7. Baseline Geometry PIDF-LO suggests to use GMLv3 feature.xsd, which provides a subset of the available GML functionality. As a consequence a number of further XML files are implicitly included, namely geometryBasic0d1d.xsd, geometryBasic2d.xsd, temporal.xsd, measure.xsd, units.xsd, gmlBase.xsd, dictionary.xsd, xLinks.xsd and basicTypes.xsd, as being necessary to support. This provides for a vast range of possibilities which would pose significant complications to implementors wish to develop location dependent routing applications. By agreeing to a minimal set of data appropriate for routing, a minimum set of GML that MUST be implemented by a given application type can also be set. This does not preclude the additional functionality from being implemented, merely that it may not be understood by some nodes. 7.1. Zero Dimensions The minimum supported set of elements is position/Point/pos provided by geometryBasic0d1d.xsd. Thus a point location has only one representation as follows: 4.5 -36.2 The and objects MUST NOT be used since they are deprecated in GML 3.1 and their functionality can be substituted with the above-described elements. Note that pos allows altitude to be expressed based on the selected Coordinate Reference Systems (e.g., EPSG:4979 or EPSG:4326). Most Coordinate Reference Systems use altitude above the geoid and not altitude above the ground. 7.2. One Dimensions Support for one dimensional shapes (such as the LineString or the posList object)is not required except as a part of two dimensional shapes. geometryBasic0d1d.xsd provides these geometric properties and objects. Winterbottom, et al. Expires August 8, 2006 [Page 24] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 7.3. Two Dimensions The examples previously used were all contructed using elements from this schema which reuse functionality from geometryBasic2d.xsd. As was described earlier the arcband definition in GML is problematic for producing a closed solid and SHOULD consequently be avoided. As a result of this, elements required exclusively for representing the arcband shape have not been included in the minimum supported element set. The minimum element set is therefore restricted to circle and polygon. Circle: extentOf/ Polygon/ exterior/ Ring/ curveMember/ Curve/ segments/ CircleByCentrePoint/ -> Circle pos radius Alternatively it would be possible to use the following structure to express a circle using the element with three pos elements as well. However, the usage of pos and radius, as shown above, is inline with the model used by the 3GPP. Polygon: extentOf/ Polygon/ exterior/ LinearRing/ pos or posList -> Polygon 7.4. Three Dimensions Support for three dimensions is not required 7.5. Envelopes The Envelope element is a representation of a bounding box and can be expressed in two or three dimensions. Defining a space using the Envelope element should be done with extreme caution due to Winterbottom, et al. Expires August 8, 2006 [Page 25] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 continuity problems at the extremities of the CRS. In WGS-84, two envelopes are required at the 180th meridian. The minimum set of elements required to support an Envelope are: boundBy/ Envelope/ upperCorner/ Point/ Pos lowerCorner/ Point/ Pos/ 7.6. Temporal Dimensions Support for temporal elements is not required 7.7. Units of Measure The base SI units as a minimum MUST be supported. For measures of distance this is metres. The EPSG URN for metres is: metres = urn:ogc:def:uom:EPSG:9001:6.6 Angles are frequently expressed in terms of both degrees and radians, consequently both MUST be implemented. degrees = urn:ogc:def:uom:EPSG:9102:6.6 radians = urn:ogc:def:uom:EPSG:9101:6.6 Further units of measurement are not required. 7.8. Coordinate Reference System (CRS) There are a very large number of coordinate reference systems in existence today, but many are, however, not in widespread use. Existing communications protocols such as those used in both the ANSI, 3GPP and NENA standards (see [6], [7], [8]) have standardized on WGS-84. It is recommended for routing purpose that only WGS-84 coordinate types MUST be implemented and further that this set be restricted to the following: Winterbottom, et al. Expires August 8, 2006 [Page 26] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 WGS84(2D) = urn:ogc:def:crs:EPSG:6.6:4326 WGS84(3D) = urn:ogc:def:crs:EPSG:6.6:4979 Winterbottom, et al. Expires August 8, 2006 [Page 27] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 8. Recommendations As a summary this document gives a few recommendations on the usage of location information in PIDF-LO. Nine rules specified in Section 4 give guidelines on the ambiguity of PIDF-LO with regard to the occurrence of multiple location information. It is recommend that gml:position, gml:pos types be used to specify locations when locations are needed for routing and specifically emergency routing. Enhancements to GMLv3 feature.xsd may need to be defined to allow complex shapes types to be specified in a way that makes them easy to distinguish and validate. This is particularly important if the data is to be used during the decision making process of routing signaling messages. Only a limited subset of GML functionality from the feature.xsd schema is necessary to describe a geodetic location with sufficient precision to allow a routing decision to be made. Restricting both the amount of GML that MUST be implemented, and the number of variations in which this data can be expressed significantly reduces the likelihood of interoperability issues in the future. Precedents exist in the other communications protocols for restricting CRS types and representations for the sake of simplicity and interoperability, and the recommendation is made to adopt similar restrictions for mandatory implementable components of GeoPriv. If Geodetic information is to be provided via DHCP, then a minimum resolution of 20 bits SHOULD be specified for both the Latitude and Longitude fields so that sub 100 metre precision is achieved. Where only two dimensional objects are required polygons SHOULD be used to express the enclosed area. Where 3 dimensions are required a 3 dimensional bounding box representing a rectangular prism SHOULD be used with care taken around the 180th meridian. Winterbottom, et al. Expires August 8, 2006 [Page 28] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 9. Security Considerations The primary security considerations relate to how location information is conveyed and used, which are outside the scope of this document. This document is intended to serve only as a set of guidelines as to which elements MUST or SHOULD be implemented by systems wishing to perform location dependent routing. The ramification of such recommendations is that they extend to devices and clients that wish to make use of such services. Winterbottom, et al. Expires August 8, 2006 [Page 29] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 10. IANA Considerations This document does not introduce any IANA considerations. Winterbottom, et al. Expires August 8, 2006 [Page 30] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 11. Acknowledgments The authors would like to thank the GEOPRIV working group for their discussions in the context of PIDF-LO, in particular James Polk and Henning Schulzrinne. Furthermore, we would like to thanks Jon Peterson as the author of PIDF-LO and Nadine Abbott for her constructive comments in clarifying some aspects of the document. Winterbottom, et al. Expires August 8, 2006 [Page 31] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 12. Open Issues Need to get define minimal subset of Civic information that is useful for routing purposes. May be hard to get normative, but hopefully we can get something that is generally representative. Need agreement on minimal set of shape support. Need to go through the rules to enhance clarity. These rules are highly likely to be important in quite a number of Location Dependent Routing (LDR) based applications, including ECRIT. General feedback is that they are not clear or precise enough yet. Henning has provide some good feedback here that I have not had time to incorporate yet, some of these comments will hopefully be easier to resolve if open issue 1 above is also resoved. Winterbottom, et al. Expires August 8, 2006 [Page 32] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 13. References 13.1. Normative references [1] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. 13.2. Informative References [3] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004. [4] "Mobile Location Protocol (MLP), OMA, Candidate Version 3.1", March 2004. [5] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", draft-ietf-geopriv-dhcp-civil-09 (work in progress), January 2006. [6] "TR-45 J-STD-036-AD-2 Enhanced Wireless 9-1-1 Phase 2". [7] "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project; Technical Specification Group Code Network; Universal Geographic Area Description (GAD)". [8] "NENA Standard for the Implementation of the Wireless Emergency Service Protocol E2 Interface". [9] Schulzrinne, H., "A Document Format for Expressing Privacy Preferences", draft-ietf-geopriv-common-policy-06 (work in progress), October 2005. [10] Peterson, J., "A Presence Architecture for the Distribution of GEOPRIV Location Objects", draft-ietf-geopriv-pres-02 (work in progress), September 2004. Winterbottom, et al. Expires August 8, 2006 [Page 33] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 Appendix A. Creating a PIDF-LO from DHCP Geo Encoded Data RFC-3825 [3] describes a means by which an end-point may learns it location from information encoded into DHCP option 123. The following section describes how and end-point can take this information and represent it in a well formed PIDF-LO describing this geodetic location. The location information described in RFC-3825 consists of a latitude, longitude, altitude and datum. A.1. Latitude and Longitude The latitude and longitude values are represented in degrees and decimal degrees. Latitude values are positive if north of the equator, and negative if south of the equator. Similarly longitudinal values are positive if east of the Greenwich meridian, and negative if west of the Greenwich meridian. The latitude and longitude values are each 34 bit long fields consisting of a 9 bit integer component and a 25 bit fraction component, with negative numbers being represented in 2s complement notation. The latitude and longitude fields are each proceeded by a 6 bit resolution field, the LaRes for latitude, and the LoRes for longitude. The value in the LaRes field indicates the number of significant bits to interpret in the Latitude field, while the value in the LoRes field indicates the number of significant bits to interpret in the Longitude field. For example, if you are in Wollongong Australia which is located at 34 Degrees 25 minutes South and 150 degrees 32 minutes East this would translate to -34.41667, 150.53333 in decimal degrees. If these numbers are translated to their full 34 bit representations, then we arrive the following: Latitude = 111011101.1001010101010101000111010 Longitude = 0100101101000100010001000010100001 RFC-3825, uses the LaRes and LoRes values to specify a lower and upper boundary for location thereby specifying an area. The size of the area specified is directly related to the value specified in the LaRes and LoRes fields. Using the previous example, if LaRes is set 7, then lower latitude boundary can be calculated as -256+128+64+16+8+4, which is -36 degrees, the upper boundary then becomes -256+128+64+16+8+4+2+1 which is -35 degrees. LoRes may be used similarly for Longitude. Winterbottom, et al. Expires August 8, 2006 [Page 34] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 So what level of precision is useful? Well, certain types of applications and regulations call for different levels of precision, and the required precision may vary depending on how the location was determined. For Cellular 911 calls in the United States, for example, if the network measures the location then the caller should be within 100 metres, while if the handset does the measurement then the location should be within 50 metres. Since DHCP is a network based mechanism we will benchmark off 100 metres (approximately 330 ft) which is still a large area. For simplicity we shall assume that we are defining a square, in which we are equally to appear anywhere. The greatest distance through this square is across the diagonal, so we make this 100 metres. +----------------------+ | _/| | _/ | | _/ | | _/ | | _/ | | 100_/ metres | | _/ | | _/ | | _/ | | _/ | |_/ | +----------------------+ The distance between the top and the bottom and the left and the right is the same, the area being a square, and this works out to be 70.7 metres. When expressed in decimal degrees, the third point after the decimal place represents about 100 metre precision, this equates to 10 binary places of fractional part. A 70 metre distance is required, so 11 fractional binary digits are necessary resulting in a total of 20 bits of precision. With -34.4167, 150.5333 encoded with 20 bits of precision for the LaRes and LoRes, the corners of the enclosing square are: Point 1 (-34.4170, 150.5332) Point 2 (-34.4170, 150.5337) Point 3 (-34.4165, 150.5332) Point 4 (-34.4165, 150.5337) Winterbottom, et al. Expires August 8, 2006 [Page 35] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 A.2. Altitude The altitude elements define how the altitude is encoded and to what level of precision. The units for altitude are either metres, or floors, with the actual measurement being encoded in a similar manner to those for latitude and longitude, but with 22 bit integer, and 8 bit fractional components. A.3. Generating the PIDF-LO If altitude is not required, or is expressed in floors then a geodetic location expressed by a polygon SHOULD be used. If the altitude is expressed in floors and is required, the altitude SHOULD be expressed as a civic floor number as part of the same location- info element. In the example above the GML for the location would be expressed as follows: -34.4165 150.5332 -34.4165 150.5337 -34.4170 150.5537 -34.4170 150.5532 -34.4165 150.5332 If a floor number of say 3 were included, then the location-info element would contain the above information and the following: 2 When altitude is expressed as an integer and fractional component, as with the latitude and longitude, it expresses a range, and this cannot be easily expressed in polygon form. Envelopes, as described Winterbottom, et al. Expires August 8, 2006 [Page 36] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 earlier, define upper and lower bounds for rectangular enclosures, both in two and 3 dimensions, and SHOULD be used where an altitude range is specified. Care must be taken around the 180th meridian to ensure a misrepresentation does not occur should the 180th meridian be crossed. Extending the previous example to include an altitude expressed in metres rather than floors. AltRes is set to a value of 19, and the Altitude value is set to 34. Using similar techniques as shown in the latitude and longitude section, a range of altitudes between 32 metres and 40 metres is described. The Envelope would therefore be defined as follows: -34.4165 150.5337 40 -34.4170 150.5332 32 The Method value SHOULD be set to DHCP. Note that this case, the DHCP is referring to the way in which location information was delivered to the IP-device, and not necessarily how the location was determined. The timestamp value SHOULD be set to the time that location was retrieved from the DHCP server. The client application MAY insert any usage rules that are pertinent to the user of the device and that comply with [9]. A guideline is that the any retention-expiry value SHOULD NOT exceed the current lease time. The Provided-By element SHOULD NOT be populated as this is not provided by the source of the location information. The 3 completed PIDF-LO representations are provided below, and represent a location without altitude, a location with a civic Winterbottom, et al. Expires August 8, 2006 [Page 37] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 altitude, and a location represented as a 3 dimensional rectangular prism. -34.4165 150.5332 -34.4165 150.5337 -34.4170 150.5537 -34.4170 150.5532 -34.4165 150.5332 DHCP 2005-07-05T14:49:53+10:00 Winterbottom, et al. Expires August 8, 2006 [Page 38] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 -34.4165 150.5332 -34.4165 150.5337 -34.4170 150.5537 -34.4170 150.5532 -34.4165 150.5332 2 DHCP 2005-07-05T14:49:53+10:00 Winterbottom, et al. Expires August 8, 2006 [Page 39] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 -34.4165 150.5337 40 -34.4170 150.5332 32 DHCP 2005-07-05T14:49:53+10:00 Winterbottom, et al. Expires August 8, 2006 [Page 40] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 Authors' Addresses James Winterbottom Andrew Corporation Wollongong NSW Australia Email: james.winterbottom@andrew.com Martin Thomson Andrew Corporation Wollongong NSW Australia Email: martin.thomson@andrew.com Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@siemens.com Winterbottom, et al. Expires August 8, 2006 [Page 41] Internet-Draft GEOPRIV PIDIF-LO Profile February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Winterbottom, et al. Expires August 8, 2006 [Page 42]