Global Navigation Satellite System (GNSS) Reference Information Protocol (GRIP)
draft-thomson-geopriv-grip-00

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 January 28, 2010.

Copyright Notice

Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This document describes a means of acquiring Global Navigation Satellite System (GNSS) assistance data using HTTP. Assistance data aids GNSS receivers in acquiring and measuring satellite signals, as well as being useful in calculating positions. The GNSS Reference Information Protocol (GRIP) provides a framework for discovering resources capable of providing any kind of location-based assistance data.

Table of Contents

1.  Introduction
    1.1.  Advantages of Assistance Data
2.  Conventions used in this document
3.  GRIP Operation Overview
4.  GRIP Metadata
    4.1.  Local and Global Assistance Data
    4.2.  GRIP Metadata Format
        4.2.1.  'coverage' element
        4.2.2.  'ad' element
        4.2.3.  'batches' element
5.  GRIP Assistance Data Requests
    5.1.  Location Parameters
6.  Assistance Data Batch Requests
7.  GRIP Errors
8.  Assistance Data
    8.1.  Batched Assistance Data
    8.2.  Caching Assistance Data
    8.3.  Time Assistance
9.  XML Schema
10.  Security Considerations
11.  IANA Considerations
    11.1.  Registration of MIME type 'application/grip+xml'
    11.2.  Registration of MIME type 'application/grip-ad+xml'
    11.3.  Error code Registry
    11.4.  URN Sub-Namespace Registration for 'urn:ietf:params:xml:ns:grip'
    11.5.  XML Schema Registration
12.  Acknowledgements
13.  References
    13.1.  Normative References
    13.2.  Informative References

1.  Introduction

A Global Navigation Satellite System (GNSS) provides a signal that enables accurate determination of the position of a receiver in space and time. A constellation of satellites transmit radio signals that the receiver is able to measure. From these measurements, the location of the receiver and the time of measurement can be determined using knowledge about the position and velocity of the satellites and the signal they transmit.

Acquisition of satellite signals requires searching for the extremely weak signal transmitted by each satellite. Satellites transmit a distinct repeating code that is used by the receiver for signal acquisition. Acquiring the signal is done by synchronizing with the received signal in both frequency and time. In order to synchronize, the receiver searches in two dimensions:

time/code phase:

The distance between the satellite and receiver means that the receiver sees a signal that is offset in time. The amount of time shift is known as code phase since it is measured within the window of the repeated code sequence. Code phase forms the primary measurement used in calculating a position.

frequency:

The relative speed of satellite and receiver causes Doppler shift of the satellite signal.

To make use of satellite measurements, information about the satellite and the signal that it transmits is required. To achieve this, satellite signals are typically modulated at a low rate with a navigation message. The navigation message provides information that is used in calculation of location and time, including information on satellite orbit, satellite health, time model, and atmospheric effects on the signal. The navigation message is transmitted by satellites at very low rates to avoid hampering the measurement process.

Once satellite signals have been acquired and measured, the measurement information is combined with the information from the navigation message and a position (and time) can be calculated. Successful calculation of a position typically requires measurement data for a minimum of 5 satellites unless otherwise supplemented.

If a receiver has to perform all these steps independently, satellite acquisition and receipt of the navigation message can take significant amounts of time. Improvements in receiver design have increased receiver sensitivity and the speed that signals are acquired. However, the low data rates used for the navigation message adds a fixed delay to this process. Use of assistance data provides a dramatic improvement in the time taken to acquire signals and produce a result. Dedicated data networks are able to provide the information contained in the navigation message much more efficiently.

An assistance data server uses a reference network - a distributed set of GNSS receivers - to acquire information about satellite signals. The server is then able to provide this information to receivers and aid in GNSS signal measurement and position calculation.

This document provides a means of acquiring GNSS assistance data using GRIP, a protocol based on HTTP (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [RFC2616]. Basic mechanisms are specified for extending the use of GRIP to any form of assistance data.

[I‑D.thomson‑geopriv‑grip‑gps] (Thomson, M., “Global Position System (GPS) Assistance Data for GRIP,” Jul 2009.) defines assistance data for the Global Positioning System (GPS).

1.1.  Advantages of Assistance Data

GNSS assistance data is information provided to a receiver that is provided to improve the quality and timeliness of GNSS measurements or positioning. The most basic set of assistance data includes the same information provided in the navigation message. Additional forms of assistance data include information customized to a particular receiver to assist it in acquiring signals, or information about satellite ephemerides (orbits) that is useful over a longer period of time.

Acquiring assistance data from the network completely removes the need to receive the navigation message. Navigation message content can be transmitted to the receiver using the vastly more efficient communication paths provided by a data network. This removes a significant step from the process of determining a position.

Knowing what satellites to search for can reduce signal acquisition time. One of the most basic pieces of information provided by assistance data is knowledge of which satellites are above the horizon and can therefore be measured. Concentrating on "visible" satellites ensures that less time is wasted on attempting to measure signals that could not possibly be found.

Assistance data can provide information about where in the frequency/code phase space to search for a particular satellite signal. This reduces the time required to acquire a satellite signal. Since an approximate frequency and code phase can be known, it becomes feasible to spend more time searching for weaker signals, improving receiver sensitivity. Improved sensitivity ensures that GNSS can be used in areas where signal penetration is poor, like buildings and other areas with poor sky visibility, and increases the likelihood of getting sufficient satellite measurements to calculate a position.

Assistance data also enables compensation for the effects of the navigation message. Knowing the content of the navigation message ahead of time means that the receiver is able to anticipate the effect of its modulation on the signal and compensate accordingly. This increases the sensitivity of the receiver and allows for faster signal acquisition.

Specialized assistance data types can also provide further assistance. Assistance data can provide more sophisticated models of satellite orbits, or localized data relating to signal propagation or interference.

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

3.  GRIP Operation Overview

A client is configured with the location of a GRIP server, or follows a hyperlink that leads to a GRIP server. This URI indicates the location of a GRIP metadata document (GRIP Metadata), which describes all that the server is capable of.

From the metadata document, the client is able to determine what information is made available by the GRIP server and where that information is available from. The client retrieves (GRIP Assistance Data Requests) one or more resources to acquire assistance data.

4.  GRIP Metadata

A server providing a GRIP service might provide a certain subset of assistance data to clients. Conveying the set of assistance data types that it is capable of providing to clients is the basis of GRIP. To that end, a metadata document format is defined.

A client retrieves a GRIP metadata document using an HTTP GET request. The metadata document contains a listing of each of the supported assistance data types, plus a URI indicating where each type can be requested.

The following GRIP metadata document shows support for three global assistance data types, support for two local assistance data types over a small area. A single batched assistance data resource is provided, with a means to create more.

  <grip xmlns="urn:ietf:params:xml:ns:grip"
        xmlns:gps="urn:ietf:params:xml:ns:grip:gps">
    <global>
      <ad type="gps:utcModel">/grip/utc</ad>
      <ad type="gps:ephemeris">/grip/ephemeris</ad>
      <ad type="gps:ionosphere">/grip/ionosphere</ad>
    </global>

    <local>
      <coverage>
        <gml:Polygon xmlns:gml="http://www.opengis.net/gml"
                     srsName="urn:ogc:def:crs:EPSG::4326">
          <gml:exterior>
            <gml:LinearRing>
              <gml:posList>
                -33.856625 151.215906 -33.856299 151.215343
                -33.856326 151.214731 -33.857533 151.214495
                -33.857720 151.214613 -33.857369 151.215375
                -33.856625 151.215906
              </gml:posList>
            </gml:LinearRing>
          </gml:exterior>
        </gml:Polygon>
      </coverage>
      <ad type="gps:ephemeris">/grip/ephemeris</ad>
      <ad type="gps:acqAssist">/grip/acqAssist</ad>
    </local>

    <batches create="/grip?create">
      <batch uri="/grip/batch/device-based">
        <global>
          <ad type="gps:utcModel"/>
          <ad type="gps:ionosphere"/>
        </global>
        <local>
          <ad type="gps:ephemeris"/>
        </local>
      </batch>
    </batches>
  </grip>

4.1.  Local and Global Assistance Data

The GRIP metadata format describes the types of assistance data that the server is willing to provide, separated into two sections: local and global.

Local assistance data applies to a particular position on the Earth. When requesting this information, the client indicates the location of interest. The server constructs assistance data that is specific to that location.

Global assistance data can be acquired that is useful to a receiver regardless of the position of the receiver. For instance, in GPS the relationship between the GPS time system and Universal Coordinated Time (UTC) is globally applicable.

Some assistance data types are always localized, other items are always global. In some cases, the localized data provided for some types of assistance data is simply a subset of the global data that is useful at the specified location.

For instance, a satellite navigation model, which includes information on the position of the satellite, can be provided as both global and local data. A global request might provide navigation parameters for all satellites in the constellation; a local request might only include those satellites that can be viewed from the indicated location.

4.2.  GRIP Metadata Format

GRIP metadata is specified as an XML document of type application/grip+xml. This document is split into three sections:

global:

This element describes what forms of global assistance data are made available and where each may be retrieved.

local:

This element describes what forms of local assistance data are made available and where each may be retrieved.

batches:

This element lists the locations where multiple forms of assistance data can be acquired from single resources.

4.2.1.  'coverage' element

In order to provide GNSS assistance data, receivers need to observe and record satellite signals across a large area. These receivers either need to receive a signal from a satellite (such as the GPS navigation message) or take measurements of the satellite signal.

Each receiver can only measure or observe a satellite for part of its orbit. A global distribution of receivers is necessary to be able to provide assistance data for the entire planet. Where receivers are distributed over a smaller area, GRIP provides a means to indicate where receivers are able to measure satellite signals.

Both global and local sections optionally include a coverage element. The coverage specifies the region where the provided information provided is applicable. Outside this area, the assistance data might not be comprehensive or completely accurate.

The coverage region is specified using a GML Polygon or Envelope, or a Circle as defined in [RFC5491] (Winterbottom, J., Thomson, M., and H. Tschofenig, “GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations,” March 2009.). If no coverage element is specified, this indicates that assistance data can be provided for any location on the Earth.

A GRIP service MAY provide information outside its indicated coverage area. Clients need to be aware that this information could be inaccurate, missing certain elements, or it could be extrapolated from old information.

Coverage might vary depending on the type of assistance data. Some forms of assistance data, such as differential corrections, can only be collected for a small geographic area. Therefore, multiple global or local elements can be specified with different coverage areas.

If the same assistance data type appears multiple times, or if multiple coverage elements are included, the coverage for that assistance data type is the union of the associated coverage regions.

4.2.2.  'ad' element

The ad element indicates availability of a specific type of assistance data.

The text content of the ad element indicates a URI where assistance data can be acquired. This URI is either an absolute URI or specified relative to the base URI of the GRIP index document.

The type of assistance data provided is specifed in the type attribute of the ad element. This identifies an XML element by its qualified name (Hollander, D., Layman, A., and T. Bray, “Namespaces in XML 1.0 (Second Edition),” August 2006.) [W3C.REC‑xml‑names‑20060816], using the namespace context from the enclosing document.

When included as a child of the global element, the ad element describes the location of resources that contain the indicated items of global assistance data. Similarly, when included in the local element, it indicates where local assistance can be acquired.

4.2.3.  'batches' element

The batches element contains one or more batches of assistance data - URI references to resources that contain multiple forms of assistance data. These might be provided as a convenience to clients that might otherwise require multiple requests for the same information.

Each batch element contained within a batches element represents a single resource. The URI of the resource is included in the uri attribute. This single resource contains multiple forms of assistance data.

The global assistance data types included in the resource are defined in a list of ad elements under a global element. Similarly, the local assistance data types are defined in a list of ad elements under a local element. The ad elements in this context are empty; each does not contain URIs to the individual unit of assistance data.

The batches element does not include a coverage description. Each assistance data type is expected to be included in the top-level global or local elements, which include coverage descriptions. Coverage for the batch can be assumed to be the intersection of the coverage for each of the associated assistance data types.

The optional create attribute of the batches element enables the creation of new collection of information if present.

Creation and use of batched requests is described in more detail in Section 6 (Assistance Data Batch Requests).

5.  GRIP Assistance Data Requests

A GRIP assistance data request is a HTTP GET to the URI indicated in the GRIP index.

For global assistance data resources, an unmodified request is sufficient to retrieve the indicated information.

For local assistance data resources, URI parameters are used to indicate the location that the information is generated for. Location is indicated by the addition of URI parameters.

The same resource MAY provide both global and local assistance data of the same type, using the presence or absence of URI parameters to determine which of these is requested.

The MIME type of all assistance data documents is application/grip-ad+xml. The document contains an XML document with a document element of the type indicated in the GRIP index.

In the absence of any required URI parameters or any form of GRIP-specific error, the server MUST indicate that the URI is invalid with an HTTP 404 error. The HTTP 404 response contains a GRIP error in the body of the message, using a MIME type of application/grip+xml.

5.1.  Location Parameters

The client MUST specify the location that the local assistance data is applicable to. Location information can be provided directly by specifying parameters directly in the URI or indirectly.

If this information is not provided, the server responds with an error (GRIP Errors) contained in an HTTP 404 response.

The following URI parameters are used to specify a location directly:

latitude:

The approximate latitude of the location where assistance data is required.

longitude:

The approximate longitude of the location where assistance data is required.

altitude:

The approximate latitude of the location where assistance data is required. Inclusion of altitude is optional; if absent, the server MAY assume a value of 0.

uncertainty:

The estimated maximum distance that assistance data is expected to be useful for, specified in meters from the indicated point. This is only necessary for some forms of local assistance data; a default value of one kilometer MAY be assumed if this parameter is omitted.

locationuri:

A URI that indicates the location associated with the request.

Other URI parameters MUST be ignored by the server if they are not supported.

  GET /grip/acqAssist?latitude=-35.406&longitude=150.882 HTTP/1.1
  Host: grip.example.com
  Accept-Content: application/grip-ad+xml,application/grip+xml;q=0.5

Latitude, longitude and altitude specified in URI parameters use the World Geodetic System 1984 (WGS 84) coordinate reference system.

Location information MAY be provided by reference. The locationuri parameter is used to include a URI. Percent-encoding MUST be used to ensure that reserved characters in the URI are correctly escaped.

The location URI either takes the form of an indirect reference, or location URI (Marshall, R., “Requirements for a Location-by-Reference Mechanism,” November 2009.) [I‑D.ietf‑geopriv‑lbyr‑requirements]; or information can be provided directly in URI form using a geo: URI (Mayrhofer, A. and C. Spanring, “A Uniform Resource Identifier for Geographic Locations ('geo' URI),” April 2010.) [I‑D.ietf‑geopriv‑geo‑uri]. A location URI MUST resolve to a presence data information format - location object (PIDF-LO) (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.) [RFC4119] document.

A server MAY choose to not support the locationuri parameter, or to limit the URI schemes that it accepts. If this is not the case, an error with a code of unsupportedLocation MUST be provided. A client MUST be prepared to receive this code and either dereference the URI and provide the values directly or abandon the request.

6.  Assistance Data Batch Requests

Retrieving batches assistance data resources is no different to requesting assistance data of a single type. An HTTP GET to the indicated URI is sufficient, possibly including location parameters (Location Parameters). If local assistance data is part of the batched assistance data, then location information MUST be provided.

A batched assistance data resource contains all indicated forms of assistance data collected together in an adbatch element, see Section 8.1 (Batched Assistance Data).

A server MAY support creation of specific batches. If this is the case, a URI is provided in the create attribute of the batches element of the GRIP metadata.

Sending an HTTP POST message containing a batch element as the document element creates a new batch. The MIME type of this document is application/grip+xml. The uri attribute of the batch element sent by the client is ignored by the server; the client can set this to any value.

  POST /grip?create HTTP/1.1
  Host: grip.example.com
  Content-Type: application/grip+xml;charset=utf-8
  Content=Length: 226

  <batch xmlns="urn:ietf:params:xml:ns:grip"
         xmlns:gps="urn:ietf:params:xml:ns:grip:gps" uri="#">
    <global>
      <ad type="gps:utcModel"/>
    </global>
    <local>
      <ad type="gps:ephemeris"/>
    </local>
  </batch>

If successful, the response is an HTTP 201 (Created) response containing a reduced GRIP metadata document, containing a single batch element. The batch element contains the URI that has been allocated to this resource. The Location header of the HTTP response also indicates the URI of the newly created resource.

  HTTP/1.1 201 Created
  Location: https://grip.example.com/grip/batch/303
  Content-Type: application/grip+xml;charset=utf-8
  Content=Length: 337

  <grip xmlns="urn:ietf:params:xml:ns:grip"
        xmlns:gps="urn:ietf:params:xml:ns:grip:gps">
    <batches create="/grip?create">
      <batch uri="/grip/batch/101">
        <global>
          <ad type="gps:utcModel"/>
        </global>
        <local>
          <ad type="gps:ephemeris"/>
        </local>
      </batch>
    </batches>
  </grip>

A server MAY choose to not advertise newly created batched assistance data resources in the GRIP metadata that it provides to other clients. Batched assistance data resources MAY also have a limited lifetime; if so, the Expires header MUST be used to indicate when the metadata is no longer valid.

If a resource already exists with the requested set of assistance data types, the server SHOULD refer to this in the 201 response in preference to creating additional resources. This prevents the proliferation of batched assistance data resources.

Errors in the request body are indicated with an HTTP 400 (Bad Request) response containing a GRIP error document (GRIP Errors) with an appropriate error code.

7.  GRIP Errors

Errors in the URIs provided are firstly indicated using HTTP errors. However, the body of the HTTP error MUST contain a GRIP document that describes the error.

An error document consists of an error element, with a mandatory code attribute. Any number of message elements MAY be added to convey human-readable feedback on the error; each message element contains an xml:lang attribute that identifies the language of the text.

  <error xmlns="urn:ietf:params:xml:ns:grip" code="noLocation">
    <message xml:lang="en">Missing 'latitude' parameter.</message>
  </error>

The following values for the code attribute and the values of corresponding HTTP errors are defined:

noLocation:

(HTTP 404) A request for local assistance data did not contain location information.

badLocation:

(HTTP 404) A request for local assistance data contained location information that was badly formatted or was not understood by the server.

unsupportedLocation:

(HTTP 404) A request for local assistance data contained location information that might be valid, but the server is not able to use the provided form.

noCoverage:

(HTTP 404) A request for assistance data indicated a location that the server has no coverage for.

noData:

(HTTP 503) The identified assistance data type is currently unavailable. Used when the server is temporarily unable to provide assistance data.

unsupportedType:

(HTTP 400) The identified assistance data type is not supported by the server. Used in response to a batch creation request.

badXml:

(HTTP 400) The XML provided in the request was badly formed, or invalid. Used in response to a batch creation request.

8.  Assistance Data

Assistance data that can be expressed in XML form is supported by this protocol. The XML element is the basic unit of assistance data, since this is what is identified in the ad element.

All assistance data is provided with the same MIME type, application/grip-ad+xml. The document element determines the type.

New definitions of assistance data only require the definition of an XML format and the use of a unique namespace URI (Hollander, D., Layman, A., and T. Bray, “Namespaces in XML 1.0 (Second Edition),” August 2006.) [W3C.REC‑xml‑names‑20060816]. Formal schema definitions, such as XML Schema (Beech, D., Thompson, H., Mendelsohn, N., and M. Maloney, “XML Schema Part 1: Structures,” May 2001.) [W3C.REC‑xmlschema‑1‑20010502] or RelaxNG (International Organization for Standardization, “Document Schema Definition Language (DSDL) -- Part 2: Regular-grammar-based validation -- RELAX NG,” 2008.) [ISO.19757‑2.2008] SHOULD be used, but are not necessary as long as structure and semantics are clearly defined.

Assistance data for the Global Position System (GPS) is defined in [I‑D.thomson‑geopriv‑grip‑gps] (Thomson, M., “Global Position System (GPS) Assistance Data for GRIP,” Jul 2009.). These assistance data are used in examples throughout this document.

8.1.  Batched Assistance Data

Batched assistance data uses the application/grip-ad+xml MIME type, but all requested assistance data is included as child elements of a adbatch document element.

  <adbatch xmlns="urn:ietf:params:xml:ns:grip">
    <utc xmlns="urn:ietf:params:xml:ns:grip:gps">
      <reference week="477">436559</reference>
      <offset>0.76014e-4 -0.21722e-12</offset>
      <leapsec>13</leapsec>
    </utc>
    <navigation xmlns="urn:ietf:params:xml:ns:grip:gps">
    </navigation>
  </adbatch>

8.2.  Caching Assistance Data

Caching of assistance data is particularly useful in alleviating server load. Standard HTTP mechanisms are suitable for controlling caching of global assistance data, but local assistance data introduces complications.

Assistance data for two locations within close proximity might not vary significantly. However, HTTP caches place significance in any change in a URI, including trivially significant decimal places in numbers and even the ordering of URI parameters. Therefore, small changes in location can result in a completely different URI.

In order to facilitate caching, clients SHOULD round latitude and longitude values to 5 decimal places (equivalent to approximately 0.5 meters distance error), removing any trailing zeroes. This ensures locations are consistently represented.

In serving a large number of requests, a server might choose to cache assistance data that is applicable over a geographic area. A method of caching optimization relies on fixing the locations that assistance data is provided for to a grid. Assistance data is only provided for the center point of the grid. All other points in the grid receive the same assistance data.

The grid-based method allows caching by the server itself, but not a generic HTTP cache. A server MAY use HTTP redirection to more efficiently use generic HTTP caches. An HTTP 302 (Found) response is appropriate in redirecting a response that includes a fixed location value (URI parameters or geo: URI); an HTTP 303 (See Other) is more appropriate when location URIs are used to provide location information. This increases the latency of requests.

Local assistance data that is based on a location URI can change if the referenced document also changes. A server MUST either indicate that local assistance data is not cacheable through the use of Cache-Control headers or indicate validity times with an Expires. If the server caches the information retrieved from the location URI, the server might reflect this in the value of an Expires header.

Assistance data itself can be used to derive the location of a client. Servers MUST NOT allow assistance data based on a location URI to enter a shared cache. The Cache-Control headers for such requests MUST be set to private or no-cache. Where redirection is used, the redirection response cannot be placed in a shared cache, but the resulting document is cacheable.

8.3.  Time Assistance

It is common for GNSS systems to use a different time model than UTC. Commonly assistance data is used to relate the GNSS time to UTC. This allows a client that is accurately synchronized to the GNSS time (a necessary outcome or prerequisite of location determination) to very accurately synchronize with UTC time.

Assistance data that relates time systems is an important part of this protocol. Indeed, assistance data that relates GNSS time with other time systems is also useful.

It is not the intent for this protocol to itself provide time synchronization functions. Other protocols, such as Network Time Protocol (NTP) (Mills, D., “Network Time Protocol (Version 3) Specification, Implementation,” March 1992.) [RFC1305], or Simple NTP (Mills, D., “Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI,” January 2006.) [RFC4330], perform this task efficiently and accurately.

9.  XML Schema

<xs:schema
    targetNamespace="urn:ietf:params:xml:ns:grip"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:grip="urn:ietf:params:xml:ns:grip"
    xmlns:gml="http://www.opengis.net/gml"
    elementFormDefault="qualified"
    attributeFormDefault="unqualified">

  <xs:annotation>
    <xs:appinfo
        source="urn:ietf:params:xml:schema:grip">
      GNSS Reference Information Protocol (GRIP) Schema
    </xs:appinfo>
    <xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
      <!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
           published RFC and remove this note.]] -->
      This document defines core elements of GRIP documents.
    </xs:documentation>
  </xs:annotation>

  <xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
  <xs:import namespace="http://www.opengis.net/gml"/>

  <xs:element name="grip" type="grip:gripType"/>
  <xs:complexType name="gripType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:sequence>
          <xs:element name="global" type="grip:adSetType"
                      minOccurs="0" maxOccurs="unbounded"/>
          <xs:element name="local" type="grip:adSetType"
                      minOccurs="0" maxOccurs="unbounded"/>
          <xs:element name="batches" type="grip:batchesType"
                      minOccurs="0"/>
          <xs:any namespace="##other" processContents="lax"
                  minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="adSetType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:sequence>
          <xs:element name="coverage" type="grip:coverageType"
                      minOccurs="0" maxOccurs="unbounded"/>
          <xs:element name="ad" type="grip:adType"
                      minOccurs="0" maxOccurs="unbounded"/>
          <xs:any namespace="##other" processContents="lax"
                  minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="coverageType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:choice>
          <xs:element ref="gml:_Geometry"/>
          <xs:element ref="gml:Envelope"/>
        </xs:choice>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="adType">
    <xs:simpleContent>
      <xs:extension base="xs:anyURI">
        <xs:attribute name="type" type="xs:QName" use="required"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

  <xs:complexType name="batchesType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:sequence>
          <xs:element ref="grip:batch"
                      minOccurs="0" maxOccurs="unbounded"/>
          <xs:any namespace="##other" processContents="lax"
                  minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute name="create" type="xs:anyURI" use="optional"/>
        <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:element name="batch" type="grip:batchType"/>
  <xs:complexType name="batchType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:sequence>
          <xs:element name="global" type="grip:batchAdSetType"
                      minOccurs="0"/>
          <xs:element name="local" type="grip:batchAdSetType"
                      minOccurs="0"/>
          <xs:any namespace="##other" processContents="lax"
                  minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute name="uri" type="xs:anyURI" use="required"/>
        <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="batchAdSetType">
    <xs:complexContent>
      <xs:restriction base="grip:adSetType">
        <xs:sequence>
          <xs:element name="ad" type="grip:adType"
                      minOccurs="0" maxOccurs="unbounded"/>
          <xs:any namespace="##other" processContents="lax"
                  minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <!-- Batched responses -->
  <xs:element name="adbatch" type="grip:adbatchType"/>
  <xs:complexType name="adbatchType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:sequence>
          <xs:any namespace="##any" processContents="lax"
                  minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <!-- Errors -->
  <xs:element name="error" type="grip:errorType"/>
  <xs:complexType name="errorType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:sequence>
          <xs:element name="message" type="grip:errorMsgType"
                      minOccurs="0" maxOccurs="unbounded"/>
          <xs:any namespace="##other" processContents="lax"
                  minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute name="code" type="xs:token"
                      use="required"/>
        <xs:anyAttribute namespace="##any" processContents="lax"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="errorMsgType">
    <xs:simpleContent>
      <xs:extension base="xs:token">
        <xs:attribute ref="xml:lang"/>
        <xs:anyAttribute namespace="##any" processContents="lax"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

</xs:schema>

10.  Security Considerations

A server MAY individually authorize clients and challenge clients to provide authentication credentials.

Receivers need to be aware that falsified assistance data can be used to cause a location calculation to be arbitrarily incorrect. In particular, falsifying the location of a satellite by altering ephemeris information could be used to cause the receiver to calculate any location. Small changes in location caused by this methods are difficult to detect, but larger changes can be identified through inconsistency in Doppler shift and comparison of basic satellite location with previously acquired (and trusted) estimates, such as the GPS almanac.

A server that provides the ability to create batch assistance data resources provides clients with a means to alter its state. Server implementations SHOULD constrain this feature to prevent exhaustion of resources by malicious clients. Limiting the total number of resources by directing clients to already existing resources is effective due to the limited number of combinations of assistance data types. Servers might also require client authorization, or artificially limit the total number of batch resources.

Location information provided by a client in making a request for local assistance data is potentially privacy sensitive. A client SHOULD use HTTP over TLS (Rescorla, E., “HTTP Over TLS,” May 2000.) [RFC2818] to ensure that only the identified server is able to use this information. Location URIs SHOULD use similarly secured channels to prevent attackers from intercepting or falsifying this information.

Because location information is potentially sensitive, servers MUST NOT use location information for anything other than serving the request that contains it.

GRIP metadata is designed to carry descriptions of how assistance data can be retrieved. This document could contain references to resources under the control of other parties that might be unaware of this linkage. For instance, these links might refer to files on the client system, or they might invoke specific protocol actions. If a client dereferences links without validation, this might be used by a server to leak information or even trigger unintended actions from the client. Clients MUST validate any URI it receives. Restricting use of URIs to https: and http: URIs limits the scope of any attack. Only accepting responses of the MIME type application/grip-ad+xml further reduces the ability of an attacker to trigger client behavior.

11.  IANA Considerations

This section registers two MIME types: application/grip+xml for GRIP metadata and control documents in Section 11.1 (Registration of MIME type 'application/grip+xml'), application/grip-ad+xml for GRIP assistance data documents in Section 11.2 (Registration of MIME type 'application/grip-ad+xml').

A registry for GRIP errors is defined in Section 11.3 (Error code Registry).

The XML namespace used in GRIP metadata and control documents is registered in Section 11.4 (URN Sub-Namespace Registration for 'urn:ietf:params:xml:ns:grip'), the corresponding schema definition is registered in Section 11.5 (XML Schema Registration).

11.1.  Registration of MIME type 'application/grip+xml'

This section registers the application/grip+xml MIME type, used for GRIP metadata and the core protocol.

To:

ietf-types@iana.org

Subject:

Registration of MIME media type application/grip+xml

MIME media type name:

application

MIME subtype name:

grip+xml

Required parameters:

(none)

Optional parameters:

charset Same as the charset parameter of application/xml as specified in Section 3.2 of RFC 3023 (Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” January 2001.) [RFC3023].

Encoding considerations:

Same as the encoding considerations of application/xml as specified in Section 3.2 of RFC 3023 (Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” January 2001.) [RFC3023].

Security considerations:

Security considerations are described in Section 10 (Security Considerations). Many of the security considerations in Section 10 of RFC 3023 (Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” January 2001.) [RFC3023] also apply.

Interoperability considerations:

This content type provides a basis for a protocol.

Published specification:

RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for this specification.]

Applications which use this media type:

Global Navigation Satellite System (GNSS) receivers and servers that provide assistance data for GNSS receivers.

Additional Information:

Magic Number(s): (none) File extension(s): .grip
Macintosh File Type Code(s): TEXT

Person & email address to contact for further information:

Martin Thomson <martin.thomson@andrew.com>

Intended usage:

LIMITED USE

Author/Change controller:

The IETF

Other information:

This media type is a specialization of application/xml (Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” January 2001.) [RFC3023], and many of the considerations described there also apply to application/grip+xml.

11.2.  Registration of MIME type 'application/grip-ad+xml'

This section registers the application/grip-ad+xml MIME type, used for the expression of assistance data.

To:

ietf-types@iana.org

Subject:

Registration of MIME media type application/grip-ad+xml

MIME media type name:

application

MIME subtype name:

grip-ad+xml

Required parameters:

(none)

Optional parameters:

charset Same as the charset parameter of application/xml as specified in Section 3.2 of RFC 3023 (Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” January 2001.) [RFC3023].

Encoding considerations:

Same as the encoding considerations of application/xml as specified in Section 3.2 of RFC 3023 (Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” January 2001.) [RFC3023].

Security considerations:

Many of the security considerations in Section 10 of RFC 3023 (Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” January 2001.) [RFC3023] apply.

Interoperability considerations:

This content type is used to provide an interoperable format for assistance data. Interoperability depends on the definition of the assistance data, which is not proscribed to allow for new assistance data definitions.

Published specification:

RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for this specification.]

Applications which use this media type:

Global Navigation Satellite System (GNSS) receivers and servers that provide assistance data for GNSS receivers.

Additional Information:

Magic Number(s): (none) File extension(s): .gripad
Macintosh File Type Code(s): TEXT

Person & email address to contact for further information:

Martin Thomson <martin.thomson@andrew.com>

Intended usage:

LIMITED USE

Author/Change controller:

The IETF

Other information:

This media type is a specialization of application/xml (Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” January 2001.) [RFC3023], and many of the considerations described there also apply to application/grip-ad+xml.

11.3.  Error code Registry

This document requests that the IANA create a new registry for GRIP, including an initial registry for error codes. Error codes are included in GRIP error documents as described in Section 7 (GRIP Errors) and MAY be any sequence of characters.

The following summarizes the requested registry:

Related Registry:

Geopriv GRIP Registries, Error codes for GRIP

Defining RFC:

RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for this specification.]

Registration/Assignment Procedures:

Following the policies outlined in [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.), the IANA policy for assigning new values for the Error codes for GRIP registry shall be Standards Action: Values are assigned only for Standards Track RFCs approved by the IESG.

Registrant Contact:

IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

This section pre-registers the error codes defined in Section 7 (GRIP Errors).

11.4.  URN Sub-Namespace Registration for 'urn:ietf:params:xml:ns:grip'

This section registers a new XML namespace, urn:ietf:params:xml:ns:grip, per the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

URI: urn:ietf:params:xml:ns:grip

Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

XML:

      BEGIN
        <?xml version="1.0"?>
        <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
        <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
          <head>
            <title>GRIP Metadata</title>
          </head>
          <body>
            <h1>Namespace for GRIP Metadata Definitions</h1>
            <h2>urn:ietf:params:xml:ns:grip</h2>
    [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
    with the RFC number for this specification.]
            <p>See RFCXXXX</p>
          </body>
        </html>
      END

11.5.  XML Schema Registration

This section registers an XML schema as per the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

URI:

urn:ietf:params:xml:schema:grip

Registrant Contact:

IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

Schema:

The XML for this schema can be found as the entirety of Section 9 (XML Schema) of this document.

12.  Acknowledgements

This document is part of the definition of GRIP. The original GRIP protocol was developed by the University of New South Wales through the OSGRS project http://osgrs.sourceforge.net/. The GPS expertise of Neil Harper was invaluable in assembling this document.

13.  References

13.1. Normative References

13.2. Informative References

Author's Address