One document matched: draft-thomson-geopriv-grip-01.txt
Differences from draft-thomson-geopriv-grip-00.txt
GEOPRIV M. Thomson
Internet-Draft Andrew Corporation
Intended status: Experimental March 5, 2010
Expires: September 6, 2010
Global Navigation Satellite System (GNSS) Reference Information Protocol
(GRIP)
draft-thomson-geopriv-grip-01
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.
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 6, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Thomson Expires September 6, 2010 [Page 1]
Internet-Draft GRIP March 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Advantages of Assistance Data . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 5
3. GRIP Operation Overview . . . . . . . . . . . . . . . . . . . 5
4. GRIP Metadata . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Local and Global Assistance Data . . . . . . . . . . . . . 7
4.2. GRIP Metadata Format . . . . . . . . . . . . . . . . . . . 7
4.2.1. 'coverage' element . . . . . . . . . . . . . . . . . . 7
4.2.2. 'ad' element . . . . . . . . . . . . . . . . . . . . . 8
4.2.3. 'batches' element . . . . . . . . . . . . . . . . . . 9
5. GRIP Assistance Data Requests . . . . . . . . . . . . . . . . 9
5.1. Location Parameters . . . . . . . . . . . . . . . . . . . 10
6. Assistance Data Batch Requests . . . . . . . . . . . . . . . . 11
7. GRIP Errors . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Assistance Data . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Batched Assistance Data . . . . . . . . . . . . . . . . . 14
8.2. Caching Assistance Data . . . . . . . . . . . . . . . . . 14
8.3. Time Assistance . . . . . . . . . . . . . . . . . . . . . 15
9. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11.1. Registration of MIME type 'application/grip+xml' . . . . . 20
11.2. Registration of MIME type 'application/grip-ad+xml' . . . 22
11.3. Error code Registry . . . . . . . . . . . . . . . . . . . 23
11.4. URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:grip' . . . . . . . . . . . . . . 23
11.5. XML Schema Registration . . . . . . . . . . . . . . . . . 24
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
13.1. Normative References . . . . . . . . . . . . . . . . . . . 24
13.2. Informative References . . . . . . . . . . . . . . . . . . 25
Thomson Expires September 6, 2010 [Page 2]
Internet-Draft GRIP March 2010
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, or
4 satellites if the receiver has accurate time.
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
Thomson Expires September 6, 2010 [Page 3]
Internet-Draft GRIP March 2010
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 [RFC2616]. Basic mechanisms are
specified for extending the use of GRIP to any form of assistance
data.
[I-D.thomson-geopriv-grip-gps] 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
Thomson Expires September 6, 2010 [Page 4]
Internet-Draft GRIP March 2010
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].
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 (Section 4), 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 (Section 5) 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.
Thomson Expires September 6, 2010 [Page 5]
Internet-Draft GRIP March 2010
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>
Thomson Expires September 6, 2010 [Page 6]
Internet-Draft GRIP March 2010
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.
Thomson Expires September 6, 2010 [Page 7]
Internet-Draft GRIP March 2010
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]. 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 [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"
Thomson Expires September 6, 2010 [Page 8]
Internet-Draft GRIP March 2010
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.
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
Thomson Expires September 6, 2010 [Page 9]
Internet-Draft GRIP March 2010
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 (Section 7) 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
Thomson Expires September 6, 2010 [Page 10]
Internet-Draft GRIP March 2010
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 [I-D.ietf-geopriv-lbyr-requirements]. A location URI
MUST resolve to a presence data information format - location object
(PIDF-LO) [RFC4119] document. Alternatively, information can be
provided directly in URI form using a geo: URI
[I-D.ietf-geopriv-geo-uri].
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 either 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
(Section 5.1). 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.
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.
Thomson Expires September 6, 2010 [Page 11]
Internet-Draft GRIP March 2010
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/303">
<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
Thomson Expires September 6, 2010 [Page 12]
Internet-Draft GRIP March 2010
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 (Section 7) 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.
Thomson Expires September 6, 2010 [Page 13]
Internet-Draft GRIP March 2010
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
[W3C.REC-xml-names-20060816]. Formal schema definitions, such as XML
Schema [W3C.REC-xmlschema-1-20010502] or RelaxNG [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]. 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 improving
responsiveness and 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
Thomson Expires September 6, 2010 [Page 14]
Internet-Draft GRIP March 2010
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) and remove 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 [[ Content-
Location might help with this; but it doesn't help with caching,
sadly]].
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.
Thomson Expires September 6, 2010 [Page 15]
Internet-Draft GRIP March 2010
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) [RFC1305], or Simple NTP [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>
Thomson Expires September 6, 2010 [Page 16]
Internet-Draft GRIP March 2010
<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>
Thomson Expires September 6, 2010 [Page 17]
Internet-Draft GRIP March 2010
<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>
Thomson Expires September 6, 2010 [Page 18]
Internet-Draft GRIP March 2010
</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
Thomson Expires September 6, 2010 [Page 19]
Internet-Draft GRIP March 2010
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 [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 before using
it. 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,
"application/grip-ad+xml" for GRIP assistance data documents in
Section 11.2.
A registry for GRIP errors is defined in Section 11.3.
The XML namespace used in GRIP metadata and control documents is
registered in Section 11.4, the corresponding schema definition is
registered in Section 11.5.
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.
Thomson Expires September 6, 2010 [Page 20]
Internet-Draft GRIP March 2010
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 [RFC3023].
Encoding considerations: Same as the encoding considerations of
application/xml as specified in Section 3.2 of RFC 3023 [RFC3023].
Security considerations: Security considerations are described in
Section 10. Many of the security considerations in Section 10 of
RFC 3023 [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 [RFC3023], and many of the considerations
described there also apply to application/grip+xml.
Thomson Expires September 6, 2010 [Page 21]
Internet-Draft GRIP March 2010
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 [RFC3023].
Encoding considerations: Same as the encoding considerations of
application/xml as specified in Section 3.2 of RFC 3023 [RFC3023].
Security considerations: Many of the security considerations in
Section 10 of RFC 3023 [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. The document element of this XML document determines
the nature of the content.
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>
Thomson Expires September 6, 2010 [Page 22]
Internet-Draft GRIP March 2010
Intended usage: LIMITED USE
Author/Change controller: The IETF
Other information: This media type is a specialization of
application/xml [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 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], 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.
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].
URI: urn:ietf:params:xml:ns:grip
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
XML:
Thomson Expires September 6, 2010 [Page 23]
Internet-Draft GRIP March 2010
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].
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 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
[RFC2119] Bradner, S., "Key words for use
in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119,
March 1997.
[RFC2616] Fielding, R., Gettys, J.,
Thomson Expires September 6, 2010 [Page 24]
Internet-Draft GRIP March 2010
Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T.
Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1",
RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS",
RFC 2818, May 2000.
[RFC3023] Murata, M., St. Laurent, S.,
and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[RFC3688] Mealling, M., "The IETF XML
Registry", BCP 81, RFC 3688,
January 2004.
[RFC5491] Winterbottom, J., Thomson, M.,
and H. Tschofenig, "GEOPRIV
Presence Information Data
Format Location Object
(PIDF-LO) Usage Clarification,
Considerations, and
Recommendations", RFC 5491,
March 2009.
13.2. Informative References
[RFC1305] Mills, D., "Network Time
Protocol (Version 3)
Specification, Implementation",
RFC 1305, March 1992.
[RFC4119] Peterson, J., "A Presence-based
GEOPRIV Location Object
Format", RFC 4119,
December 2005.
[RFC4330] Mills, D., "Simple Network Time
Protocol (SNTP) Version 4 for
IPv4, IPv6 and OSI", RFC 4330,
January 2006.
[RFC5226] Narten, T. and H. Alvestrand,
"Guidelines for Writing an IANA
Considerations Section in
RFCs", BCP 26, RFC 5226,
May 2008.
Thomson Expires September 6, 2010 [Page 25]
Internet-Draft GRIP March 2010
[I-D.ietf-geopriv-lbyr-requirements] Marshall, R., "Requirements for
a Location-by-Reference
Mechanism", draft-ietf-geopriv-
lbyr-requirements-09 (work in
progress), November 2009.
[I-D.ietf-geopriv-geo-uri] Mayrhofer, A. and C. Spanring,
"A Uniform Resource Identifier
for Geographic Locations ('geo'
URI)",
draft-ietf-geopriv-geo-uri-04
(work in progress),
November 2009.
[W3C.REC-xml-names-20060816] Bray, T., Hollander, D., and A.
Layman, "Namespaces in XML 1.0
(Second Edition)", World Wide
Web Consortium FirstEdition REC
-xml-names-20060816,
August 2006, <http://
www.w3.org/TR/2006/
REC-xml-names-20060816>.
[I-D.thomson-geopriv-grip-gps] Thomson, M., "Global Position
System (GPS) Assistance Data
for GRIP", draft-thomson-
geopriv-grip-gps-00 (work in
progress), Jul 2009.
[W3C.REC-xmlschema-1-20010502] Thompson, H., Beech, D.,
Maloney, M., and N. Mendelsohn,
"XML Schema Part 1:
Structures", World Wide Web
Consortium FirstEdition REC-
xmlschema-1-20010502, May 2001,
<http://www.w3.org/TR/2001/
REC-xmlschema-1-20010502>.
[ISO.19757-2.2008] International Organization for
Standardization, "Document
Schema Definition Language
(DSDL) -- Part 2: Regular-
grammar-based validation --
RELAX NG", ISO Standard
19757-2, 2008.
Thomson Expires September 6, 2010 [Page 26]
Internet-Draft GRIP March 2010
Author's Address
Martin Thomson
Andrew Corporation
PO Box U40
Wollongong University Campus, NSW 2500
AU
Phone: +61 2 4221 2915
EMail: martin.thomson@andrew.com
URI: http://www.andrew.com/
Thomson Expires September 6, 2010 [Page 27]
| PAFTECH AB 2003-2026 | 2026-04-24 03:04:49 |