GEOPRIV K. Doran Internet-Draft R. Barnes Intended status: Informational BBN Technologies Expires: September 2, 2010 March 1, 2010 A Logical Data Model for Location Protocols draft-doran-geopriv-proto-map-00 Abstract There are currently several protocols developed by different standards organizations that implement a basic design pattern where a client requests location from a location server and the server responds with location information. This document defines a general data model for such protocols, and describes how some existing geolocation protocols can be mapped into this unified model. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 Internet-Draft will expire on September 2, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Doran & Barnes Expires September 2, 2010 [Page 1] Internet-Draft Location Protocol Model March 2010 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Data Model Overview . . . . . . . . . . . . . . . . . . . . . 5 4. Request parameters . . . . . . . . . . . . . . . . . . . . . . 6 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1.2. Callback . . . . . . . . . . . . . . . . . . . . . . . 6 4.1.3. Language . . . . . . . . . . . . . . . . . . . . . . . 6 4.1.4. Accuracy . . . . . . . . . . . . . . . . . . . . . . . 6 4.1.5. Age . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1.6. Response Time . . . . . . . . . . . . . . . . . . . . 6 4.2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.1. Protocol Name . . . . . . . . . . . . . . . . . . . . 7 4.2.2. Protocol Version . . . . . . . . . . . . . . . . . . . 7 4.2.3. Request Type . . . . . . . . . . . . . . . . . . . . . 7 4.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 7 4.3.1. Unique Identifier (UID) . . . . . . . . . . . . . . . 7 4.3.2. Network Access Identifier (NAI) . . . . . . . . . . . 7 4.3.3. Network Access Password . . . . . . . . . . . . . . . 8 4.3.4. Group . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3.5. IP Address . . . . . . . . . . . . . . . . . . . . . . 8 4.3.6. MAC Address . . . . . . . . . . . . . . . . . . . . . 8 4.3.7. Port Number . . . . . . . . . . . . . . . . . . . . . 8 4.3.8. URI . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3.9. Fully Qualified Domain Name . . . . . . . . . . . . . 8 4.3.10. [Cellular] Telephony . . . . . . . . . . . . . . . . . 8 4.4. Measurements . . . . . . . . . . . . . . . . . . . . . . . 8 4.4.1. WiFi . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4.2. Cellular . . . . . . . . . . . . . . . . . . . . . . . 9 4.4.3. w16e . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4.4. GNSS . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Other parameters . . . . . . . . . . . . . . . . . . . . . 9 5. Response parameters . . . . . . . . . . . . . . . . . . . . . 9 5.1. General parameters . . . . . . . . . . . . . . . . . . . . 9 5.1.1. Timestamp . . . . . . . . . . . . . . . . . . . . . . 9 5.1.2. Target . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Location [PIDF-LO] . . . . . . . . . . . . . . . . . . . . 9 Doran & Barnes Expires September 2, 2010 [Page 2] Internet-Draft Location Protocol Model March 2010 5.2.1. Geodetic location . . . . . . . . . . . . . . . . . . 9 5.2.2. Civic location . . . . . . . . . . . . . . . . . . . . 10 5.2.3. Location by reference . . . . . . . . . . . . . . . . 10 5.3. Other parameters . . . . . . . . . . . . . . . . . . . . . 10 6. Protocol mapping summary . . . . . . . . . . . . . . . . . . . 10 6.1. Google Gears Geolocation API Mapping . . . . . . . . . . . 10 7. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Doran & Barnes Expires September 2, 2010 [Page 3] Internet-Draft Location Protocol Model March 2010 1. Introduction Over time, the increasing mobility of Internet endpoints, and the global basis on which Internet applciations are delivered, have driven demand for geolocation information about Internet hosts. In order to respond to the demand, many different organizations have developed geolocation platforms and protocols. For example, the SUPL and MLP location protocols for cellular networks were developed in the 3GPP and OMA, while the Parlay/X location protocol for tradional fixed-line telephone networks was developed in ETSI. While many of these protocols have matured idependently, because they are similiar in purpose, the data models that they define are also similiar. While the terminoligy for data elements may vary, the definitions are often analogous, if not equivalent. Despite the clear overlap of function, different protocols continue to be used independently, perpetuating a fragmented marketplace for location services. This fragmentation did not cause problems while the domains of different protocols remained distinct. However, many different types of networks, with their own "native" location protocols, are now being used to carry IP traffic. At the same time, geolocation functiosn are being introduced as core components of modern web browsers and operating systems. These trends argue for a unification of the current space of location protocols in order to facilitate location services that are interoperable across the entire Internet. Obviously, a proliferation of protocols has practical implications as well. Without a single universal data model, developers are forced to choose which protocols to use or support in their implemetations. Server and client components have little re-usability and interoperability across protocols. Transitioning from one protocol to another is expensive and difficult. This is an unfortunate situation, espescially because it could be avoided given the similarities among protocols. In fact, if a universal data model is agreed upon, and the process for mapping various protocols to and from that data model is standardized, these problems can be resolved. This document introduces a universal geolocation data model that will meet the needs of the majority of exisiting protocols and be extensible to accomodate future protocols. This document also provides mappings of some exisiting geolocation protocols to this data model. A main goal of these mappings is to reduce confusion resulting from the use of different terminology to mean the same thing in different specifications. Doran & Barnes Expires September 2, 2010 [Page 4] Internet-Draft Location Protocol Model March 2010 2. Definitions 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 [1]. 3. Data Model Overview It is logical for the data model to consist of two top level objects: Request and Response. The two natural architectures for location sharing are pull and push style systems. In both of these systems, there is an entity that wants to know location (requester) and an entity that provides location (responder). The request object represents the messages that originate from requesters, and likewise, the response object represents messages originating from responders. A geolocation data model organized into top level request and response objects would satistfy the needs nearly all current location location protocols. Protocols that use client-request/ server-response message flows (HELD, MLP, Parlay/X, Google Gears) are well aligned to use this data model. The data model also fits into protocols that use client-subscribe/server-notify message flows (Parlay/X, [LOC]SIP). Geolocation platforms that depend on client- post location updates can also sue this data model. In short, this request/response structured data model is flexible enough to fit into many different types of protocols and message flows. The request object contains any information that is necessary/helpful for a location provider. This includes the type of request, identifiers, measurements, constraints on the response, callback URIs, and other relevant information. The response object contains any information relevant to the location requester. In addition to a location object, this includes the type of response, identifiers, time information, error messages, and any other useful information. Furthermore, a response object does not necessarily have to be used as a "response" in a message flow. It can be used by any entity that wants to send a location object to another, ie, a client posting a location update to a location server. Obviously, the standard request and response objects will not cover all elements of all protocols; hovever, they are both extensible so they can be customized for individual protocols and extended for futurue use. This document will define a standard way of generically extending the universal data model. Doran & Barnes Expires September 2, 2010 [Page 5] Internet-Draft Location Protocol Model March 2010 4. Request parameters 4.1. General Parameters listed under "General" are top level parameters not falling under any particular categorization. 4.1.1. Target The Request object MAY specify the target device to which the location request should be sent using the "target" parameter. The value of this paramter is a URI. 4.1.2. Callback The Request object MAY specify a callback address to which the location response should be sent using the "callback" parameter. The value of this paramter is a URI. In the case of a third-party location query, this field SHOULD be used to specify the address of the first-party device that is performing the lookup on behalf of the third-party device. 4.1.3. Language The Request objecy MAY define the requested langauge for a response containing a civic address using the "language" parameter. Language values should follow two-character and three-character representations defined is ISO639. 4.1.4. Accuracy The Request object MAY define the requested accuracy for a response containing a geodetic address using the "accuracy" parameter. [What units should accuracy use? How should protocols that request mutliple accuracies be mapped to the unified data model?] 4.1.5. Age The Request object MAY define the maximum age of the location in the response using the "age" parameter. [How should we handle tolerance of this request parameter if it cannot be satisfied? Let each protocol define it? Add tolerance parameters?] 4.1.6. Response Time The Request object MAY define the requested maximum response time for the location provider to respond to the location request using the "response_time" parameter. [How should this be represented? Doran & Barnes Expires September 2, 2010 [Page 6] Internet-Draft Location Protocol Model March 2010 milliseconds? let protocol decide/define untis?] 4.2. Protocol A Request object MAY define a Protocol object that defines the protocol specific aspects of the request. 4.2.1. Protocol Name The "protocol:name" parameter is a string representation of the protocol being used by the universal data model, ie "HELD". 4.2.2. Protocol Version The "protocol:version" parameter is a string representation of the version of the protocol being used, which is defined by the "protocol:name" parameter. An example value for this field is "1.1". 4.2.3. Request Type Protocols that have multiple types of requests can use this field to define what request type to use. For example, Parlay/X might use this field to distinguish a "getLocation" request from a "getTerminalDistance" request or a "startPeriodicalNotification" subscription request. 4.3. Identifiers Identifiers are parameters that identify the device that is requesting location. For third-party location queries, these should describe the third-party device, not the first-party requester. That is, if Device A requesting location on behalf of Device B, identifiers should describe Device B, and Device A can be specified via the "callback" parameter. 4.3.1. Unique Identifier (UID) The "uid" parameter MAY be used to define any Unique Identifier applicable to the protocol being represented. [ie, "DUID" for location over dhcp] A "uid" should not be confused with a network access identifier (see NAI). 4.3.2. Network Access Identifier (NAI) To be used with protocols that require authentication ie, username, user@domain [See RFC4282] Doran & Barnes Expires September 2, 2010 [Page 7] Internet-Draft Location Protocol Model March 2010 4.3.3. Network Access Password Password associated with UNI for networks that require username/ password authentication 4.3.4. Group The "group" parameter MAY be used to define a group/buddy list when looking up a location for multiple users. This is used for third- party requests. 4.3.5. IP Address The IP address of the requester can be stored using the "ip" parameter. 4.3.6. MAC Address The MAC address (bssid) of the requester can be stored using the "mac" parameter. 4.3.7. Port Number The "port" parameter MAY be used to specify the UDP or TCP Port being used. This is useful for mulitple requesters running on same IP on different ports. 4.3.8. URI A URI specifying the requester can be stored in the "uri" parameter. For a first-party location query, this SHOULD be the same as the "callback" parameter if both contain values. 4.3.9. Fully Qualified Domain Name The fully qualified domain name of the requester can be stored in the "fqdn" parameter. This should be a domain name that resolves to a SINGLE device. ie, server-1.example.com. 4.3.10. [Cellular] Telephony The "telephony" parameter can be used to store various telephony identifiers, such as MSISDN, IMSI, IMEI, MIN, MDN. 4.4. Measurements Measurements get a little bit tricky with fields, attributes, and units varying across protocols... Need to consider these factors Doran & Barnes Expires September 2, 2010 [Page 8] Internet-Draft Location Protocol Model March 2010 when deciding how to map them to a unversial data model 4.4.1. WiFi Parameters for storing WiFi Data. 4.4.2. Cellular Parameters for storing Cellular Data. 4.4.3. w16e Parameters for storing w16e Data 4.4.4. GNSS Parameters for storing GNSS Data 4.5. Other parameters Describle how the universal data model can be extended here. 5. Response parameters 5.1. General parameters Parameters listed under "General" are top level parameters not falling under any particular categorization. 5.1.1. Timestamp The time the location was discovered. 5.1.2. Target The device to receiving the response. The value of this parameter is a URI. 5.2. Location [PIDF-LO] The Location model is essentially a one-to-one mapping of a PIDF-LO. 5.2.1. Geodetic location Doran & Barnes Expires September 2, 2010 [Page 9] Internet-Draft Location Protocol Model March 2010 5.2.2. Civic location 5.2.3. Location by reference 5.3. Other parameters 6. Protocol mapping summary This section shows how existing protocols map to the above unified data model o [(model, HELD, DHCP, MLP, Gears, LOCSIP)] 6.1. Google Gears Geolocation API Mapping Doran & Barnes Expires September 2, 2010 [Page 10] Internet-Draft Location Protocol Model March 2010 +-----------------------+----------------------------+ | Request Model | Gears | +-----------------------+----------------------------+ | language | address_language | | target | host | | callback | | | accuracy | | | response_age | | | response_time | | | protocol:name | "Google Gears Geolocation" | | protocol:version | | | protocol:request_type | request_address | | identifiers:uid | access_token | | identifiers:nai | | | identifiers:nap | | | identifiers:group | | | identifiers:ip | | | identifiers:mac | | | identifiers:port | | | identifiers:uri | | | identifiers:fqdn | | | identifiers:cellular | | | measurements:wifi | WiFi Data | | measurements:cellular | Cell Data | | measurements:w16e | | | measurements:gnss | | +-----------------------+----------------------------+ Table 1: Mapping for Google Gears Geolocation API to Request Object Table 1 +--------------------------------------+-----------------------+ | Response Model | Gears | +--------------------------------------+-----------------------+ | timestamp | | | target | | | location | | | location:geo | | | location:geo:point:latitude | latitude | | location:geo:point:longitude | longitude | | location:geo:point:altitude | altitude | | location:geo:point:accuracy | accuracy | | location:geo:point:altitude_accuracy | altitude_accuracy | | location:civic | | | location:civic:language | | | location:civic:country | address:country | | location:civic:a1 | address:region | Doran & Barnes Expires September 2, 2010 [Page 11] Internet-Draft Location Protocol Model March 2010 | location:civic:a2 | address:country | | location:civic:a3 | address:city | | location:civic:a4 | | | location:civic:a5 | | | location:civic:a6 | address:street | | location:civic:prd | | | location:civic:pod | | | location:civic:sts | address:street_number | | location:civic:hno | | | location:civic:hns | | | location:civic:lmk | | | location:civic:loc | | | location:civic:name | | | location:civic:pc | address:postal_code | | location:civic:bld | address:premises | | location:civic:unit | | | location:civic:flr | | | location:civic:room | | | location:civic:plc | | | location:civic:pcn | | | location:civic:pobox | | | location:civic:addcode | | | location:civic:seat | | | location:civic:rd | | | location:civic:rdsec | | | location:civic:rdbr | | | location:civic:rdsubbr | | | location:civic:prm | | | location:civic:pom | | | location:reference | | | location:reference:uris | | +--------------------------------------+-----------------------+ Table 2: Mapping for Google Gears Geolocation API to Response Object Table 2 7. Applications This section provides use cases for the unified data model (UDM): o Implementing Single Protocol [Protocol A] Client * Pre-designed, pre-implemented data model - developers will not have to design and implement their own Doran & Barnes Expires September 2, 2010 [Page 12] Internet-Draft Location Protocol Model March 2010 * The client is already designed to support additional protocols if they are later added o Implementing Multiple Protocol [Protocols A, B, C] Client * Single Data Model, Multiple Protocols o Transitioning from Protocol A to Protocol B * Mapping in this docuemnt provides instructions for how to map Protocol A to UDM to Protocol B * All Protocol A code / components / assets can still be used, just add a translation layer o Reusing Server Components * A location server can accept multiple protocols on the front- end, normalize them all to UDM, allowing other parts of the server to be usable for all protocols (eg, logging, caching) o Interoperability of Protocols * Implement a location server that accepts [Protocol A] Requests, in case of [Protocol A] failure, it degrades to use [Protocol B], and the translation / [Protocol B] query is done server- side, with the [Protocol B] response being translate back to [Protocol A] to send to the client. 8. Privacy Considerations [Text here] 9. Security Considerations [Text here] 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, Doran & Barnes Expires September 2, 2010 [Page 13] Internet-Draft Location Protocol Model March 2010 J., and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007. [3] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [4] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and J. Polk, "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", draft-ietf-geopriv-policy-21 (work in progress), January 2010. [5] Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, "HTTP Enabled Location Delivery (HELD)", draft-ietf-geopriv-http-location-delivery-16 (work in progress), August 2009. [6] Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-06 (work in progress), September 2009. 10.2. Informative References [7] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [8] Peterson, J., Hardie, T., and J. Morris, "Implications of 'retransmission-allowed' for SIP Location Conveyance", RFC 5606, August 2009. [9] Marshall, R., "Requirements for a Location-by-Reference Mechanism", draft-ietf-geopriv-lbyr-requirements-09 (work in progress), November 2009. [10] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements", draft-ietf-geopriv-l7-lcp-ps-10 (work in progress), July 2009. [11] Polk, J., Schnizlein, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information", draft-ietf-geopriv-rfc3825bis-08 (work in progress), February 2010. Doran & Barnes Expires September 2, 2010 [Page 14] Internet-Draft Location Protocol Model March 2010 Authors' Addresses Kevin M. Doran BBN Technologies 9861 Broken Land Parkway Columbia, MD 21046 US Phone: +1 410 290 6175 Email: kdoran@bbn.com Richard L. Barnes BBN Technologies 9861 Broken Land Parkway Columbia, MD 21046 US Phone: +1 410 290 6169 Email: rbarnes@bbn.com Doran & Barnes Expires September 2, 2010 [Page 15]