INTERNET-DRAFT Mari Korkea-aho draft-korkea-aho-spatial-location-payload-00.txt Haitao Tang Expires: November 2001 Nokia May 2001 Spatial Location Payload < draft-korkea-aho-spatial-location-payload-00.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 document defines the syntax and coding for the spatial location payload, which can hold various spatial location data sets. 1. Introduction There are very many different ways of representing location information and different location-based applications can require different spatial location data. [1] This document defines a common Spatial Location Payload, to carry any spatial location data set, e.g., the common spatial location defined in [1], the descriptive location defined in [2], or any other location data. The advantage of the Payload is that there will be a general way of expressing different location data sets, enabling interoperability and use of common tools. In addition, the Payload will e.g. enable a location to be expressed in many different ways, or combining different location data sets (e.g. the common spatial location data set SLO [1] and some application specific extensions). Internet Draft Spatial Location Payload May 2001 2. Spatial Location Payload Structure The Payload can include any number of location data sets (Fig. 1.) and their associated elements. It could e.g. contain the common spatial location set SLO [1] and some application specific extensions to SLO. (Note: Instead of combining the common spatial location set SLO and the application specific extensions in the Payload, SLO and the extensions can be defined as a common data set using DTD or XML Schema extension mechanisms [1]. However, in order to simplify translation and processing we recommend defining extensions as own separate data sets). +-Payload-----------------+ +-Payload-----------------+ | | | | | +---------------------+ | | +---------------------+ | | | Elements of | | | | | | | | location data set 1 | | | |SLO data elements [1]| | | +---------------------+ | | | | | | | e.g. | +---------------------+ | | +---------------------+ | | | | | Elements of | | | +---------------------+ | | | location data set 2 | | | | | | | +---------------------+ | | | Extensions to SLO | | | | | | | | | +---------------------+ | | +---------------------+ | | | Elements of | | | | | | location data set n | | +-------------------------+ | +---------------------+ | | | +-------------------------+ Figure 1. Payload structure and example 3. Syntax of Spatial Location Payload The syntax is specified with ABNF grammar (RFC2234). Further explanation and example are given in the next section. ==================================================================== Spatial-Location-payload = *(Location-Content Delimiter) Location-Content = Coordinate-Location | Descriptive-Location | Any- Other-Location Coordinate-Location = ; e.g., those defined in [1, 3-7], while the M. Korkea-aho, H. Tang [Page 2] Internet Draft Spatial Location Payload May 2001 ; common spatial location data set [1] is ; recommended to be when there is no other ; mutually understood/preferred location format ; between the involved parties Descriptive-Location = ; e.g., a descriptive location define in [2] Any-Other-Location = Delimiter = ; e.g., when using XML-based coding, it ; "is" a pair of corresponding element ; tags ==================================================================== 4. Coding Spatial Location Payload with XML The location Payload could be encoded in many different ways, e.g., text based attribute-value pairs, binary, MIME, XML, etc. In order to enable interoperability, we need a common way for coding the payload. We propose XML. The advantages of XML are that the encoding is easily understandable and human readable. Standard tools and parsers can be used. In addition, many of the other proposals make use of XML, while a possible disadvantage of using XML is that it is quite verbose. 4.1 DTD-based solution For the correct parsing, we need only those DTDs defined for the different location elements carried in the payload. Here is an example case of a spatial location payload. It carries two element sets, SLO [1] and a descriptive location data set dls-finnish1 [2]. Example XML Payload message using DTDs: ==================================================================== %slo-default-dtd; %dls-finnish1-dtd; ]> M. Korkea-aho, H. Tang [Page 3] Internet Draft Spatial Location Payload May 2001 N60.08.00.235556 E025.00.00 +12.99 010 50 2.5 Samitie 8 D 35 00900 Helsinki Finland ==================================================================== In order to avoid conflicts in the payload, the elements of the different location data sets in the payload should be unique. This can be achieved by using XML namespaces [8]. 4.2 XML Schema-based solution For the correct parsing, we need only the XML schemas defined for the different location elements carried in the payload. Here is an example. It carries two element sets, SLO [1] and a data set "car" of an imaginary car application (see Appendix A.2 for XML schema). Example XML Payload message using XML schemas: ==================================================================== N60.08.00.235556 E025.00.00 M. Korkea-aho, H. Tang [Page 4] Internet Draft Spatial Location Payload May 2001 +12.99 010 50 2.5 2.0 1 M240 M30 T25 179 360 40 20 gps4everyone ==================================================================== 5. Naming of Data Sets If each data set has a unique identifier, the different data sets can be identified. This simplifies the processing and possible transformation between different representation formats. In the Payload the different data sets are currently identified by: a) in the DTD-based solution: the DTD URI or public identifier. b) in the Schema-based solution: the Schema URI or namespace. 6. Other Considerations Security. Location alone 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 may like to release their location information to M. Korkea-aho, H. Tang [Page 5] Internet Draft Spatial Location Payload May 2001 the public. The authors believe that there must be security mechanisms available to protect the information whenever needed. However, we let the location-dealing applications or protocols define or select their own specific mechanisms for authorization, authentication, encryption, key exchanging, etc. 7. References [1] M. Korkea-aho, et al., "A Common Spatial Location Dataset," IETF Draft (draft-korkea-aho-spatial-dataset-01.txt), Work in progress, May 2001. [2] H. Tang, et al., "Common Syntax and Coding for Descriptive Location," IETF Draft (draft-tang-spatial-descriptive-location- 00.txt), Work in progress, May 2001. [3] 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). [4] Definition of a Mobile Location Query API, Contribution to Location Inter-operability Forum (LIF), API Specification, v.0.5, 18 Oct 2000. [5] 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. [6] Sekiguchi, et al., NaVigation Markup Language (NVML), W3C Note 6 Aug 1999,http://www.w3.org/TR/NVML. [7] Hiroyuki Kanemitsu, Tomihisa Kamada, POIX: Point Of Interest eXchange Language Specification, W3C Note - 24 June 1999, http://www.w3.org/TR/poix. [8] Bray et al., Namespaces in XML, World Wide Web Consortium 14 January 1999, http://www.w3.org/TR/1999/REC-xml-names-19990114 [9] Fallside, D. (Ed.), XML Schema Part 0: Primer, W3C Recommendation, May 2001, http://www.w3.org/TR/xmlschema-0/ Author's Addresses Mari Korkea-aho P.O. Box 407, FIN-00045 Nokia Finland Email: mari.korkea-aho@iki.fi M. Korkea-aho, H. Tang [Page 6] Internet Draft Spatial Location Payload May 2001 Haitao Tang P.O. Box 407, FIN-00045 Nokia Finland Email: haitao.tang@nokia.com Appendix A.1 XML DTD for a set of location elements of an imaginary car application. Appendix A.2 XML Schema for a set of location elements of an imaginary car application. M. Korkea-aho, H. Tang [Page 7] Internet Draft Spatial Location Payload May 2001 Copyright Statement Copyright (C) The Internet Society (2001). 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." M. Korkea-aho, H. Tang [Page 8]