idnits 2.17.1
draft-thomson-geopriv-grip-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (June 29, 2011) is 4686 days in the past. Is this
intentional?
Checking references for intended status: Experimental
----------------------------------------------------------------------------
** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110)
** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303)
-- Obsolete informational reference (is this intentional?): RFC 1305
(Obsoleted by RFC 5905)
-- Obsolete informational reference (is this intentional?): RFC 4330
(Obsoleted by RFC 5905)
-- Obsolete informational reference (is this intentional?): RFC 5226
(Obsoleted by RFC 8126)
Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 GEOPRIV M. Thomson
3 Internet-Draft Andrew Corporation
4 Intended status: Experimental June 29, 2011
5 Expires: December 31, 2011
7 Global Navigation Satellite System (GNSS) Reference Information Protocol
8 (GRIP)
9 draft-thomson-geopriv-grip-02.txt
11 Abstract
13 This document describes a means of acquiring Global Navigation
14 Satellite System (GNSS) assistance data using HTTP. Assistance data
15 aids GNSS receivers in acquiring and measuring satellite signals, as
16 well as being useful in calculating positions. The GNSS Reference
17 Information Protocol (GRIP) provides a framework for discovering
18 resources capable of providing any kind of location-based assistance
19 data.
21 Status of This Memo
23 This Internet-Draft is submitted in full conformance with the
24 provisions of BCP 78 and BCP 79.
26 Internet-Drafts are working documents of the Internet Engineering
27 Task Force (IETF). Note that other groups may also distribute
28 working documents as Internet-Drafts. The list of current Internet-
29 Drafts is at http://datatracker.ietf.org/drafts/current/.
31 Internet-Drafts are draft documents valid for a maximum of six months
32 and may be updated, replaced, or obsoleted by other documents at any
33 time. It is inappropriate to use Internet-Drafts as reference
34 material or to cite them other than as "work in progress."
36 This Internet-Draft will expire on December 31, 2011.
38 Copyright Notice
40 Copyright (c) 2011 IETF Trust and the persons identified as the
41 document authors. All rights reserved.
43 This document is subject to BCP 78 and the IETF Trust's Legal
44 Provisions Relating to IETF Documents
45 (http://trustee.ietf.org/license-info) in effect on the date of
46 publication of this document. Please review these documents
47 carefully, as they describe your rights and restrictions with respect
48 to this document. Code Components extracted from this document must
49 include Simplified BSD License text as described in Section 4.e of
50 the Trust Legal Provisions and are provided without warranty as
51 described in the Simplified BSD License.
53 Table of Contents
55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
56 1.1. Advantages of Assistance Data . . . . . . . . . . . . . . 4
57 2. Conventions used in this document . . . . . . . . . . . . . . 5
58 3. GRIP Operation Overview . . . . . . . . . . . . . . . . . . . 5
59 4. GRIP Metadata . . . . . . . . . . . . . . . . . . . . . . . . 5
60 4.1. Local and Global Assistance Data . . . . . . . . . . . . . 6
61 4.2. GRIP Metadata Format . . . . . . . . . . . . . . . . . . . 7
62 4.2.1. 'coverage' element . . . . . . . . . . . . . . . . . . 7
63 4.2.2. 'ad' element . . . . . . . . . . . . . . . . . . . . . 8
64 5. GRIP Assistance Data Requests . . . . . . . . . . . . . . . . 8
65 5.1. Location Parameters . . . . . . . . . . . . . . . . . . . 9
66 6. GRIP Errors . . . . . . . . . . . . . . . . . . . . . . . . . 10
67 7. Assistance Data . . . . . . . . . . . . . . . . . . . . . . . 10
68 7.1. Caching Assistance Data . . . . . . . . . . . . . . . . . 11
69 7.2. Time Assistance . . . . . . . . . . . . . . . . . . . . . 12
70 8. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 12
71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
73 10.1. Registration of MIME type 'application/grip+xml' . . . . . 16
74 10.2. Registration of MIME type 'application/grip-ad+xml' . . . 17
75 10.3. Error code Registry . . . . . . . . . . . . . . . . . . . 18
76 10.4. URN Sub-Namespace Registration for
77 'urn:ietf:params:xml:ns:grip' . . . . . . . . . . . . . . 18
78 10.5. XML Schema Registration . . . . . . . . . . . . . . . . . 19
79 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
81 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19
82 12.2. Informative References . . . . . . . . . . . . . . . . . . 20
84 1. Introduction
86 A Global Navigation Satellite System (GNSS) provides a signal that
87 enables accurate determination of the position of a receiver in space
88 and time. A constellation of satellites transmit radio signals that
89 the receiver is able to measure. From these measurements, the
90 location of the receiver and the time of measurement can be
91 determined using knowledge about the position and velocity of the
92 satellites and the signal they transmit.
94 Acquisition of satellite signals requires searching for the extremely
95 weak signal transmitted by each satellite. Satellites transmit a
96 distinct repeating code that is used by the receiver for signal
97 acquisition. Acquiring the signal is done by synchronizing with the
98 received signal in both frequency and time. In order to synchronize,
99 the receiver searches in two dimensions:
101 time/code phase: The distance between the satellite and receiver
102 means that the receiver sees a signal that is offset in time. The
103 amount of time shift is known as code phase since it is measured
104 within the window of the repeated code sequence. Code phase forms
105 the primary measurement used in calculating a position.
107 frequency: The relative speed of satellite and receiver causes
108 Doppler shift of the satellite signal.
110 To make use of satellite measurements, information about the
111 satellite and the signal that it transmits is required. To achieve
112 this, satellite signals are typically modulated at a low rate with a
113 navigation message. The navigation message provides information that
114 is used in calculation of location and time, including information on
115 satellite orbit, satellite health, time model, and atmospheric
116 effects on the signal. The navigation message is transmitted by
117 satellites at very low rates to avoid hampering the measurement
118 process.
120 Once satellite signals have been acquired and measured, the
121 measurement information is combined with the information from the
122 navigation message and a position (and time) can be calculated.
123 Successful calculation of a position typically requires measurement
124 data for a minimum of 5 satellites unless otherwise supplemented, or
125 4 satellites if the receiver has accurate time.
127 If a receiver has to perform all these steps independently, satellite
128 acquisition and receipt of the navigation message can take
129 significant amounts of time. Improvements in receiver design have
130 increased receiver sensitivity and the speed that signals are
131 acquired. However, the low data rates used for the navigation
132 message adds a fixed delay to this process. Use of assistance data
133 provides a dramatic improvement in the time taken to acquire signals
134 and produce a result. Dedicated data networks are able to provide
135 the information contained in the navigation message much more
136 efficiently.
138 An assistance data server uses a reference network - a distributed
139 set of GNSS receivers - to acquire information about satellite
140 signals. The server is then able to provide this information to
141 receivers and aid in GNSS signal measurement and position
142 calculation.
144 This document provides a means of acquiring GNSS assistance data
145 using GRIP, a protocol based on HTTP [RFC2616]. Basic mechanisms are
146 specified for extending the use of GRIP to any form of assistance
147 data.
149 [I-D.thomson-geopriv-grip-gps] defines assistance data for the Global
150 Positioning System (GPS).
152 1.1. Advantages of Assistance Data
154 GNSS assistance data is information provided to a receiver that is
155 provided to improve the quality and timeliness of GNSS measurements
156 or positioning. The most basic set of assistance data includes the
157 same information provided in the navigation message. Additional
158 forms of assistance data include information customized to a
159 particular receiver to assist it in acquiring signals, or information
160 about satellite ephemerides (orbits) that is useful over a longer
161 period of time.
163 Acquiring assistance data from the network completely removes the
164 need to receive the navigation message. Navigation message content
165 can be transmitted to the receiver using the vastly more efficient
166 communication paths provided by a data network. This removes a
167 significant step from the process of determining a position.
169 Knowing what satellites to search for can reduce signal acquisition
170 time. One of the most basic pieces of information provided by
171 assistance data is knowledge of which satellites are above the
172 horizon and can therefore be measured. Concentrating on "visible"
173 satellites ensures that less time is wasted on attempting to measure
174 signals that could not possibly be found.
176 Assistance data can provide information about where in the frequency/
177 code phase space to search for a particular satellite signal. This
178 reduces the time required to acquire a satellite signal. Since an
179 approximate frequency and code phase can be known, it becomes
180 feasible to spend more time searching for weaker signals, improving
181 receiver sensitivity. Improved sensitivity ensures that GNSS can be
182 used in areas where signal penetration is poor, like buildings and
183 other areas with poor sky visibility, and increases the likelihood of
184 getting sufficient satellite measurements to calculate a position.
186 Assistance data also enables compensation for the effects of the
187 navigation message. Knowing the content of the navigation message
188 ahead of time means that the receiver is able to anticipate the
189 effect of its modulation on the signal and compensate accordingly.
190 This increases the sensitivity of the receiver and allows for faster
191 signal acquisition.
193 Specialized assistance data types can also provide further
194 assistance. Assistance data can provide more sophisticated models of
195 satellite orbits, or localized data relating to signal propagation or
196 interference.
198 2. Conventions used in this document
200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
202 document are to be interpreted as described in [RFC2119].
204 3. GRIP Operation Overview
206 A client is configured with the location of a GRIP server, or follows
207 a hyperlink that leads to a GRIP server. This URI indicates the
208 location of a GRIP metadata document (Section 4), which describes all
209 that the server is capable of.
211 From the metadata document, the client is able to determine what
212 information is made available by the GRIP server and where that
213 information is available from. The client retrieves (Section 5) one
214 or more resources to acquire assistance data.
216 4. GRIP Metadata
218 A server providing a GRIP service might provide a certain subset of
219 assistance data to clients. Conveying the set of assistance data
220 types that it is capable of providing to clients is the basis of
221 GRIP. To that end, a metadata document format is defined.
223 A client retrieves a GRIP metadata document using an HTTP "GET"
224 request. The metadata document contains a listing of each of the
225 supported assistance data types, plus a URI indicating where each
226 type can be requested.
228 The following GRIP metadata document shows support for three global
229 assistance data types, support for two local assistance data types
230 over a small area.
232
234
235 /grip/utc
236 /grip/ephemeris
237 /grip/ionosphere
238
240
241
242
244
245
246
247 -33.856625 151.215906 -33.856299 151.215343
248 -33.856326 151.214731 -33.857533 151.214495
249 -33.857720 151.214613 -33.857369 151.215375
250 -33.856625 151.215906
251
252
253
254
255
256 /grip/ephemeris
257 /grip/acqAssist
258
259
261 A GRIP metadata document can be provided in response to an HTTP
262 "OPTIONS" request made to any GRIP resource. This metadata document
263 can include information about that resource (global and local
264 elements with coverage), or it can include information on other
265 resources.
267 4.1. Local and Global Assistance Data
269 The GRIP metadata format describes the types of assistance data that
270 the server is willing to provide, separated into two sections: local
271 and global.
273 Local assistance data applies to a particular position on the Earth.
274 When requesting this information, the client indicates the location
275 of interest. The server constructs assistance data that is specific
276 to that location.
278 Global assistance data can be acquired that is useful to a receiver
279 regardless of the position of the receiver. For instance, in GPS the
280 relationship between the GPS time system and Universal Coordinated
281 Time (UTC) is globally applicable.
283 Some assistance data types are always localized, other items are
284 always global. In some cases, the localized data provided for some
285 types of assistance data is simply a subset of the global data that
286 is useful at the specified location.
288 For instance, a satellite navigation model, which includes
289 information on the position of the satellite, can be provided as
290 both global and local data. A global request might provide
291 navigation parameters for all satellites in the constellation; a
292 local request might only include those satellites that can be
293 viewed from the indicated location.
295 4.2. GRIP Metadata Format
297 GRIP metadata is specified as an XML document of type
298 "application/grip+xml". This document is split into three sections:
300 global: This element describes what forms of global assistance data
301 are made available and where each may be retrieved.
303 local: This element describes what forms of local assistance data
304 are made available and where each may be retrieved.
306 4.2.1. 'coverage' element
308 In order to provide GNSS assistance data, receivers need to observe
309 and record satellite signals across a large area. These receivers
310 either need to receive a signal from a satellite (such as the GPS
311 navigation message) or take measurements of the satellite signal.
313 Each receiver can only measure or observe a satellite for part of its
314 orbit. A global distribution of receivers is necessary to be able to
315 provide assistance data for the entire planet. Where receivers are
316 distributed over a smaller area, GRIP provides a means to indicate
317 where receivers are able to measure satellite signals.
319 Both global and local sections optionally include a "coverage"
320 element. The "coverage" specifies the region where the provided
321 information provided is applicable. Outside this area, the
322 assistance data might not be comprehensive or completely accurate.
324 The coverage region is specified using a GML "Polygon" or "Envelope",
325 or a "Circle" as defined in [RFC5491]. If no "coverage" element is
326 specified, this indicates that assistance data can be provided for
327 any location on the Earth.
329 A GRIP service MAY provide information outside its indicated coverage
330 area. Clients need to be aware that this information could be
331 inaccurate, missing certain elements, or it could be extrapolated
332 from old information.
334 Coverage might vary depending on the type of assistance data. Some
335 forms of assistance data, such as differential corrections, can only
336 be collected for a small geographic area. Therefore, multiple
337 "global" or "local" elements can be specified with different coverage
338 areas.
340 If the same assistance data type appears multiple times, or if
341 multiple coverage elements are included, the coverage for that
342 assistance data type is the union of the associated coverage regions.
344 4.2.2. 'ad' element
346 The "ad" element indicates availability of a specific type of
347 assistance data.
349 The text content of the "ad" element indicates a URI where assistance
350 data can be acquired. This URI is either an absolute URI or
351 specified relative to the base URI of the GRIP index document.
353 The type of assistance data provided is specifed in the "type"
354 attribute of the "ad" element. This identifies an XML element by its
355 qualified name [W3C.REC-xml-names-20060816], using the namespace
356 context from the enclosing document.
358 When included as a child of the "global" element, the "ad" element
359 describes the location of resources that contain the indicated items
360 of global assistance data. Similarly, when included in the "local"
361 element, it indicates where local assistance can be acquired.
363 5. GRIP Assistance Data Requests
365 A GRIP assistance data request is a HTTP GET to the URI indicated in
366 the GRIP index.
368 For global assistance data resources, an unmodified request is
369 sufficient to retrieve the indicated information.
371 For local assistance data resources, a "GeoLocation" header is
372 included in the request.
374 The same resource MAY provide both global and local assistance data
375 of the same type, using the presence or absence of the "Geolocation"
376 header to determine which of these is requested.
378 The MIME type of all assistance data documents is
379 "application/grip-ad+xml". The document contains an XML document
380 with a document element of the type indicated in the GRIP index.
382 A server MUST generate appropriate HTTP status codes in response to
383 errors. As long as it is acceptable to clients, the HTTP response
384 SHOULD contain a GRIP "error" in the body of the message, using a
385 MIME type of "application/grip+xml".
387 5.1. Location Parameters
389 The client MUST specify the location that the local assistance data
390 is applicable to in a "Geolocation" header. Location information can
391 be provided in the body of the request or by providing a URI to an
392 external resource.
394 If location information is necessary, but not provided, the server
395 responds with an error (Section 6) contained in an HTTP 427 (Bad
396 Geolocation) response.
398 GET /grip/acqAssist HTTP/1.1
399 Host: grip.example.com
400 Accept: application/grip-ad+xml,application/grip+xml;q=0.5
401 Geolocation: geo:-35.406,150.882;u=1200
403 Latitude, longitude and altitude specified in URI parameters use the
404 World Geodetic System 1984 (WGS 84) coordinate reference system.
406 Location information MAY be provided by reference. The "locationuri"
407 parameter is used to include a URI. Percent-encoding MUST be used to
408 ensure that reserved characters in the URI are correctly escaped.
410 The location URI either takes the form of an indirect reference, or
411 location URI [RFC5808]. A location URI MUST resolve to a presence
412 data information format - location object (PIDF-LO) [RFC4119]
413 document. Alternatively, information can be provided directly in URI
414 form using a geo: URI [RFC5870].
416 A server MAY choose to not support the "locationuri" parameter, or to
417 limit the URI schemes that it accepts. If this is not the case, an
418 error with a code of "unsupportedLocation" MUST be provided. A
419 client MUST be prepared to receive this code and either dereference
420 the URI and either provide the values directly or abandon the
421 request.
423 6. GRIP Errors
425 Errors in the URIs provided are firstly indicated using HTTP errors.
426 However, the body of the HTTP error MUST contain a GRIP document that
427 describes the error.
429 An error document consists of an "error" element, with a mandatory
430 "code" attribute. Any number of "message" elements MAY be added to
431 convey human-readable feedback on the error; each "message" element
432 contains an "xml:lang" attribute that identifies the language of the
433 text.
435
436 Missing Geolocation header.
437
439 The following values for the "code" attribute and the values of
440 corresponding HTTP errors are defined:
442 noLocation: (HTTP 427) A request for local assistance data did not
443 contain location information.
445 badLocation: (HTTP 427) A request for local assistance data
446 contained location information that was badly formatted or was not
447 understood by the server.
449 unsupportedLocation: (HTTP 427) A request for local assistance data
450 contained location information that might be valid, but the server
451 is not able to use the provided form.
453 noCoverage: (HTTP 400) A request for assistance data indicated a
454 location that the server has no coverage for.
456 noData: (HTTP 503) The identified assistance data type is currently
457 unavailable. Used when the server is temporarily unable to
458 provide assistance data.
460 7. Assistance Data
462 Assistance data that can be expressed in XML form is supported by
463 this protocol. The XML element is the basic unit of assistance data,
464 since this is what is identified in the "ad" element.
466 All assistance data is provided with the same MIME type,
467 "application/grip-ad+xml". The document element determines the type.
469 New definitions of assistance data only require the definition of an
470 XML format and the use of a unique namespace URI
471 [W3C.REC-xml-names-20060816]. Formal schema definitions, such as XML
472 Schema [W3C.REC-xmlschema-1-20010502] or RelaxNG [ISO.19757-2.2008]
473 SHOULD be used, but are not necessary as long as structure and
474 semantics are clearly defined.
476 Assistance data for the Global Position System (GPS) is defined in
477 [I-D.thomson-geopriv-grip-gps]. These assistance data are used in
478 examples throughout this document.
480 7.1. Caching Assistance Data
482 Caching of assistance data is particularly useful in improving
483 responsiveness and alleviating server load. Standard HTTP mechanisms
484 are suitable for controlling caching of global assistance data, but
485 local assistance data introduces complications. Adding a
486 "geolocation" tag to the "Vary" header ensures that values are
487 properly cached.
489 Assistance data for two locations within close proximity might not
490 vary significantly. However, HTTP caches place significance in any
491 change in a URI, including trivially significant decimal places in
492 numbers and even the ordering of URI parameters. Therefore, small
493 changes in location can result in a completely different URI. A
494 server MAY redirect requests that include "Geolocation" headers to
495 location-specific resources in order to provide better support for
496 caching.
498 In serving a large number of requests, a server might choose to cache
499 assistance data that is applicable over a geographic area. A method
500 of caching optimization relies on fixing the locations that
501 assistance data is provided for to a grid. Assistance data is only
502 provided for the center point of the grid. All other points in the
503 grid receive the same assistance data.
505 The grid-based method allows caching by the server itself, but not a
506 generic HTTP cache. A server MAY use HTTP redirection to more
507 efficiently use generic HTTP caches. An HTTP 303 (See Other) is
508 appropriate when responses are dependent on location. This improves
509 cacheability at a cost in latency. Alternatively, using the
510 "Content-Location" header doesn't aid caching of an immediate
511 request, but improves cacheability for subsequent requests that are
512 directed at resource identified in the "Content-Location" header.
514 Local assistance data that is based on a location URI can change if
515 the referenced document also changes. A server MUST either indicate
516 that such local assistance data is not cacheable through the use of
517 "Cache-Control" headers or indicate validity times with an "Expires".
518 The server might also include a "Geolocation" header that indicates
519 the area that the assistance data applies to.
521 Assistance data itself can be used to derive the location of a
522 client. Servers MUST NOT allow assistance data based on location
523 information to enter a shared cache. The "Cache-Control" headers for
524 such requests MUST be set to "private" or "no-cache". Where
525 redirection is used, the redirection response cannot be placed in a
526 shared cache, but the resulting document is cacheable.
528 7.2. Time Assistance
530 It is common for GNSS systems to use a different time model than UTC.
531 Commonly assistance data is used to relate the GNSS time to UTC.
532 This allows a client that is accurately synchronized to the GNSS time
533 (a necessary outcome or prerequisite of location determination) to
534 very accurately synchronize with UTC time.
536 Assistance data that relates time systems is an important part of
537 this protocol. Indeed, assistance data that relates GNSS time with
538 other time systems is also useful.
540 It is not the intent for this protocol to itself provide time
541 synchronization functions. Other protocols, such as Network Time
542 Protocol (NTP) [RFC1305], or Simple NTP [RFC4330], perform this task
543 efficiently and accurately. Specific access technologies also
544 provide time synchronization services that are linked to access
545 technology specific timing characteristics.
547 8. XML Schema
549
557
558
560 GNSS Reference Information Protocol (GRIP) Schema
561
562
563
565 This document defines core elements of GRIP documents.
566
567
569
570
572
573
574
575
576
577
579
581
583
584
585
586
587
589
590
591
592
593
595
597
599
600
601
602
604
605
606
607
608
609
610
612
613
614
616
617
618
619
620
621
622
624
625
626
627
628
629
630
632
634
635
637
638
639
640
642
643
644
645
646
647
648
649
651
653 9. Security Considerations
655 A server MAY individually authorize clients and challenge clients to
656 provide authentication credentials. How authentication credentials
657 are negotiated is outside the scope of this specification.
659 Receivers need to be aware that falsified assistance data can be used
660 to cause a location calculation to be arbitrarily incorrect. In
661 particular, falsifying the location of a satellite by altering
662 ephemeris information could be used to cause the receiver to
663 calculate any location. Small changes in location caused by this
664 methods are difficult to detect, but larger changes can be identified
665 through inconsistency in Doppler shift and comparison of basic
666 satellite location with previously acquired (and trusted) estimates,
667 such as the GPS almanac.
669 Location information provided by a client in making a request for
670 local assistance data is potentially privacy sensitive. A client
671 SHOULD use HTTP over TLS [RFC2818] to ensure that only the identified
672 server is able to use this information. Location URIs SHOULD use
673 similarly secured channels to prevent attackers from intercepting or
674 falsifying this information.
676 Because location information is potentially sensitive, servers MUST
677 NOT use location information for anything other than serving the
678 request that contains it.
680 GRIP metadata is designed to carry descriptions of how assistance
681 data can be retrieved. This document could contain references to
682 resources under the control of other parties that might be unaware of
683 this linkage. The only authoritative source of metadata for a
684 resource is the resource itself; all other links are informative
685 only.
687 A malicious server might use links to cause a client to leak
688 information or trigger unintended actions. For instance, links in
689 metadata might refer to files on the client system, or they might
690 invoke specific protocol actions. Clients MUST validate any URI it
691 receives before using it. Restricting use of URIs to "https:" (and
692 optionally "http:") URIs limits the scope of any attack. Only
693 accepting responses of the MIME type "application/grip-ad+xml"
694 further reduces the ability of an attacker to trigger client
695 behavior.
697 10. IANA Considerations
699 This section registers two MIME types: "application/grip+xml" for
700 GRIP metadata and control documents in Section 10.1,
701 "application/grip-ad+xml" for GRIP assistance data documents in
702 Section 10.2.
704 A registry for GRIP errors is defined in Section 10.3.
706 The XML namespace used in GRIP metadata and control documents is
707 registered in Section 10.4, the corresponding schema definition is
708 registered in Section 10.5.
710 10.1. Registration of MIME type 'application/grip+xml'
712 This section registers the "application/grip+xml" MIME type, used for
713 GRIP metadata and the core protocol.
715 To: ietf-types@iana.org
717 Subject: Registration of MIME media type application/grip+xml
719 MIME media type name: application
721 MIME subtype name: grip+xml
723 Required parameters: (none)
725 Optional parameters: charset
726 Same as the charset parameter of application/xml as specified in
727 Section 3.2 of RFC 3023 [RFC3023].
729 Encoding considerations: Same as the encoding considerations of
730 application/xml as specified in Section 3.2 of RFC 3023 [RFC3023].
732 Security considerations: Security considerations are described in
733 Section 9. Many of the security considerations in Section 10 of
734 RFC 3023 [RFC3023] also apply.
736 Interoperability considerations: This content type provides a basis
737 for a protocol.
739 Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please
740 replace XXXX with the RFC number for this specification.]
742 Applications which use this media type: Global Navigation Satellite
743 System (GNSS) receivers and servers that provide assistance data
744 for GNSS receivers.
746 Additional Information: Magic Number(s): (none)
747 File extension(s): .grip
748 Macintosh File Type Code(s): TEXT
750 Person & email address to contact for further information: Martin
751 Thomson
753 Intended usage: LIMITED USE
755 Author/Change controller: The IETF
757 Other information: This media type is a specialization of
758 application/xml [RFC3023], and many of the considerations
759 described there also apply to application/grip+xml.
761 10.2. Registration of MIME type 'application/grip-ad+xml'
763 This section registers the "application/grip-ad+xml" MIME type, used
764 for the expression of assistance data.
766 To: ietf-types@iana.org
768 Subject: Registration of MIME media type application/grip-ad+xml
770 MIME media type name: application
772 MIME subtype name: grip-ad+xml
774 Required parameters: (none)
776 Optional parameters: charset
777 Same as the charset parameter of application/xml as specified in
778 Section 3.2 of RFC 3023 [RFC3023].
780 Encoding considerations: Same as the encoding considerations of
781 application/xml as specified in Section 3.2 of RFC 3023 [RFC3023].
783 Security considerations: Many of the security considerations in
784 Section 10 of RFC 3023 [RFC3023] apply.
786 Interoperability considerations: This content type is used to
787 provide an interoperable format for assistance data.
788 Interoperability depends on the definition of the assistance data,
789 which is not proscribed to allow for new assistance data
790 definitions. The document element of this XML document determines
791 the nature of the content.
793 Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please
794 replace XXXX with the RFC number for this specification.]
796 Applications which use this media type: Global Navigation Satellite
797 System (GNSS) receivers and servers that provide assistance data
798 for GNSS receivers.
800 Additional Information: Magic Number(s): (none)
801 File extension(s): .grip
802 Macintosh File Type Code(s): TEXT
804 Person & email address to contact for further information: Martin
805 Thomson
807 Intended usage: LIMITED USE
809 Author/Change controller: The IETF
811 Other information: This media type is a specialization of
812 application/xml [RFC3023], and many of the considerations
813 described there also apply to application/grip-ad+xml.
815 10.3. Error code Registry
817 This document requests that the IANA create a new registry for GRIP,
818 including an initial registry for error codes. Error codes are
819 included in GRIP error documents as described in Section 6 and MAY be
820 any sequence of characters.
822 The following summarizes the requested registry:
824 Related Registry: Geopriv GRIP Registries, Error codes for GRIP
826 Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
827 with the RFC number for this specification.]
829 Registration/Assignment Procedures: Following the policies outlined
830 in [RFC5226], the IANA policy for assigning new values for the
831 Error codes for GRIP registry shall be Standards Action: Values
832 are assigned only for Standards Track RFCs approved by the IESG.
834 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
835 Martin Thomson (martin.thomson@andrew.com).
837 This section pre-registers the error codes defined in Section 6.
839 10.4. URN Sub-Namespace Registration for 'urn:ietf:params:xml:ns:grip'
841 This section registers a new XML namespace,
842 "urn:ietf:params:xml:ns:grip", per the guidelines in [RFC3688].
844 URI: urn:ietf:params:xml:ns:grip
846 Registrant Contact: IETF, GEOPRIV working group,
847 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
849 XML:
851 BEGIN
852
853
855
856
857 GRIP Metadata
858
859
860 Namespace for GRIP Metadata Definitions
861 urn:ietf:params:xml:ns:grip
862 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
863 with the RFC number for this specification.]
864 See RFCXXXX
865
866
867 END
869 10.5. XML Schema Registration
871 This section registers an XML schema as per the guidelines in
872 [RFC3688].
874 URI: urn:ietf:params:xml:schema:grip
876 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
877 Martin Thomson (martin.thomson@andrew.com).
879 Schema: The XML for this schema can be found as the entirety of
880 Section 8 of this document.
882 11. Acknowledgements
884 This document is part of the definition of GRIP. The original GRIP
885 protocol was developed by the University of New South Wales through
886 the OSGRS project . The GPS expertise
887 of Neil Harper was invaluable in assembling this document.
889 12. References
891 12.1. Normative References
893 [RFC2119] Bradner, S., "Key words for use in
894 RFCs to Indicate Requirement Levels",
895 BCP 14, RFC 2119, March 1997.
897 [RFC2616] Fielding, R., Gettys, J., Mogul, J.,
898 Frystyk, H., Masinter, L., Leach, P.,
899 and T. Berners-Lee, "Hypertext
900 Transfer Protocol -- HTTP/1.1",
901 RFC 2616, June 1999.
903 [RFC2818] Rescorla, E., "HTTP Over TLS",
904 RFC 2818, May 2000.
906 [RFC3023] Murata, M., St. Laurent, S., and D.
907 Kohn, "XML Media Types", RFC 3023,
908 January 2001.
910 [RFC3688] Mealling, M., "The IETF XML
911 Registry", BCP 81, RFC 3688,
912 January 2004.
914 [RFC5491] Winterbottom, J., Thomson, M., and H.
915 Tschofenig, "GEOPRIV Presence
916 Information Data Format Location
917 Object (PIDF-LO) Usage Clarification,
918 Considerations, and Recommendations",
919 RFC 5491, March 2009.
921 12.2. Informative References
923 [RFC1305] Mills, D., "Network Time Protocol
924 (Version 3) Specification,
925 Implementation", RFC 1305,
926 March 1992.
928 [RFC4119] Peterson, J., "A Presence-based
929 GEOPRIV Location Object Format",
930 RFC 4119, December 2005.
932 [RFC4330] Mills, D., "Simple Network Time
933 Protocol (SNTP) Version 4 for IPv4,
934 IPv6 and OSI", RFC 4330,
935 January 2006.
937 [RFC5226] Narten, T. and H. Alvestrand,
938 "Guidelines for Writing an IANA
939 Considerations Section in RFCs",
940 BCP 26, RFC 5226, May 2008.
942 [RFC5808] Marshall, R., "Requirements for a
943 Location-by-Reference Mechanism",
944 RFC 5808, May 2010.
946 [RFC5870] Mayrhofer, A. and C. Spanring, "A
947 Uniform Resource Identifier for
948 Geographic Locations ('geo' URI)",
949 RFC 5870, June 2010.
951 [W3C.REC-xml-names-20060816] Layman, A., Hollander, D., and T.
952 Bray, "Namespaces in XML 1.0 (Second
953 Edition)", World Wide Web Consortium
954 FirstEdition REC-xml-names-20060816,
955 August 2006, .
958 [I-D.thomson-geopriv-grip-gps] Thomson, M., "Global Position System
959 (GPS) Assistance Data for GRIP",
960 draft-thomson-geopriv-grip-gps-02
961 (work in progress), Jun 2011.
963 [W3C.REC-xmlschema-1-20010502] Maloney, M., Thompson, H.,
964 Mendelsohn, N., and D. Beech, "XML
965 Schema Part 1: Structures", World
966 Wide Web Consortium FirstEdition REC-
967 xmlschema-1-20010502, May 2001, .
971 [ISO.19757-2.2008] International Organization for
972 Standardization, "Document Schema
973 Definition Language (DSDL) -- Part 2:
974 Regular-grammar-based validation --
975 RELAX NG", ISO Standard 19757-2,
976 2008.
978 Author's Address
980 Martin Thomson
981 Andrew Corporation
982 PO Box U40
983 Wollongong University Campus, NSW 2500
984 AU
986 Phone: +61 2 4221 2915
987 EMail: martin.thomson@andrew.com
988 URI: http://www.andrew.com/