Internet Engineering Task Force Haitao Tang Internet Draft Nokia Document: draft-tang-spatial-payload-reqs-00.txt James M. Polk Expires: May 2001 Cisco Systems Mari Korkea-aho Nokia Kenji Takahashi NTT Nov. 2000 Spatial Location Payload Requirements with Protocol Recommendations 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. 1. Abstract This document describes the requirements placed on the Spatial Location Payload (SLO), as well as its specific protocol recommendations, regardless of the Protocol utilized. Internet Draft draft-tang-spatial-payload-reqs-00.txt Nov.2000 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 [2]. 3. Definition of Terms Although the following terms cannot be IANA registered (because we are not defining a Protocol), they are included here for clarification purposes. Target: The entity whose location is known by the server and desired by the client. The protocol does not specify how the server learns the location of the target. Server: Entity that supplies the location of the target to the client. One end of the protocol. Client: The entity that desired to learn the location of the target. One end of the protocol. Coordinate: An ordered set of N numbers designating the position of a point in an N-dimensional space. Geodetic Datum: A set of parameters describing the size and shape of the earth and the origin and orientation of the coordinate systems used to map the earth. Location Accuracy: The measurement is correct to within this maximum expected error. Time: Real time of the measurement/fix of the target location. Speed: Ground speed and Vertical speed of the target. Direction: The direction of the target movement, expressed in a 2- dimensional (horizontal) frame indicated by the magnetic (or true) North. Course: The direction from the current position of the target to a defined destination, expressed in a 2-dimensional (horizontal) frame indicated by the magnetic (or true) North. Orientation: The orientation of the target, expressed in a 2-dimensional (horizontal) frame indicated by the magnetic (or true) North, and a vertical element expressed by the angle between the horizontal plane and the main axis of the object. 4. Location Representation A location representation is an instantiation of the location of a target. In SLO, location representations shall be determined through two levels of abstraction: schema and format. Tang, Polk, Korkea-aho, and Takahashi [Page 2] Internet Draft draft-tang-spatial-payload-reqs-00.txt Nov.2000 "Schema" defines the logical scheme which the location representations are based on. For example, location is expressed with latitude, longitude, and altitude using WGS-84 as reference system. Velocity is expressed as horizontal and vertical elements. "Format" defines how a given schema is represented. For example, a location determined by longitude, latitude, and altitude can be represented by degrees, minutes, and seconds with arbitrary decimal fractions. The velocity can be represented in meters per second with arbitrary decimal fractions. The payload must: a. Define one default location representation that must be supported by all SLO entities. _ The scheme for the default location representation must specify an absolute location on the earth, using WGS-84 geodetic datum as reference system. - The format for the default location representation must specify the location in longitude, latitude, and altitude parameters. Altitude is a recommended (must be provided if available) parameter. b. Support other location representations than the default, including existing schemes and formats widely used in other contexts. c. Specify an IANA registration process for additional representations. d. Permit at a minimum, the following values to be included in a payload, providing that the entities have such capability to specify: (1) Used Coordinate (e.g., long, lat., alt. in degrees) and datum (e.g., WGS-84) (2) Geocentric Position (3) Location Accuracy (4) Time (date, time, time zone) (5) Speed (ground speed, vertical speed) (6) Direction (7) Course (8) Orientation (9) Other un-specified attributes, such as descriptive location. e. Permit multiple scheme/format representations in a single payload. f. Be extendable to support new location representations. 5. Security Methods Operations on SLO payloads, such as retrieval of a particular element of a payload, must be defined and implemented to enforce security (including privacy) protection. Such operations MUST: a. Provide a mandatory-to-implement, optional-to-use method for an entity to retrieve encrypted elements inside the payload. The method should allow a choice in the algorithm(s) used. b. The method SHALL work according to the policy attributes set to the elements, as well as other (possibly multiple) attributes such as the identity (or anonymity) of the target/client and its class-of-user. c. Provide a mandatory-to-implement, optional-to-use data integrity and data origin authentication method for the payload. The method should allow a choice in the algorithm(s) used. d. Not degrade a target/client's expectations of privacy. 6. Identity and Policy Attributes Tang, Polk, Korkea-aho, and Takahashi [Page 3] Internet Draft draft-tang-spatial-payload-reqs-00.txt Nov.2000 The payload MUST: a. Specify the mandatory-to-implement, optional-to-use target identifier and policy attributes for an entity to retrieve the encrypted elements inside the payload, and for an entity to identify/name the target of the payload. b. Specify the way that the policy attributes and client identity/class- of-user are used to restrict location information (e.g., location accuracy and locatability) retrieved by interpreting policy selected for class-of-user. c. Protocols SHALL use the target identifier in any target-related actions (e.g., Server Discovery). d. Target identifier SHALL be given according to 8.2.c. 7. Payload Encoding The payload encoding: a. MUST support multiple formats. Each format must be registered with IANA. b. MUST support a simple format for the values in Sec 4., 5., and 6. c. SHOULD have a provision to specify the location accuracy. d. MUST be able to infer the IANA type and the beginning and end of each format without parsing the entire message (as in TLV). e. MUST allow formats to contain UTF-8 (mandatory) and the optional (raw binary, local character sets, UTF-16, and UTF-32) content. f. Must support formats that contain human-readable text. Such text SHOULD specify the language to be used. g. MUST be extensible/flexible enough to support a future descriptive location format. 8. Protocol Recommendations A SLO can be used/carried by various relevant protocols. Due to the nature of location information, the following recommendations are made to those protocols for the proper usage: 8.1 Representation Negotiation The protocol must: a. Provide a mechanism for a client to indicate which additional representations it prefers. b. Provide a mechanism for the client to select which of said representations it prefers. c. Provide the capability to provide reports in any representation d. Provide that, following such selection, server reports in the format chosen by the client. 8.2. Server Discovery a. There SHALL be a server discovery mechanism for a client to find the appropriate server for a given target. b. The discovery mechanism SHALL work across domains. It SHOULD use widely deployed mechanisms such as DNS. It SHALL permit server locations to be changed with TTL's ranging from minutes to months. c. Targets SHALL be identified with an identifier. The target identifier SHALL be unique within the domain of the server. d. Servers SHALL be identified by an identifier. Server names SHALL Tang, Polk, Korkea-aho, and Takahashi [Page 4] Internet Draft draft-tang-spatial-payload-reqs-00.txt Nov.2000 be globally unique. For example, a URI of the form "protocol:haitao- tangs-phone@airtouch.com" would be an appropriate way to identify a target. DNS is then used to find the server. e. Clients MUST be able to perform DNS A, A6, AAAA, and SRV lookups, and may support manual configuration and/or other methods to resolve the IP address of a suitable server in an unqualified domain. f. Translator services should be distinguishable from other servers during discovery. g. It is desirable that translator capabilities (supported formats) can be determined during discovery. 8.3. Protocol Security The protocol must: a. Provide a mandatory-to-implement, optional-to-use authentication mechanism from client to server and from server to client. The mechanism should allow a choice in the algorithm(s) used. b. Specify how such a mechanism shall be used in the presence of firewalls and Network Address Translation (NAT) between client and server. c. Include mechanisms to allow subsequent location policy decisions to be based on (possibly multiple) factors in addition to the identity (or anonymity) of the target/client, e.g., authentication mechanism, group membership(s), and class-of-user. d. Support a mandatory-to-implement, optional-to-use data integrity and data origin authentication mechanism for all data. The mechanism should allow a choice in the algorithm(s) used. e. Provide a mandatory-to-implement, optional-to-use data confidentiality mechanism. The mechanism should allow a choice in the algorithm(s) used. f. Not degrade a target/client's expectations of privacy. g. Support anonymous use, authenticated use, as well as the combined use of the both. Anonymous use MAY require the server(s) to be able to associate location with the same (anonymous) target/client over time. The anonymous party MAY want to authenticate the other parties (i.e., who gets/provides the location). In addition, the legitimacy of the anonymous party MAY need to be authenticated. h. Specify a mechanism for extending the security mechanism for additional capability. i. Not dictate the ways how a target should communicate relevant information with a server, or/and a client, given such communication is needed. The ways MUST NOT degrade a target/client/server's expectations of privacy. 8.4. Protocol Policy To direct the proper dealing with the target/client's information, the protocol must: a. Specify a Policy Information Base (PIB), as well as classes of user for spatial location server. b. Specify the way that the PIB and classes of user are used to control the access of a client by the location server. c. Provide a mandatory-to-implement, optional-to-use Policy Enforcement Point_mechanism. d. Provide an optional Policy Decision Point_mechanism. e. Specify how servers obtain policy from a policy storage facility if the Policy Decision Point mechanism is implemented. Tang, Polk, Korkea-aho, and Takahashi [Page 5] Internet Draft draft-tang-spatial-payload-reqs-00.txt Nov.2000 f. Provide a mechanism to direct the server's protection of the location information from any unwanted party by: 1. Locatability control 2. Security mechanisms. 9. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFC's to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] B. Rosen, J. Costa-Requena, M. Korkea-aho, M. Ylianttila, R. Mahy, K. Takahashi, and S. Farrell, "Spatial Location Protocol Requirements", Internet Draft draft-rosen-spatial-requirements-00.txt, July 2000. 10. Author's Addresses Haitao Tang Nokia Research Center P.O. BOX 407 FIN-00045 Nokia Group Finland Phone: +358 40 749 9256 Email: haitao.tang@nokia.com James M. Polk Office of the CTO Cisco Systems, Inc. 18581 North Dallas Parkway Dallas, TX 75287 USA Phone: +1 972 813 5208 Email: jmpolk@cisco.com Mari Korkea-aho Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland Phone: +358 40 733 9693 Email: mari.korkea-aho@nokia.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 Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. Tang, Polk, Korkea-aho, and Takahashi [Page 6] Internet Draft draft-tang-spatial-payload-reqs-00.txt Nov.2000 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." Tang, Polk, Korkea-aho, and Takahashi [Page 7]