INTERNET-DRAFT Mari Korkea-aho Internet Engineering Task Force Haitao Tang Document:draft-korkea-aho-spatial-dataset-00.txt Nokiadraft-korkea-aho-spatial-dataset-01.txt David Racz Expires:MayNovember 2001 Nokia James M. Polk Cisco Kenji Takahashi NTTNov. 2000May 2001 A Common Spatial LocationDatasetData Set < draft-korkea-aho-spatial-dataset-01.txt > Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 work proposes a commonformat and extensible frameworkdata set of expressing spatial location information in the Internet. The design aims at bridging various existing/proposed data representation formats, as well as meeting the requirements of existing/proposed location-aware applications/services. Contents 1. Introduction 2 2. Existing Spatial Location Expressions 2 3. Location Information Required by Services 3 4. Common Location Data Set 4 4.1CommonThe Elements of the Data Set 4 4.2 Syntax of the Elements56 4.3 Encoding of the Elements 8 4.3.1 XML DTD for the Data Set7 5. Extendible Framework8 4.3.2 XML Schema for the Data Set 8 4.4 An XML-encoded Location Example 10 5. Extendibility of the Data Set 11 6. Security Considerations911 7. Acknowledgements1011 8. References 12 9. Author's Addresses10 9. References 1013 1. Introduction Currently many organizations are working on location-related technologies, and how to express and provide location information to services and applications in the Internet. Such organizations are IETF, OpenGIS, 3GPP, LIF, WAP Forum, W3C, etc. Each of them basically specifies its own way of providing and expressing location information to services and applications. This raises a serious problem - the various location information formats, services, and applications will not be interoperable in the Internet. Therefore, a commonextendibleway of expressingand transferringlocation information for services and applications in the Internet is needed.This work thus proposesOne way of reaching interoperability is to have a commonformat and extensible framework of expressingdata set to express spatial location information with in the Internet. This draft proposes such a set. The design aims at bridging various existing/proposed data representation formats, as well as meeting the requirements of existing/proposed location-aware services.SecurityA more general framework enabling interoperability isonepresented in the draft "Spatial Location Payload" <draft-korkea-aho-spatial- location-payload-00.txt>. The payload allows the combination of several location data sets. It enables e.g., thekey issuescommon spatial location data set to beconsideredextended with application specific elements, or to express theprogress of the work.same location in different ways. 2. Existing Spatial Location Expressions There are many existing or proposed location expressions from a number of organizations (e.g. IETF, OpenGIS, 3GPP, LIF, WAP Forum, and W3C). Some of them are listed below: - Expression standardized for GSM and UMTS to be used internally in the mobile networks (called here "3GPP") [1] - An interface towards mobile networks in consideration by LIF [2] - The Geography Markup Language by the OpenGIS Consortium (GML) [3] - NaVigation Markup Language (NVML) [4] and Point Of Interest eXchange Language (POIX) [5] submitted to the W3C - GeoTags for HTML resource discovery [6,7] - National Marine Electronics Association (NMEA) interface and protocol [8] often used by GPS receivers - VCard and ICalendar [9, 10, 11] include elements to specify position - A Means for Expressing Location Information in the Domain NameSystem (DNS-LOC)System(DNS-LOC) [12] - Proposed Simple Text Format for the Spatial Location Protocol (SLoP) [13] In brief most of the formats express location with latitude, longitude, using WGS84 as reference datum. GML, LIF, NAVML, and POIX also enable expressions using other coordinate systems and reference datum. Some allow altitude, if the data is available. In the location expressions, altitude usually means the height above WGS84 reference ellipsoid, while it is unclear in some cases. Most of the formats focus on the specification of the location of a point object, whereas others include also the expression of object shapes (3GPP, LIF, and GML). In DNS-LOC and NVML radial size of object can be defined. When the accuracy for estimating a location is defined, it is mostly expressed as horizontal and vertical error. Though, the 3GPP proposal includes more complex accuracy descriptions. LIF, POIX, NMEA, and 3GPP include also fields for velocity/speed. It is expressed as horizontal speed in all the cases except 3GPP. The 3GPP proposal defines horizontal velocity (horizontal speed + bearing) and vertical velocity (vertical speed + vertical direction). Direction of movement is also included in LIF, POIX, and NMEA, using true and/or magnetic North. POIX and NMEA include possibility to define the course as well. 3. Location Information Required by Services Many different types of location-aware services have been identified, e.g. information services (e.g. yellow pages, point-of-interest services), navigation & guidance, notifications (ads, traffic alerts, weather services, etc.), information memorizing & association, tracking & resource management, authorization, location specific resource management and discovery, location sensitive billing, network management. It appears that most of the different services will primarily need absolute spatial location information as input. This is also the format that most existing location measurement systems can provide. Some of the services also need descriptive location such as addresses, regions, etc. This kind of information is generally created by manual input or via transformation services. Altitude and accuracy information will bring added value to services, but most of them can live without it. It is quite evident that in addition to location information it is important to attach the time of measurement to the location. This can be essential to the processing and management of location information. Other information that could bring added value to services include the orientation of the object, its moving direction, intended course, and speed. What about the size and shape of the object? This information could principally be used in two ways; firstly to describe the object which is positioned in order to determine what region it is covering (e.g. in finding, guidance, notification, tracking, authorization, resource discovery, billing and management services), secondly to indicate the region of interest or object to attach information to (finding information and information memorizing & association). Since most of the objects for positioning are of minor size (<10 m), the size and shape of an object usually do not have significance for the location of the object. It is also difficult to express shapes and sizes in an interoperable way. In fact, size and shape can be understood and specified as attributes associated to a location rather than location itself. 4. Common Location Data Set 4.1CommonThe Elements of the Data Set The proposal of a common data set is based on identified elements important to applications, and on the available data from different devices and interfaces.Co-ordinatesCoordinates and Datum (mandatory) When reviewing the various existing interfaces and data representation formats, we find that most of them support coordinates expressed in latitude, longitude, and altitude (optional) usingWGS-84WGS- 84 datum. Thus we propose to use these in the common data set, where latitude and longitude would be mandatory. In order to keep the common data set simple, no other datum or coordinate systems are supported. We have chosen to enable the optional altitude to be expressed both as theWGS- 84WGS-84 reference ellipsoid and mean sea level as reference. Location Accuracy (optional) Location accuracy is the estimation/measurement error of a location. The different interfaces include different types of accuracy information. We propose to include the most common way to express this, i.e. horizontal accuracy, by circle of radius from the positioned point, and height accuracy, by range from the positioned point. Time (mandatory) Time is the time of a measurement/fix of a location of an object. It is an important factor for location information. With the help of the time it is easier to manage location information and it enables different kinds of approximations. It is a mandatory element. Speed (optional) Speed is indicated as horizontal ground and vertical speed. This expression is chosen because many systems are able to indicate horizontal ground and vertical speed. Direction (optional) Direction indicates the direction of movement. It is expressed in a2- dimensional2-dimensional (horizontal) frame indicated by the magnetic (or true) North. Course (optional) Course indicates the direction from the current position to a defined destination. It is expressed in a 2-dimensional (horizontal) frame indicated by the magnetic (or true) North. Orientation (optional) Orientation describes the orientation of the positioned object. Orientation is often given with a local coordinate system as reference. Since this reference frame can be different for different objects, it will be difficult to make a common expression based on this. One possibility would be to attach an object type indicating directly the used reference framework. Instead of such a solution, we propose a method where the orientation is expressed in a 2-dimensional (horizontal) frame indicated by the magnetic (or true) North, and a vertical element expressed by the angle between horizontal plane and the main axis of the object.Un-specified Attributes (optional) An un-specified element is incorporated into the common set to include some application specific elements. The attributes should be relevant for location payload and not conflict with defined/existing attributes. This field should be used with consideration.4.2 Syntax of the Elements Some of the existing data formats allow different optional ways to express the data elements and include syntax information. However, in order to keep processing as simple as possible we prefer only one single way of expression.Here is theThe syntax of the elements in the common dataset:set is as follows (For more details see ABNF notation in Appendix A and formatting details in Appendix B). Element Expression format Example Coordinates -Latitude[N/S]degree.minute.second,[N|S]degree.minute.second.f, N60.08.00.235556 (mandatory) degree range [0-90], decimal fraction f in arbitrary length -Longitude[E/W]degree.minute.second,[E|W]degree.minute.second.f, E25.00.00 (mandatory) degree range [0-180], decimal fraction f in arbitrary length -Altitude above [(+)|-]x.f meter from WGS-84reference+12 datum reference ellipsoid, + above, (optional) - below,(optional)decimal fraction f in arbitrary length -Altitude abovein meter, + above, - below,[(+)|-]x.f meter from mean sea, +10 mean sea level level, + above, - below, optional) decimal fraction f in arbitrary(optional)length Location Accuracy -Horizontal by circle of radius from the 50.0 accuracy positioned point in (+)x.f meter, (optional) decimal fraction f in arbitrary length -Altitude in (+)x.f meter, decimalfraction in2.5 accuracy fraction f in arbitrary length (optional) Time [14, 15] Real time of the measurement/fix (mandatory)1999-08-15T11:16:31.0 +2:001999-08-15T11:16:31.0+2:00 YYYY-MM-DDThh:mm:ss.sTZD, where YYYY = four-digit year MM = two-digit month (01=January, etc.) DD = two-digit day of month (01-31) hh = two digits of hour (00-23) mm = two digits of minute (00-59) ss = two digits of second (00-59) s = one or more digits representing a decimal fraction of a second TZD = time zone designator (Z or +hh:mm or -hh:mm) Speed - Ground speedx.f [m/s | km/h | mph | knot ],(+)x.f [ms|kmh|mph|knot], 2.0m/sms (optional) where default meter/secondor m/s,(ms), decimal fraction f in arbitrarydecimal fractionslength - Vertical speedx.f [m/s | km/h | mph | knot ],(+)x.f [ms|kmh|mph|knot], 1.0m/sms (optional) where default meter/second (ms), decimal fraction f in arbitrarydecimal fractionslength Direction magnetic/true direction, M240 (optional) 360 degrees from North clockwise[M | T] x.f, degrees and[M|T][0-360].f degrees, where fractionalM240degrees f in arbitrary length, M default Course magnetic/true direction, M30 (optional) 360 degrees from North clockwise[M | T] x.f, degrees and[M|T][0-360].f degrees, where fractional degrees f in arbitrary length, M default Orientation - Horizontal magnetic/true direction, (optional) 360 degrees from North clockwise M240[M | T] x.f, degrees and[M|T][0-360].f, degrees, where fractional degrees f in arbitrary length, M default - Vertical (pitch)[+|-] [0-180].f[(+)|-][0-180].f degrees, fractional 0 (optional) degrees f in arbitrary lengthUn-specified attribute: value, [value] car_orientation: Attributes 360,40,20 (optional)4.3 Encoding of theData SetElements The data elements can be encoded in many different ways, e.g., text based attribute-value pairs, binary, MIME, XML, etc. In order to enable interoperability, again, we need a common way of encoding the parameters. We propose XML. The advantages of XML are that the encoding is easily understandable, human readable, and standard tools and parsers can be used. In addition to this, many of the other proposals make use of XML. A possible disadvantage of using XML is that it is quite verbose. 4.3.1 XML DTD for the Data Set TheXML.dtdXML DTD for the commonexpressiondata set is: <!-- slo_default.dtd --> <!ELEMENT SLO (POS,ALT, ALT_MSL, H_ACC, V_ACC,ALT?, ALT_MSL?, H_ACC?, V_ACC?, TIME,G_SPEED, V_SPEED, DIR, COURSE, H_ORIENT, V_ORIENT, X_ATTR)>G_SPEED?, V_SPEED?, DIR?, COURSE?, H_ORIENT?, V_ORIENT?)> <!ELEMENT POS (LAT, LONG)> <!ELEMENT LAT (#PCDATA)> <!ELEMENT LONG (#PCDATA)> <!-- Altitude --> <!ELEMENT ALT (#PCDATA)> <!ELEMENT ALT_MSL (#PCDATA)> <!-- Location Accuracy --> <!ELEMENT H_ACC (#PCDATA)><!ATTLIST H_ACC unit (ms|kmh|mph|knot) "ms"><!ELEMENT V_ACC (#PCDATA)><!ATTLIST V_ACC unit (ms|kmh|mph|knot) "ms"><!-- Time --> <!ELEMENT TIME (#PCDATA)> <!-- Speed --> <!ELEMENT G_SPEED (#PCDATA)> <!ATTLIST G_SPEED unit (ms|kmh|mph|knot) "ms"> <!ELEMENT V_SPEED (#PCDATA)> <!ATTLIST V_SPEED unit (ms|kmh|mph|knot) "ms"> <!-- Direction --> <!ELEMENT DIR (#PCDATA)> <!-- Course --> <!ELEMENT COURSE (#PCDATA)> <!-- Orientation --> <!ELEMENT H_ORIENT (#PCDATA)> <!ELEMENT V_ORIENT (#PCDATA)><!ELEMENT X_ATTR (PARAM)> <!ELEMENT PARAM (VALUE*)> <!ATTLIST PARAM name CDATA #REQUIRED> <!ELEMENT VALUE (#PCDATA)> An XML-encoded location example: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE IETF_SLO_Default PUBLIC "-//IETF//SLO default//EN" "slo_default.dtd"> <SLO> <POS> <LAT>N60.08.00.235556</LAT> <LONG> E025.00.00</LONG> </POS> <ALT>+12</ALT> <ALT_MSL>+10</ALT_MSL> <H_ACC>50.0</H_ACC> <V_ACC>2.5</V_ACC> <TIME>1999-08-15T11:16:31.0 +2:00</TIME> <G_SPEED unit=ms>2.0</G_SPEED> <V_SPEED unit=ms>1.0</V_SPEED> <DIR>M240</DIR> <COURSE>M30</COURSE> <H_ORIENT>M240</H_ORIENT> <V_ORIENT>0</V_ORIENT> <X_ATTR> <PARAM name="car_orientation"> <VALUE>360</VALUE> <VALUE>40</VALUE> <VALUE>20</VALUE> </PARAM> </X_ATTR> </SLO> 5. Extendible Framework A framework enables to express4.3.2 XML Schema for thesame location in different ways, or add extensions toData Set XML Schemas provide acertain expression. That is, the location expression can be gathered by combining different location information modules. We propose an XML-based framework. Since we assume that the XML-parser performs validation, the framework needs to include the references tomeans for defining thedtdsstructure, content and semantics of XML documents more precisely than thedata subsetsDTDs. With help of theframework. We assume that the receiving party has the required dtds, otherwise a URL pointing toXML Schema we can express thedtd should be available. One way of creatingconstraints on theframeworkdifferent data elements better. Below isto create a LOC_FRAME document that incorporatesthedtds ofXML-Schema for thedifferentcommon spatial locationrepresentation modules. Belowdata set. <?xml version="1.0"?> <xsd:schema targetNamespace="http://www-nrc.nokia.com/ietf- spatial/2001/05/08/location" xmlns:this="http:// www- nrc.nokia.com/ietf-spatial/2001/05/08/location" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="SLO" type="this:LocationData"/> <xsd:complexType name="LocationData"> <xsd:sequence> <xsd:element name="POS" type="this:POSType"/> <xsd:element name="ALT" type="xsd:decimal" minOccurs="0"/> <xsd:element name="ALT_MSL" type="xsd:decimal" minOccurs="0"/> <xsd:element name="H_ACC" type="this:NonNegativeDecimal" minOccurs="0"/> <xsd:element name="V_ACC" type="this:NonNegativeDecimal" minOccurs="0"/> <xsd:element name="TIME" type="xsd:dateTime"/> <xsd:element name="G_SPEED" type="this:Speed" minOccurs="0"/> <xsd:element name="V_SPEED" type="this:Speed" minOccurs="0"/> <xsd:element name="DIR" type="this:DegreesFromNorth" minOccurs="0"/> <xsd:element name="COURSE" type="this:DegreesFromNorth" minOccurs="0"/> <xsd:element name="H_ORIENT" type="this:DegreesFromNorth" minOccurs="0"/> <xsd:element name="V_ORIENT" type="this:PlusMinus180Decimal" minOccurs="0"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="POSType"> <xsd:sequence> <xsd:element name="LAT" type="this:LATType"/> <xsd:element name="LONG" type="this:LONGType"/> </xsd:sequence> </xsd:complexType> <xsd:simpleType name="LATType"> <xsd:restriction base="xsd:string"> <xsd:pattern value="(N|S)((\d|[0-8]\d)\.([0-5]\d)\.[0- 5]\d(\.\d+)?)|90\.00\.00(\.0+)?"/> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="LONGType"> <xsd:restriction base="xsd:string"> <xsd:pattern value="(E|W)((\d|\d\d|[0-1][0-7]\d)\.([0- 5]\d)\.[0-5]\d(\.\d+)?)|180\.00\.00(\.0+)?"/> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="DegreesFromNorth"> <xsd:restriction base="xsd:string"> <xsd:pattern value="(M?|T)((\d|\d\d|[0-3][0- 5]\d)(\.\d+)?)|(360(\.0+)?)"/> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="PlusMinus180Decimal"> <xsd:restriction base="xsd:decimal"> <xsd:minInclusive value="-180"/> <xsd:maxInclusive value="180"/> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="NonNegativeDecimal"> <xsd:restriction base="xsd:decimal"> <xsd:minInclusive value="0"/> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="SpeedUnit"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="ms"/> <xsd:enumeration value="kmh"/> <xsd:enumeration value="mph"/> <xsd:enumeration value="knot"/> </xsd:restriction> </xsd:simpleType> <xsd:complexType name="Speed"> <xsd:simpleContent> <xsd:extension base="this:NonNegativeDecimal"> <xsd:attribute name="unit" type="this:SpeedUnit" default="ms"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:schema> 4.4 An XML-encoded Location Example Here is anexample, where the framework incorporates two subsets,example of a location described using the"slo_default" subsetcommon location data set and"my_loc" subset:its XML Schema: <?xmlversion="1.0" encoding="UTF-8"?> <!DOCTYPE LOC_FRAME [ <!ENTITY % slo_default_dtd public PUBLIC "-//IETF//SLO_default//EN" "slo_default.dtd"> <!ENTITY % my_loc_dtd public PUBLIC "-//MY_LOC//My_Location//EN" "my_loc.dtd"> %slo_default_dtd; %my_loc_dtd; <!ELEMENT LOC_FRAME (SLO, MY_LOC)> ]> <LOC_FRAME> <SLO> ... </SLO> <MY_LOC> ... </MY_LOC> </LOC_FRAME> If each module is identified by an identifier (e.g.version = "1.0" encoding = "UTF-8"?> <loc:SLO xmlns:loc="http://www-nrc.nokia.com/ietf- spatial/2001/05/08/location" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www-nrc.nokia.com/ietf- spatial/2001/05/08/location http://www-nrc.nokia.com/ietf- spatial/2001/05/08/location.xsd"> <POS> <LAT>N60.08.00.235556</LAT> <LONG>E025.00.00</LONG> </POS> <ALT>+12.99</ALT> <ALT_MSL>010</ALT_MSL> <H_ACC>50</H_ACC> <V_ACC>2.5</V_ACC> <TIME>2001-01-01T12:00:01+02:00</TIME> <G_SPEED>2.0</G_SPEED> <V_SPEED unit="knot">1</V_SPEED> <DIR>M240</DIR> <COURSE>M30</COURSE> <H_ORIENT>T25</H_ORIENT> <V_ORIENT>179</V_ORIENT> </loc:SLO> 5. Extendibility of thesystem or public identifierData Set The common spatial location data set includes only a specific set of elements with clearly defined contents (The element "un-specified attributes" existing in thedocument, orprevious version was removed from theXML-root element), it will be easier to identifydata set). In this manner we can keep the data set unambiguous andto processunique. This simplifies transformation andtransformvalidation of thedata. Indata set. XML Schema [16] provides general extension mechanisms with which SLO or elements of it can be incorporated in other data sets. However, in order toavoid conflicts in the structure document,simplify transformation and processing of the different datasetssets, we recommend that application specific extensions shouldinclude unique XML-elements. This could be achieved by using XML- namespaces [16]. Another option tobefurther studied is to include the different dtds in an external dtd (e.g. SLO_MY_LOC.dtd)defined as own data sets andthen reference the dtd inattached to the common locationrepresentation document, in a similar mannerdata set asproposeddescribed in theXHTML modularizationdraft "Spatial Location Payload" [17].If used in combination with namespaces this approach would allow interleaving of elements from the different location representation data sets.6. Security Considerations Locationinformationalone usually means nothing but a "point" somewhere. However, when associated with a meaningful target such as a person, the location is potentially private or sensitive even though some parties(such as shops)may like to release their location information to the public. The authors believe thatlocation information shouldthere must bedelivered based on the policy set to the location information. In addition, certainsecurity and policy mechanismsshould be usedavailable to protect thelocation information, if required (as mostinformation whenever needed. These issues are, however, out of thecases). This should be looked into more detail when defining the complete payload for transferringscope of the definition of a common locationdata.data set. We let the location-dealing applications or protocols define or select their own specific security mechanisms for authorization, authentication, encryption, key exchange, etc. 7. Acknowledgements The authors would like to thank all those who have provided comments to this document. 8.Author's Addresses Mari Korkea-aho Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland Email: mari.korkea-aho@nokia.com Haitao Tang Nokia Research Center P.O. BOX 407 FIN-00045 Nokia Group Finland Email: haitao.tang@nokia.com James Polk Cisco Systems 18581 N. Dallas Parkway Dallas, Texas 75287 Phone: +1 972.813.5208 Email: jmpolk@cisco.com Kenji Takahashi Information Sharing Platform Laboratories NTT 3-9-11 Midoricho Musashino, Tokyo 180-8585 Japan Phone: +81 422 59 6668 Email: kt@nttlabs.com 9.References [1] 3rd Generation Partnership Project, Technical Specification Group Core Network, Universal Geographical Area Description (GAD), Release 1999, Technical Specification, 3G TS 23.032 V3.1.0 (2000-03) [2] Definition of a Mobile Location Query API, Contribution to Location Inter-operability Forum (LIF), API Specification, v. 0.5, 18 Oct 2000 [3] Lake, R., Cuthbert, A. (eds.), Geography Markup Language (GML) v1.0, OGC Document Number: 00-029, 12-May-2000, http://www.opengis.org/techno/specs/00-029.pdf [4] Sekiguchi, et al., NaVigation Markup Language (NVML), W3C Note 6 Aug 1999,http://www.w3.org/TR/NVML [5] Hiroyuki Kanemitsu, Tomihisa Kamada, POIX: Point Of Interest eXchange Language Specification, W3C Note - 24 June 1999, http://www.w3.org/TR/poix [6] Daviel, A., Geographic registration of HTML documents,<draft- daviel-html-geo-tag-03.txt>,<draft-daviel-html-geo-tag-03.txt>, April 2000, http://geotags.com/geo/draft-daviel-html-geo-tag-03.txt [7] Daviel, A., Geographic extensions for HTTP transactions, <draft-daviel-http-geo-header-02.txt>, April 2000, http://geotags.com/geo/draft-daviel-http-geo-header-02.txt [8] Bennett P., The NMEA FAQ, version 6.3, April 25, 2000, http://vancouver-webpages.com/pub/peter/nmeafaq.txt [9] Internet Mail Consortium, "vCard - The Electronic Business Card Version 2.1", September 18, 1996, http://www.imc.org/pdi/vcard-21.txt [10] Dawson, F., Howes, T. , vCard MIME Directory Profile, IETF RFC 2426, September 1998, http://www.imc.org/rfc2426 [11] Dawson, F., Stenerson, D., Internet Calendaring and Scheduling Core Object Specification (iCalendar), RFC 2445, November 1998, http://www.imc.org/rfc2445 [12] Davis, C., Vixie, P., Goodwin, T., Dickinson, I., A Means for Expressing Location Information in the Domain Name System, IETF RFC 1876, January 1996, ftp://ftp.funet.fi/pub/doc/rfc/rfc1876.txt [13] Mahy, R., A Simple Text Format for the Spatial Location Protocol (SLoP), Internet draft, July 2000, Work in progress, http://search.ietf.org/internet-drafts/draft-mahy-spatial- simple-coord-00.txt [14] Wolf, M., Wicksteed, C., W3C note, Date and Time Formats, 15 September 1997, http://www.w3.org/TR/1998/NOTE-datetime- 19980827 [15] Kuhn, M., A Summary of the International Standard Date and Time Notation, http://www.cl.cam.ac.uk/~mgk25/iso-time.html [16]Bray et al., Namespaces in XML, World Wide Web Consortium 14 January 1999, http://www.w3.org/TR/1999/REC-xml-names-19990114Fallside, D. (Ed.), XML Schema Part 0: Primer, W3C Recommendation, May 2001, http://www.w3.org/TR/xmlschema-0/ [17]Adams, et al., ModularizationKorkea-aho, M., Tang, H., Spatial Location Payload, <draft -korkea-aho-spatial-location-payload-00.txt>, Internet draft, May 2001, Work in progress 9. Author's Addresses Mari Korkea-aho Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland Email: mari.korkea-aho@iki.fi Haitao Tang Nokia Research Center P.O. BOX 407 FIN-00045 Nokia Group Finland Email: haitao.tang@nokia.com David L Racz Nokia Research Center 5 Wayside Road Burlington, MA 01803 USA Email: david.racz@nokia.com James Polk Cisco Systems 18581 N. Dallas Parkway Dallas, Texas 75287 USA Phone: +1 972.813.5208 Email: jmpolk@cisco.com Kenji Takahashi Information Sharing Platform Laboratories NTT 3-9-11 Midoricho Musashino, Tokyo 180-8585 Japan Phone: +81 422 59 6668 Email: kt@nttlabs.com Appendix A Formal Syntax ofXHTML, 20 October 2000, http://www.w3.org/TR/2000/CR-xhtml-modularization-20001020/ xhtml-modularization-20001020.htmlthe Common Data Set The syntax is specified with ABNF grammar (IETF RFC2234). ----------------------------------------------------------------- SLO = Coordinate Delimiter [Location_Accuracy Delimiter] Time Delimiter [Speed Delimiter] [Direction Delimiter] [Course Delimiter] [Orientation Delimiter] Delimiter = <any delimiter string> ; Delimiter depending on the coding Coordinate = Latitude Delimiter Longitude [Delimiter (Altitude_WGS84 | Altitude_Sea)] Latitude = ( "N" | "S" ) Degree90 "." Minute "." Second "." Fraction Degree90 = <an integer in [0, 90], leading zero allowed> Minute = "00" - "60" Second = "00" - "60" Fraction = *Digit Digit = "0" - "9" Longitude = ( "E" | "W" ) Degree180 "." Minute "." Second "." Fraction Degree180 = <an integer in [0, 180], leading zeros allowed> Altitude_WGS84 = ( [ "+" ] | "-" ) Meter "." Fraction ; height in meter from WGS-84 reference ellipsoid Meter = *Digit Fraction = *Digit Altitude_Sea = ( [ "+" ] | "-" ) Meter "." Fraction ; height in meter from mean sea level Location_Accuracy = [ Horizontal_Accuracy Delimiter] [ Height_Accuracy ] Horizontal_Accuracy = [ "+" ] Meter "." Fraction Height_Accuracy = [ "+" ] Meter "." Fraction Time = YYYY "-" MM "-" DD "T" hh ":" mm ":" ss "." s TZD YYYY = 4*4Digit MM = "01" - "12" DD = "01" - "31" hh = "00" - "23" mm = "00" - "59" ss = "00" - "59" s = *Digit TZD = "Z" | (( "+" | "-" ) hh:mm ) ; where Z means zero meridian Speed = [ Ground_speed [Delimiter Speed unit] Delimiter] [ Vertical_speed [Delimiter Speed unit]] Ground_speed = [ "+" ] *Digit "." *Digit Speed unit = ("ms" | "kmh" | "mph" | "knot") ; default: ms Vertical_speed = [ "+" ] *Digit "." *Digit Direction = Magnetic_direction | True_direction Magnetic_direction = [ "M" ] Degree360 "." Fraction Degree360 = <an integer in [0, 360], leading zeros allowed> True_direction = "T" Degree360 "." Fraction Course = Magnetic_direction | True_direction Orientation = Horizontal_orientation | Vertical_orientation Horizontal_orientation = Magnetic_direction | True_direction Vertical_orientation = ( [ "+" ] | "-" ) Degree180 "." Fraction ----------------------------------------------------------------- Appendix B Formatting Details for Common Spatial Data Set The table below shows the allowed prefixes for the different elements in the common spatial data set. The table shows also for which elements leading zeros are required. ------------------+--------------------+---------------- | Allowed prefixes | Leading Zero ------------------+--------------------+---------------- LAT degree | N|S | optional LONG degree | E|W | optional LAT/LONG minute | | required LAT/LONG second | | required ALT | [+]|- | optional ALT_MSL | [+]|- | optional H_ACC | [+] | optional V_ACC | [+] | optional G_SPEED | [+] | optional V_SPEED | [+] | optional DIR | M (default)|T | optional COURSE | M (default)|T | optional H_ORIENT | M (default)|T | optional V_ORIENT | [+]|- | optional ------------------+--------------------+---------------- ----------------------------------------------------------------- Copyright Statement Copyright (C) The Internet Society (2000). 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."