Geopriv WG James M. Polk Internet Draft Cisco Systems Document: draft-polk-geopriv-location-data-00.txt Jorge Cuellar Siemens AG Expires: October 2002 June 2003 GEOPRIV Location Data Considerations Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract This document describes the Geopriv Location Data Fields of the Location Object that MUST be present under what conditions, which fields SHOULD be present, and which MAY be present. This document does not address the privacy and security requirements of the GEOPRIV Protocol or the privacy and security requirements of the GEOPRIV LO Using Protocol. Conventions used in this document 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 RFC-2119 [2]. Polk/Cuellar Expires - December 2003 [Page 1] GEOPRIV Location Data Considerations June 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 2. Location Data Objective . . . . . . . . . . . . . . . . . . . 3 3. Location Data . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Coordinate Location Data Type . . . . . . . . . . . . . . . . 4 4.1 Coordinate Location - Latitude (Lat) . . . . . . . . . . 5 4.1.1 Coordinate Location - Latitude Resolution (LaRes). . . . 5 4.2 Coordinate Location - Longitude (Long) . . . . . . . . . 6 4.2.1 Coordinate Location - Longitude Resolution (LoRes) . . . 6 4.3 Coordinate Location - Altitude (Alt) . . . . . . . . . . 7 4.3.1 Coordinate Location - Altitude Resolution (AltRes) . . . 7 4.3.2 Coordinate Location - Altitude Measurement Unit (MU) . . 7 4.4 Coordinate Location - Datum (Datum) . . . . . . . . . . 7 5. Civil Location Data Type . . . . . . . . . . . . . . . . . . 8 6. Independent Location Data Fields . . . . . . . . . . . . . . 8 6.1 Distance Fields . . . . . . . . . . . . . . . . . . . . . 8 6.2 Direction Fields . . . . . . . . . . . . . . . . . . . . 9 6.3 Speed Fields . . . . . . . . . . . . . . . . . . . . . . 9 6.4 Angle or Position Fields . . . . . . . . . . . . . . . . 9 6.5 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 10 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 12. Author Information . . . . . . . . . . . . . . . . . . . . . 12 13. Full Copyright Statement . . . . . . . . . . . . . . . . . . 12 1. Introduction This document describes the Geopriv Location Data Fields of the Location Object that MUST be present under what conditions, which fields SHOULD be present, and which MAY be present. This document does not address the privacy and security requirements of the GEOPRIV Protocol or the privacy and security requirements of the GEOPRIV LO Using Protocol described in [3], which is out of scope here. The presented set or list of Location Data Fields is not all- inclusive, but fields that are relevant to the WG at this time. Location Data is to be defined in several ways within Geopriv in regards to a Location Target - and should always be understood in the context of a Geopriv Target (the entity device whose location is sought). The Target might be associated with a person (Joe), or it might be associated with a building (a particular pizza restaurant). First is the data contained within a single field (i.e. Latitude or cube number or velocity of the target). These fields are defined Polk/Cuellar Expires - December 2003 [Page 2] GEOPRIV Location Data Considerations June 2003 within this document and are categorized as: MUST be present in a Location Object (LO), SHOULD be present in the LO, or MAY be present in the LO. These fields are also characterized as being individually independent (meaning a particular field can be present independently of any other field being present - such as velocity); while other fields are characterized as being dependent on another present field for relevance (such as a Latitude field requiring a Datum field for exactness of the position of a target with respect to a meridian). 1.1 Motivation This document attempts to open up discussion on the location fields that can be carried within the Geopriv Location Object. 1.2 Definitions Here is listed the Geopriv components as well as other significant terms that are not defined and scoped from the (section below that this document is about). Meridian - An imaginary great circle on the earth's surface passing through both the North and South geographic poles. All points on the same meridian have the same longitude Other definitions may be found in [3]. 2. Location Data Objective The objective of Location Data is to convey the location of the Geopriv Target to another entity. The Target might, through policy, alter the precision of resolution of the data provided, but should not lie. Various reasons might be valid to reveal more or less precise resolution to a location request from another entity. Those reasons for the level of precision conveyed are left to the Target, or the domain the Target is within (i.e. a matter of policy - which is out of scope for this document). 3. Location Data <> 4. Coordinate Location Data Type This Geopriv Location Data Type (LDT) represents location information involving coordinate mapping systems. Some mapping systems focus on a 2-dimensional location (two intersecting lines), and others focus on a 3-dimensional location (three intersection lines). Typically the 2D mapping system provides coordinates in Latitude and Longitude. While 3D mapping systems add altitude to latitude and longitude. From this we can conclude that a 2D Coordinate Data Type MUST include Latitude, Longitude; while a 3D Coordinate Data Type MUST add Altitude. All mapping systems must start at some point of reference, called the meridian (what is " 0 " on a map). The most common meridian used throughout the world is Greenwich. Datums define the meridian to be used. Unless otherwise stated, for Coordinate Data Types, the starting point is Greenwich for Longitude, the Equator for Latitude, and mean-low-tide for Altitude. The scope of each coordinate field is explained in the following subsections. Also provided is the mandatory list of dependant fields that also must be present per location field, and the fields that are related/optional. An example of this is Latitude. By itself, it only provides the location of a line (just a longitude does). But when Longitude is included with latitude, a point on the earth is described. So in this sense, the longitude field is dependant on latitude field being present to provide meaningful location information. The reverse is true as well. A related field to Lat and Long is Altitude. Altitude is not mandatory to determine a point on a 2D map (it is for a 3D map), therefore it is considered related, or optional. An example of unrelated or independent location fields is Latitude and slope. However useful slope might be in describing the Target, these two fields are not dependant on each other to make an Polk/Cuellar Expires - December 2003 [Page 4] GEOPRIV Location Data Considerations June 2003 otherwise partial location field complete in 2D or 3D. 4.1 Coordinate Location - Latitude (Lat) Latitude is defined as the angular distance north or south of the earth's equator, measured in degrees along a meridian, as on a map or globe; +90 degrees representing the North Pole; -90 degrees representing the South Pole. Each degree can be fractionalized indefinitely, though this is impractical. [4] scopes a reasonable minimum fraction of a degree of Latitude to within 3.11mm or 0.0000002 of a degree. Values can be in either decimal format, binary format, or hexadecimal format - there MUST be an indication of which numbering format is used within the Location Data Type (of the Location Object). This numbering format MUST be consistent with the one used for Longitude. Latitude field dependencies: - having the Longitude field also present to provide a 2D point on a map - If the location Data Type requires a 3D point, then the Altitude field must also be present Related fields: - Altitude to provide a third axis point of location reference - Latitude Resolution field would provide the exactness of the value given One possibility when the exactness of latitude is known by the responding Location Server (provided the exactness isn't unnecessarily small), is to provide 2 latitude fields to give a upper and lower boundary of where the target is with respect to Latitude. 4.1.1 Coordinate Location - Latitude Resolution (LaRes) In [4], there is described a location field Latitude Resolution. This is provided as an efficient means of placing boundaries on a Latitude field value in binary (see appendix A and B of that document for a 2 mathematical examples of how this LaRes field refines or reduces the boundaries in which a target is within). This is not a straightforward in decimal or hexadecimal formats. This subsection, therefore, needs more work. Polk/Cuellar Expires - December 2003 [Page 5] GEOPRIV Location Data Considerations June 2003 4.2 Coordinate Location - Longitude (Long) Longitude is defined as Angular distance on the earth's surface, measured east or west from the prime meridian of a given datum, to the meridian passing through a position, expressed in degrees (and fractions of a degree); 0 degrees representing the meridian; positive degrees as traveling East, negative degrees as traveling West; can be represented by +/-180 degrees bisecting the earth in either direction away from the datum meridian. Each degree can be fractionalized infinitely, though this is impractical. [4] scopes a reasonable minimum fraction of a degree of Longitude to within 2.42mm or 0.0000004 of a degree. Values can be in either decimal format, binary format, or hexadecimal format - there MUST be an indication of which numbering format is used within the Location Data Type (of the Location Object). This numbering format MUST be consistent with the one used for Latitude. Longitude field dependencies: - having the Latitude field also present to provide a 2D point on a map - If the location Data Type requires a 3D point, then the Altitude field must also be present Related fields: - Altitude to provide a third axis point of location reference - Longitude Resolution field would provide the exactness of the value given One possibility when the exactness of Longitude is known by the responding Location Server (provided the exactness isn't one point), is to provide 2 longitude fields to give a left and right (West and East) boundary of where the target is with respect to Longitude. 4.2.1 Coordinate Location - Longitude Resolution (LoRes) In [4], there is described a location field Longitude Resolution. This is provided as an efficient means of placing boundaries on a Longitude field value in binary (see appendix A and B of that document for a 2 mathematical examples of how this LaRes field refines or reduces the boundaries in which a target is within). This is not a straightforward in decimal or hexadecimal formats. This subsection, therefore, needs more work. Polk/Cuellar Expires - December 2003 [Page 6] GEOPRIV Location Data Considerations June 2003 4.3 Coordinate Location - Altitude (Alt) Altitude is defined as the space extended upward above a reference level, especially above sea level or above the earth's surface; height; the perpendicular elevation of an object above a given level, above the ground; as, the altitude of a mountain, or of a building. The base Altitude is considered Mean Low Tide, unless otherwise stated in the definition of the field (building floors being an example of an exception). Direct field dependencies are: - the Measurement Unit field to provide the necessary unit of length (meters, building floors, kilometers, etc) for this field value to read properly Related fields: - having the Longitude field and Latitude fields to provide a three axis point of location reference 4.3.1 Coordinate Location - Altitude Resolution (AltRes) This subsection needs more work. 4.3.2 Coordinate Location - Altitude Measurement Unit (MU) This field is a dependant field for the Altitude Field that gives the Altitude field value a unit of measurement (i.e. meters). The units of measure that MUST be supported are: meters, building floors (include the definition of mezzanines and sub-basements) and what represents the surface of the earth (i.e. the ground) outside of any structures. MU field dependencies are: - This field need not be present if the Altitude field is not present. It provides no useful information by itself. Related fields: - none at this time 4.4 Coordinate Location - Datum (Datum) The Map Datum used for the coordinates given (DHCP Option [TBD] specifies 4 for Geopriv currently): Polk/Cuellar Expires - December 2003 [Page 7] GEOPRIV Location Data Considerations June 2003 1: WGS84 (Geographical 3D) - World Geodesic System 1984, CRS Code 4327, Prime Meridian Name: Greenwich 2: ED50 - European Datum 1950(77), CRS Code 4154, Prime Meridian Name: Greenwich 3: ED87 - European Datum 1987, CRS Code 4231, Prime Meridian Name: Greenwich 4: NAD83 - North American Datum 1983, CRS Code 4269, Prime Meridian Name: Greenwich 5. Civil Location Data Type In [5] a Civil Location format is described. At this time, there are a number of suggestions within that document that will need to be further examined for incorporation within this document. This is not a meant as anything other than the two sets of authors for this document and the document at [5] need to collaborate more. 6. Independent Location Data Fields The following section describes the data fields that are optional; meaning they can be included in any order and in any combination with other optional location data fields, as well as with either Location Data Type (Coordinate or Civil). <> <>. 6.1 Distance Fields The fields in this subsection relate to distance to or from the Target and another location (i.e. how far is the Target from the pizza restaurant?). Distance is defined as the length or numerical value of a known measurement unit of a straight line or curve between two objects or places. Potential Geopriv fields related to a Target that could be created have the following descriptions (this is not a complete list of reasonable fields for Distance) - Distance to/from a known physical Object (i.e. a place) Polk/Cuellar Expires - December 2003 [Page 8] GEOPRIV Location Data Considerations June 2003 - Distance to/from another Geopriv Entity - Direction towards that other Geopriv Entity - Distance from a line - as in how far away from a certain Lat or Long value 6.2 Direction Fields The fields in this subsection relate to the direction the Target is facing, turning or moving towards. Potential Geopriv fields related to a Target that could be created have the following descriptions (this is not a complete list of reasonable fields for Direction) - Direction (of the LT) - unit of measurement of direction (degrees or NSEW) - indicator whether this direction is changing, and which way - vector (of the target) - Nautical Dead Reckoning 6.3 Speed Fields The fields in this subsection relate to the speed/velocity the Target is traveling or turning in any one direction. Potential Geopriv fields related to a Target that could be created have the following descriptions (this is not a complete list of reasonable fields for speed/velocity). Speed is defined at distance traveled divided by the time of travel. - Speed/velocity (of the LT) - unit of measurement of speed (mph, nmph, kmph, fps, mps, etc) - indicator whether this speed is changing, and which way - The rate at which the target is turning 6.4 Angle or Position Fields The fields in this subsection relate to the angle/position the Target is in any one time (perhaps to include if these values are individually changing). Potential Geopriv fields related to a Target Polk/Cuellar Expires - December 2003 [Page 9] GEOPRIV Location Data Considerations June 2003 that could be created have the following descriptions (this is not a complete list of reasonable fields for angle/position). - Pitch - with 0 degrees as the forward facing horizon, positive (0 to +180) degrees and negative (-1 to -180) degrees elevation are given within this field. - To oscillate about a lateral axis so that the nose lifts or descends in relation to the tail. Used of an aircraft. - To oscillate about a lateral axis that is both perpendicular to the longitudinal axis and horizontal to the earth. Used of a missile or spacecraft. - tilt - To oscillate about a longitudinal axis so that the nose moves laterally (left or right) in relation to the tail. Used of an aircraft. - To oscillate about a longitudinal axis that is both perpendicular to the lateral axis and horizontal to the earth. Used of a missile or spacecraft. - yaw - To turn about the vertical axis. Used of an aircraft, spacecraft, or projectile. - a deviation from a straight course in steering - an erratic deflection from an intended course - deviate erratically form a set course, as of a ship - become deflected 6.5. Miscellaneous - Temperature (of LT) o-indicate if temp is changing, and which way Polk/Cuellar Expires - December 2003 [Page 10] GEOPRIV Location Data Considerations June 2003 7. Open Issues - Timestamps of when the target was observed at a particular location - Timestamp of when the LO was sent or delivered 8. Security Considerations The Security Considerations for this Location Data will be solved within another document detailing how privacy and confidentiality will be accomplished for the Location Data of a Target... 9. IANA Considerations None within this document 10. Acknowledgements None at this time 11. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [3] Cuellar, J.R., Morris, J.B., Mulligan, D., Peterson, J., Polk, J., Geopriv Requirements, work in progress, March 2003 [4] Schnizlein, J., Polk, J., Linsner, M., DHC Location Object within GEOPRIV, work in progress, Jan 2003 [5] Schulzrinne, H., DHCP Option for Civil Location, work in progress, Feb 2003 Polk/Cuellar Expires - December 2003 [Page 11] GEOPRIV Location Data Considerations June 2003 12. Author Information James M. Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, Texas 75082 USA Email: jmpolk@cisco.com Jorge R Cuellar Siemens AG Corporate Technology CT IC 3 81730 Munich Email: jorge.cuellar@siemens.com 13. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Polk/Cuellar Expires - December 2003 [Page 12]