Internet Draft Spatial B. Rosen Internet Draft Marconi Document: draft-rosen-spatial-requirements-00.txt Jose Costa -Requena Category: Informational Nokia Mari Korkea-Aho Nokia Mika Ylianttila University of Oulu Rohan Mahy Cisco Systems Kenji Takahashi NTT Stephen Farrell Baltimore Technologies Spatial Location Protocol Requirements 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. 1. Abstract This document describes requirements to be placed on the Spatial Location Protocol (SloP). 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]. Spatial Location Protocol (SloP) Requirements July 2000 3. Definition of Terms 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 which supplies the location of the target to the client. One end of the protocol. Client: The entity which desired to learn the location of the target. One end of the protocol. Precision: Number of digits to which the measurement is accurate Accuracy: The measurement is correct to within this maximum expected error Exactness: The precision of the reported value. Velocity: Speed and direction Orientation: Heading or bearing on or near the surface of the Earth, with respect to True North Obfuscate: To intentionally make the measurement less accurate by adding randomness. Geocentric: With respect to, or centered upon the center of gravity of the Earth. 4. Location Representation A location representation is an instantiation of the location of a target. In SLoP, location representations shall be determined through two levels of abstraction: schema and format. "Schema" defines the logical scheme the location representations are based on, such as WGS84. "Format" defines how a given schema is represented. A schema can be formatted in several ways. For example, a location determined by WGS84 can be represented in a set of longitude, latitude, and altitude or geo-centric Cartesian coordination (X, Y, Z). The protocol must: a. Define one default location representation that must be supported by all SLOP entities. b. Specify an absolute location on the earth and use WGS84 geodetic datum as reference system for the default scheme. c. Specify the format of the default scheme in longitude, latitude, altitude parameters. Altitude may be an optional parameter. d. Support other location representations than the default, including existing schemes and formats widely used in other contexts. These location representations may be absolute or descriptive. e. Specify an IANA registration process for additional representations. Spatial Location Protocol (SloP) Requirements July 2000 f. Permit at a minimum, the following values to be included in a report, providing that the specified scheme and format have such capability to specify: 1. Used location type (e.g absolute/descriptive location), framework (e.g. WGS84, UTM, etc), and syntax/format (e.g. long, lat., alt. in degrees). 2. Geocentric Position 3. Accuracy 4. Exactness 5. Time stamp (date, time, time zone) 6. Time-to-live 7. Direction 8. Velocity 9. Update frequency (??? do we want to include this?) 10. Orientation g. Permit multiple scheme/format representations in a single report. h. Client MUST be able to request certain elements of a format. i. Server MUST be able to provide certain elements of a format based on authorization policy (ex: give my speed, but not my position). j. Server MUST be able to obfuscate a (numeric/coordinate) location based on authorization policy. k. Be extendable to support new location representations. 5. Message Coding The protocol: a. MUST support multiple formats. Each format must be registered with IANA. b. MUST support a very simple format for latitude, longitude, and altitude. c. MUST support a format for timestamp. d. SHOULD have a provision to specify the accuracy of each coordinate/measurement. e. MUST support a mechanism to allow sending of multiple formats in a single payload. f. MUST gracefully handle receipt of formats clients do not understand. g. MUST be able to infer the IANA type and the beginning and end of each format without parsing the entire message (as in TLV). h. MUST support sending multiple instances of the same format within the same packet. i. MUST allow formats to contain raw binary, UTF-8, UTF-16, or UTF- 32 content. j. Must support formats which contain human-readable text. Such text SHOULD specify the appropriate language. k. MUST be extensible/flexible enough to support a future descriptive location format. Spatial Location Protocol (SloP) Requirements July 2000 l. Formats which tend to be large SHOULD support a simple compression mechanism. m. Both client and server MUST be able to send and receive formats larger than a single packet. 6. Representation Negotiation The protocol must: a. Provide a mechanism for the server to inform the client which representations it supports. Such a mechanism must be able to be invoked prior to the first location report. 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, reports are provided by the server in the format chosen by the client. e. Provide a mechanisms for the client to specify the need for periodic position updates. f. Provide a mechanism for the client and server to agree upon periodic position updates. 7. 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 TTLs 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 be globally unique. A URI of the form slop:haitao-tangs- phone@airtouch.com would be an appropriate way to identify a target, using the DNS to find the server. e. Clients MUST be able to perform DNS A and SRV lookups, and may support manual configuration and/or other methods to resolve the IP address of a suitable slop 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. Transport a. The protocol SHALL support UDP transport with retry timers for reliability. b. The protocol SHOULD support TCP as an optional transport. c. The protocol MAY support RTP and/or SCTP as optional transports Spatial Location Protocol (SloP) Requirements July 2000 d. The protocol SHALL provide a mechanism for the client to request that location reports be delivered by the server using a client specified QoS class or using the QoS class of the request. Such a mechanism SHALL be optional to implement, and SHALL use IETF DiffServ QoS classes. 9. 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) or the client, e.g. authentication mechanism, group membership(s), class-of-user, etc. d. Provide 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 unnecessarily degrade a client's expectations of privacy. g. Support anonymous use, as well as authenticated use. Anonymous use MAY require the server(s) to be able to associate location with the same (anonymous) client over time. h. Where possible make use of existing, proven security mechanisms (e.g. TLS, CMS, IPsec), in particular with respect to cryptographic transforms. i. Specify a mechanism for extending the security mechanism for additional capability. 10. Policy The protocol must: a. Provide a mandatory-to-implement, optional-to-use _Policy Enforcement Point_ mechanism. b. Provide an optional _Policy Decision Point_ mechanism. c. Specify how servers obtain policy from a policy storage facility if the Policy Decision Point mechanism is implemented. d. Specify a _Policy Information Base_. e. Provide a mechanism to restrict the information in reports by: 1. Accuracy of location 2. Frequency of report generation 3. Representation format Spatial Location Protocol (SloP) Requirements July 2000 4. Identity/class of report-requestor f. Specify the way that the PIB and class-of-user is used to restrict location information reported by interpreting policy selected by class of user. 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 13. Author's Addresses Brian Rosen Marconi 1000 FORE Drive Phone: +1 724 742 6826 Email: brian.rosen@marconi.com Jose Costa-Requena Nokia Email: Jose.Costa-Requena@nokia.com Mari Korkea-Aho Nokia Email: mari.korkea-aho@nokia.com Mika Ylianttila Centre for Wireless Communications PL 4500, Tutkijantie 2 E, FIN-90014 University of Oulu, Finland Email: over@ees2.oulu.fi Rohan Mahy Cisco Systems 170 W Tasman Dr, MS: SJCI/2/3 San Jose, CA 95134 +1 408 526 8570 rohan@cisco.com Kenji Takahashi Information Sharing Platform Laboratories NTT 3-9-11 Midoricho Musashino, Tokyo 180-8585 Japan Spatial Location Protocol (SloP) Requirements July 2000 Phone: +81 422 59 6668 e-mail: kt@nttlabs.com Stephen Farrell Baltimore Technologies 61 Fitzwilliam Lane Dublin 2. Ireland Phone: +353 1 647 7406 email: stephen.farrell@baltimore.ie 14. 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 implmentation 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