Internet Engineering Task Force Rohan Mahy Internet Draft Cisco Systems Document: draft-mahy-spatial-simple-coord-00.txt July 2000 Expires: January, 2001 A Simple Text Format for the Spatial Location Protocol (SLoP) 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. This draft is an individual contribution. Comments should be directed to the Author. 1. Abstract The Spatial Working Group is creating a Spatial Location Protocol (SLoP) [2] for requesting the spatial location of a target user or device. SLoP is designed to carry other formats that contain the spatial location. In many cases either the SLoP client and/or server could be a small mobile device with limited processing, memory, storage, and battery life. This proposal is a simple, text- based format to carry latitude, longitude, altitude, time, and accuracy. 2. 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 [3]. 3. Motivation The Spatial Working Group is creating a Spatial Location Protocol (SLoP) for requesting the spatial location of a target user or device. SLoP is designed to carry other formats that contain the Internet Draft Simple SLoP Format July, 2000 spatial location. In many cases either the SLoP client and/or server could be a small mobile device with limited processing, memory, storage, and battery life. At a minimum, the protocol must support a simple way to send coordinates, accuracy, and time in a single geocentric coordinate system. While many formats exist for conveying latitude and longitude, few of the common formats maintain a good balance between parsing simplicity and providing exactly the required information. This proposal is a simple, easily-parsed text format for the data elements that SLoP must be capable of conveying. 4. Example An example of the proposed format follows. 45.75;-175.98;25 Thu, 20 Jun 2000 13:50:12.571 -07:00 200;5;0.05 The example refers to a target at 45.75 deg north , 175.98 deg west, at 25m above mean sea level, measured with respect to the WGS84 geodetic datum [4]. The location measurement was taken on June 20th at approximately 1:50pm PST and was horizontally accurate to 200m and vertically accurate to 5m. The second and fractional second portion of the time is accurate to 50ms. 5. Semantics The format consists of from one to three lines of text. Each line MUST terminate with CRLF. The first line is mandatory and contains latitude, longitude, and (optionally) altitude, separated by semicolons (;). The second line is optional and contains the date, time, and optionally any offset from UTC (Universal Coordinated Time). The third line is also optional, and contains horizontal accuracy, vertical accuracy, and temporal accuracy. All of the accuracy parameters are optional, but a semicolon MUST be present if additional accuracy parameters follow (see Syntax section for more details). If the third line is present, the second MUST also be present. latitude;longitude;altitude date time offset-from-UTC horizontal-accuracy;vertical-accuracy;temporal-accuracy Values for latitude and longitude shall be expressed as decimal fractions of degrees. Whole degrees of latitude shall be represented by a decimal number ranging from 0 through 90. Whole degrees of longitude shall be represented by a decimal number ranging from 0 through 180. When a decimal fraction of a degree is specified, it shall be separated from the whole number of degrees by a decimal point (the period character, "."). Decimal fractions of a degree may be expressed to the precision desired. Internet Draft Simple SLoP Format July, 2000 Latitudes north of the equator MAY be specified by a plus sign (+), or by the absence of a minus sign (-), preceding the designating degrees. Latitudes south of the Equator MUST be designated by a minus sign (-) preceding the digits designating degrees. A point on the Equator shall be assigned to the Northern Hemisphere. Longitudes east of the prime meridian shall be specified by a plus sign (+), or by the absence of a minus sign (-), preceding the designating degrees. Longitudes west of the meridian shall be designated by a minus sign (-) preceding the digits designating degrees. A point on the prime meridian shall be assigned to the Eastern Hemisphere. A point on the 180th meridian shall be assigned to the Western Hemisphere. Any spatial address with a latitude of +90 (90) or -90 degrees will specify a position at the True North or True South Poles, respectively. The component for longitude may have any legal value. The vertical coordinate (Altitude) MUST be expressed in meters above Mean Sea Level. Points at mean sea level MUST not have a negative sign. Horizontal and vertical accuracy MUST be expressed as the maximum expected number of unsigned meters of error from the provided point. Temporal accuracy MUST be expressed as the maximum expected number of unsigned seconds or fractional seconds of error from the provided time. If separate accuracy information is not provided, the number of decimal places used should reflect the precision of the measurement. If necessary to imply precision, trailing zeroes SHOULD be added as decimal placeholders. All positions MUST be measured with respect to the WGS84 geodetic datum. This format is based upon a superset of a FIPS specification for geographic point location [5]. The date and time are expressed according to UTC (Universal Coordinated Time) [6]. If UTC offset is absent, assume UTC (GMT). 6. Syntax 6.1 Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [7]. format = latlongalt CRLF [ date-time CRLF [ accuracy CRLF ]] latlongalt = lat ";" long [ ";" alt ] lat = coord long = coord alt = [sign] num accuracy = [horiz-error] [";" [vert-error] [; time-error]] horiz-error = num vert-error = num Internet Draft Simple SLoP Format July, 2000 time-error = num date-time = [day "," SP] date SP time [[SP] utcdelta] date = 1*2digit SP month SP 4digit time = 2digit ":" 2digit ":" 2digit ["." 1*digit] utcdelta = ("+" | "-") 1*2digit [":"] 2digit coord = [sign] 1*3digit [decimal-separator 1*digit] num = 1*digit [ decimal-separator 1*digit ] day = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" | "Sun" month = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" | "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec" sign = "+" | "-" decimal-separator = "." digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" CRLF = %d13 %d10 SP = %d32 6.2 Syntactical Design Decisions For simplicity, and consistency with the date line of the format (which already uses the comma for another purpose), the "." character MUST be used if a decimal separator is needed. The "," character, MUST NOT be used as a decimal separator. The date format diverges slightly from the RFC date convention. Fractional seconds are allowed in the time format (a SLoP requirement). For simplicity, text time zones MUST NOT be used. Time zone adjustments MAY be used, but only as numeric adjustments from UTC. For legibility, and consistency with several other date formats, a ":" character is permitted to separate the hour and minute portion of utcdelta. Spaces where added in several places consistent with the examples in RFC-822 [8], and with current practice. The Author assumes the missing spaces were an accidental omission in the original BNF. While parts of RFC-822 were obsoleted or ammended, the BNF for an RFC date is still not wholly replaced anywhere else. 7. Security Considerations The information carried by this format may be sensitive and private. Implementers SHOULD refer to the security requirements and recommendations in the SLoP protocol requirements draft. 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 8. References [1] S. Bradner, "The Internet Standards Process -- Revision 3", RFC2026, Internet Engineering Task Force, Oct 1996. Internet Draft Simple SLoP Format July, 2000 [2] B. Rosen, et al., "Spatial Location Protocol Requirements", Internet Draft, Internet Engineering Task Force, July 2000, draft- spatial-requirements-00.txt, work in progress. [3] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC2119 (BCP), Internet Engineering Task Force, March 1997. [4] "DoD World Geodetic System 1984 - Its Definitions and Relationships with local Geodetic Systems-TR8350.2", Department of Defense, 1984, ftp://ftp.nima.mil/pub/gg/tr8350.2/wgs84rpt.pdf [5] Department of Commerce, "Representation of geographic point locations for information interchange", Federal Information Processing Standard 70-1, Department of Commerce--National Institute of Standards and Technology, 1986. [6] B.E. Blair, "Time and frequency dissemination: an overview of principles and techniques. In: 'Time and Frequency Theory and Fundamentals'", National Bureau of Standards Monograph 140, U.S. Department of Commerce, 1974, 233-314. [7] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC2234, Internet Engineering Task Force, November 1997. [8] D. Crocker, "Standard for the format of ARPA Internet text messages", RFC822 (BCP), Internet Engineering Task Force, Aug 1982. 9. Acknowledgements Many thanks to Brian Rosen, Jose Costa-Requena, Mari Korkea-Aho, Mika Yliantila, Kenji Takahashi, Stephen Farrell, Patrick Faltstrom, Haitao Tang, and James Polk. 10. Author's Address Rohan Mahy Cisco Systems 170 W Tasman Dr, MS: SJCI/2/3 San Jose, CA 95134 Phone: +1 408 526 8570 Email: rohan@cisco.com Internet Draft Simple SLoP Format July, 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). 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.