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 3, 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 (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
2.  Definitions
3.  Data Model Overview
4.  Request parameters
    4.1.  General
        4.1.1.  Target
        4.1.2.  Callback
        4.1.3.  Language
        4.1.4.  Accuracy
        4.1.5.  Age
        4.1.6.  Response Time
    4.2.  Protocol
        4.2.1.  Protocol Name
        4.2.2.  Protocol Version
        4.2.3.  Request Type
    4.3.  Identifiers
        4.3.1.  Unique Identifier (UID)
        4.3.2.  Network Access Identifier (NAI)
        4.3.3.  Network Access Password
        4.3.4.  Group
        4.3.5.  IP Address
        4.3.6.  MAC Address
        4.3.7.  Port Number
        4.3.8.  URI
        4.3.9.  Fully Qualified Domain Name
        4.3.10.  [Cellular] Telephony
    4.4.  Measurements
        4.4.1.  WiFi
        4.4.2.  Cellular
        4.4.3.  w16e
        4.4.4.  GNSS
    4.5.  Other parameters
5.  Response parameters
    5.1.  General parameters
        5.1.1.  Timestamp
        5.1.2.  Target
    5.2.  Location [PIDF-LO]
        5.2.1.  Geodetic location
        5.2.2.  Civic location
        5.2.3.  Location by reference
    5.3.  Other parameters
6.  Protocol mapping summary
    6.1.  Google Gears Geolocation API Mapping
7.  Applications
8.  Privacy Considerations
9.  Security Considerations
10.  References
    10.1.  Normative References
    10.2.  Informative References
§  Authors' Addresses

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.

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [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.

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? 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]

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 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

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

• [(model, HELD, DHCP, MLP, Gears, LOCSIP)]

6.1.  Google Gears Geolocation API Mapping

Table 1: Mapping for Google Gears Geolocation API to Request Object

Table 2: Mapping for Google Gears Geolocation API to Response Object

7.  Applications

This section provides use cases for the unified data model (UDM):

• Implementing Single Protocol [Protocol A] Client
  • Pre-designed, pre-implemented data model - developers will not have to design and implement their own
  • The client is already designed to support additional protocols if they are later added
• Implementing Multiple Protocol [Protocols A, B, C] Client
  • Single Data Model, Multiple Protocols
• 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
• 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)
• 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

10.2. Informative References

Authors' Addresses