idnits 2.17.1
draft-winterbottom-http-location-delivery-05.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 17.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 2847.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2858.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2865.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2871.
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 Copyright Line does not match the
current year
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'MUST not' in this paragraph:
200 (Success): This code indicates that the request was
successful. This code MUST not be used for an error response.
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (March 2, 2007) is 6262 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: '0-5' is mentioned on line 1354, but not defined
== Missing Reference: '0-9' is mentioned on line 1354, but not defined
== Unused Reference: 'RFC3275' is defined on line 2167, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346)
** 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)
** Downref: Normative reference to an Informational RFC: RFC 3693
== Outdated reference: A later version (-07) exists of
draft-ietf-geopriv-revised-civic-lo-05
== Outdated reference: A later version (-14) exists of
draft-ietf-geopriv-pdif-lo-profile-05
== Outdated reference: A later version (-03) exists of
draft-thomson-geopriv-lis-discovery-00
== Outdated reference: A later version (-02) exists of
draft-marshall-geopriv-lbyr-requirements-00
** Downref: Normative reference to an Informational draft:
draft-marshall-geopriv-lbyr-requirements (ref.
'I-D.marshall-geopriv-lbyr-requirements')
== Outdated reference: A later version (-10) exists of
draft-ietf-geopriv-l7-lcp-ps-00
** Downref: Normative reference to an Informational draft:
draft-ietf-geopriv-l7-lcp-ps (ref. 'I-D.ietf-geopriv-l7-lcp-ps')
-- No information found for draft-thomson-geopriv-location-dependability -
is the name correct?
-- Possible downref: Normative reference to a draft: ref.
'I-D.thomson-geopriv-location-dependability'
-- Obsolete informational reference (is this intentional?): RFC 793
(Obsoleted by RFC 9293)
-- Obsolete informational reference (is this intentional?): RFC 2222
(Obsoleted by RFC 4422, RFC 4752)
-- Obsolete informational reference (is this intentional?): RFC 3023
(Obsoleted by RFC 7303)
== Outdated reference: A later version (-10) exists of
draft-winterbottom-geopriv-held-identity-extensions-00
== Outdated reference: A later version (-09) exists of
draft-thomson-geopriv-held-capabilities-01
-- No information found for draft-thomson-geopriv-held-beep - is the name
correct?
Summary: 7 errors (**), 0 flaws (~~), 12 warnings (==), 13 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 GEOPRIV WG J. Winterbottom
3 Internet-Draft M. Thomson
4 Intended status: Standards Track Andrew
5 Expires: September 3, 2007 B. Stark
6 BellSouth
7 March 2, 2007
9 HTTP Enabled Location Delivery (HELD)
10 draft-winterbottom-http-location-delivery-05.txt
12 Status of this Memo
14 By submitting this Internet-Draft, each author represents that any
15 applicable patent or other IPR claims of which he or she is aware
16 have been or will be disclosed, and any of which he or she becomes
17 aware will be disclosed, in accordance with Section 6 of BCP 79.
19 Internet-Drafts are working documents of the Internet Engineering
20 Task Force (IETF), its areas, and its working groups. Note that
21 other groups may also distribute working documents as Internet-
22 Drafts.
24 Internet-Drafts are draft documents valid for a maximum of six months
25 and may be updated, replaced, or obsoleted by other documents at any
26 time. It is inappropriate to use Internet-Drafts as reference
27 material or to cite them other than as "work in progress."
29 The list of current Internet-Drafts can be accessed at
30 http://www.ietf.org/ietf/1id-abstracts.txt.
32 The list of Internet-Draft Shadow Directories can be accessed at
33 http://www.ietf.org/shadow.html.
35 This Internet-Draft will expire on September 3, 2007.
37 Copyright Notice
39 Copyright (C) The IETF Trust (2007).
41 Abstract
43 A Geopriv using protocol is described that is used for retrieving
44 location information from a server within an access network. The
45 protocol includes options for retrieving location information either
46 by-value or by-reference. The protocol supports mobile and nomadic
47 devices through Location URIs. The protocol is an application-layer
48 protocol that is independent of session-layer; an HTTP, web services
49 binding is specified.
51 Table of Contents
53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
54 1.1. Exclusions . . . . . . . . . . . . . . . . . . . . . . . . 5
55 1.2. Device or Target . . . . . . . . . . . . . . . . . . . . . 6
56 1.3. The Bigger Picture . . . . . . . . . . . . . . . . . . . . 6
57 2. Conventions used in this document . . . . . . . . . . . . . . 8
58 2.1. GEOPRIV Terminology . . . . . . . . . . . . . . . . . . . 8
59 3. HELD Overview . . . . . . . . . . . . . . . . . . . . . . . . 10
60 3.1. Requesting Location Information Directly . . . . . . . . . 10
61 3.1.1. Shaping the PIDF-LO . . . . . . . . . . . . . . . . . 11
62 3.2. Requesting a Location URI . . . . . . . . . . . . . . . . 11
63 3.2.1. Establishing a Location Server Context . . . . . . . . 12
64 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 14
65 4.1. Protocol Binding . . . . . . . . . . . . . . . . . . . . . 15
66 4.2. Location Request . . . . . . . . . . . . . . . . . . . . . 15
67 4.3. Contexts . . . . . . . . . . . . . . . . . . . . . . . . . 16
68 4.3.1. Creating Contexts . . . . . . . . . . . . . . . . . . 16
69 4.3.2. Updating Contexts . . . . . . . . . . . . . . . . . . 17
70 4.3.3. Terminating Contexts . . . . . . . . . . . . . . . . . 17
71 4.4. Combined Context and Location Requests . . . . . . . . . . 18
72 4.5. Indicating Errors . . . . . . . . . . . . . . . . . . . . 18
73 5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 19
74 5.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 20
75 5.2. "assert" Parameter . . . . . . . . . . . . . . . . . . . . 20
76 5.2.1. "method" Parameter . . . . . . . . . . . . . . . . . . 20
77 5.2.2. "timestamp" Parameter . . . . . . . . . . . . . . . . 20
78 5.2.3. "expires" Parameter . . . . . . . . . . . . . . . . . 21
79 5.2.4. "exact" Parameter . . . . . . . . . . . . . . . . . . 21
80 5.3. "locationType" Parameter . . . . . . . . . . . . . . . . . 21
81 5.3.1. "exact" Parameter . . . . . . . . . . . . . . . . . . 22
82 5.4. "profile" Parameter . . . . . . . . . . . . . . . . . . . 22
83 5.4.1. "presentity" Parameter . . . . . . . . . . . . . . . . 23
84 5.4.2. "retentionExpiry" Parameter . . . . . . . . . . . . . 23
85 5.4.3. "retentionInterval" Parameter . . . . . . . . . . . . 23
86 5.4.4. "retransmission" Parameter . . . . . . . . . . . . . . 24
87 5.4.5. "rulesetURI" Parameter . . . . . . . . . . . . . . . . 24
89 5.5. "signed" Parameter . . . . . . . . . . . . . . . . . . . . 24
90 5.6. "lifetime" Parameter . . . . . . . . . . . . . . . . . . . 24
91 5.7. "rules" Parameter . . . . . . . . . . . . . . . . . . . . 24
92 5.7.1. "rulesetURI" Parameter . . . . . . . . . . . . . . . . 25
93 5.7.2. Common Policy "ruleset" Parameter . . . . . . . . . . 25
94 5.8. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 25
95 5.9. "message" Parameter . . . . . . . . . . . . . . . . . . . 27
96 5.10. "context" Parameter . . . . . . . . . . . . . . . . . . . 27
97 5.10.1. "locationURI" Parameter . . . . . . . . . . . . . . . 27
98 5.10.2. "password" Parameter . . . . . . . . . . . . . . . . . 27
99 5.10.3. "expires" Parameter . . . . . . . . . . . . . . . . . 28
100 5.11. "location" Parameter . . . . . . . . . . . . . . . . . . . 28
101 6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 29
102 7. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 35
103 7.1. HTTP Binding WSDL . . . . . . . . . . . . . . . . . . . . 35
104 8. Security Considerations . . . . . . . . . . . . . . . . . . . 38
105 8.1. Return Routability . . . . . . . . . . . . . . . . . . . . 38
106 8.2. Transaction Layer Security . . . . . . . . . . . . . . . . 39
107 8.3. Veracity of Asserted LI . . . . . . . . . . . . . . . . . 39
108 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
109 9.1. Simple HTTP Binding Example Messages . . . . . . . . . . . 40
110 9.2. Location Request Examples . . . . . . . . . . . . . . . . 42
111 9.3. Context Creation and Update Examples . . . . . . . . . . . 44
112 9.4. Sample LG WSDL Document . . . . . . . . . . . . . . . . . 48
113 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
114 10.1. IANA Registry for HELD Result Codes . . . . . . . . . . . 49
115 10.2. URN Sub-Namespace Registration for
116 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 49
117 10.3. XML Schema Registration . . . . . . . . . . . . . . . . . 50
118 10.4. URN Sub-Namespace Registration for
119 urn:ietf:params:xml:ns:geopriv:held:http . . . . . . . . . 50
120 10.5. MIME Media Type Registration for 'application/held+xml' . 51
121 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53
122 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
123 12.1. Normative References . . . . . . . . . . . . . . . . . . . 54
124 12.2. Informative References . . . . . . . . . . . . . . . . . . 55
125 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 58
126 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 58
127 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 58
128 A.3. L7-3: Layer 7 and Layer 2/3 Provider Relationship . . . . 59
129 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 59
130 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 60
131 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 60
132 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 60
133 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 61
134 Appendix B. HELD Compliance to NENA Location Acqusition
135 Requirements . . . . . . . . . . . . . . . . . . . . 62
136 B.1. DA1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
137 B.2. DA2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
138 B.3. DA3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
139 B.4. DA4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
140 B.5. DA5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
141 B.6. DA6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
142 B.7. DA7 . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
143 B.8. DA8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
144 B.9. DA9 . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
145 B.10. DA10 . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
146 B.11. DA11 . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
147 B.12. DA12 . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
148 B.13. Rep1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
149 B.14. Rep2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
150 B.15. Rep3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
151 B.16. Rep4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
152 B.17. LocSec1 . . . . . . . . . . . . . . . . . . . . . . . . . 66
153 B.18. LocSec2 . . . . . . . . . . . . . . . . . . . . . . . . . 67
154 B.19. LocSec3 . . . . . . . . . . . . . . . . . . . . . . . . . 67
155 B.20. LocSec4 . . . . . . . . . . . . . . . . . . . . . . . . . 67
156 B.21. LocSec5 . . . . . . . . . . . . . . . . . . . . . . . . . 68
157 B.22. LocSec6 . . . . . . . . . . . . . . . . . . . . . . . . . 68
158 B.23. LocSec7 . . . . . . . . . . . . . . . . . . . . . . . . . 68
159 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 69
160 Intellectual Property and Copyright Statements . . . . . . . . . . 70
162 1. Introduction
164 The location of a Device is information that is useful for a number
165 of applications. A Device might be able to determine this
166 information using its own resources, but more often than not, the
167 Device must rely on its access network to provide this information.
168 This document describes a protocol that can be used to acquire
169 Location Information (LI) from a service within an access network.
171 This specification identifies two methods for acquiring LI. Location
172 may be retrieved from a Location Generator (LG) by-value, that is,
173 the Device may acquire LI directly. Alternatively, the Device may
174 request that the LG provide a location URI so that LI can be
175 distributed by-reference. Both of these methods are compatible, and
176 both can be provided concurrently from the same LG so that
177 application needs can be addressed individually.
179 This specification defines an XML-based protocol that enables the
180 retrieval of LI from a LG. This protocol can be bound to any
181 session-layer protocol, particularly those capable of MIME transport;
182 an HTTP binding is included as a minimum requirement.
184 1.1. Exclusions
186 This document defines a protocol for configuration purposes; that is,
187 a protocol for requesting (and receiving) the information necessary
188 to use LI. This document does not define a Geopriv Using Protocol.
189 The LG is assumed to be present within the same administrative domain
190 as the Device (the access network), which limits the security threats
191 that this protocol is exposed to.
193 This document does not specify how LI is derived. Determination of
194 the physical location of a network termination point is dependent on
195 the type of access network and the capabilities of networking
196 equipment. The specific methods that could be used are innumerable,
197 therefore this is left to individual network and equipment
198 implementations.
200 Providing LI by-reference implies that a server is able to provide
201 the Device with a public, globally-routable URI. How this URI is
202 provided is not covered by this specification. This includes any
203 interactions between the LG and LS necessary to facilitate the
204 provision of a Location URI.
206 This document does not define how an LG is discovered or configured.
207 Service discovery techniques are described in
208 [I-D.thomson-geopriv-lis-discovery].
210 1.2. Device or Target
212 LI provided for the Device is often represented as the location of a
213 user. However, in this document LI is attributed to a Device and not
214 a person. Primarily, this is because location determination
215 technologies are generally designed to locate a Device and not a
216 person. In addition to this, unless the Device requires active user
217 authentication, there is no guarantee that any particular individual
218 is using the Device at that instant. Thus, if any claim of veracity
219 is to be made for LI, the distinction between Target and Device must
220 be made explicit.
222 This distinction should not lead to the impression that the location
223 of the Device does not impact the privacy constraints required by
224 this protocol. Revealing the location of the Device almost
225 invariably reveals some information about the location of the user of
226 the Device, therefore the same level of privacy protection demanded
227 by a user is required for the Device.
229 It is expected that, for most applications, this distinction will be
230 unnecessary: LI for the Device will be used as an adequate substitute
231 for the user's LI. This requires either some additional assurances
232 about the link between Device and Target, or an acceptance of the
233 aforementioned limitations.
235 This document assumes that the Device is responsible for the protocol
236 interactions described and that it does so with the authority of the
237 Target and Rule Maker (RM).
239 1.3. The Bigger Picture
241 This document describes an interface between a Device and a Location
242 Generator (LG). Detailing the interactions between these two
243 entities requires a wider understanding of other interested parties.
245 For the Device, the most important consideration is the Target. In
246 some cases, this is the same as the Device, but it is more likely to
247 be a human user. The foundation of this protocol is that the Target
248 is able to direct the dissemination of LI, that is, the Target
249 provides authorization policies and otherwise controls how LI is
250 granted to Location Recipients (LRs). This extends to when a
251 Location Server (LS) is employed to provide a Location URI; the LS
252 cannot provide LI to an LR without express permission from the
253 Target.
255 The LG exists as an access network service. An Access Provider (AP)
256 operates this service so that Devices (and Targets) can retrieve LI.
257 The LG exists because not all Devices are capable of determining LI,
258 and because, even if a Device is able to determine its own LI, it may
259 be more efficient with assistance.
261 The following diagram shows one possible configuration of the roles
262 identified in [RFC3693] and where this protocol applies.
264 +-----------+ +-----------+
265 | Location | | Location |
266 | Generator | - - - - | Server |
267 | | | |
268 +-----------+ +-----------+
269 | |
270 HELD |
271 | |
272 Rule Maker - _ +-----------+ +-----------+
273 o - - | Device | | Location |
274 | (Target) |----Object--->| Recipient |
378 | | | (LS, RH) | | |
379 +-----------+ +----------+ +-----------+
381 Figure 2: Simple Location Request Model
383 In this model, the Device in this scenario acts as a Location Server
384 (LS) and Rule Holder (RH); it is responsible for making authorization
385 decisions about which Location Recipients are given LOs.
387 The LG needs to uniquely identify the Device within the access
388 network. The source address of the request message is sufficient in
389 most cases. Once the Device is identified, the LG uses network
390 domain-specific information to determine the location of the Device.
392 An LI request does not need to include any identification information
393 other than return addressing. In fact, the HTTP binding (Section 7)
394 includes the option for a GET request. Return routability also
395 addresses a number of security concerns, see Section 8.
397 The response from the LG is a PIDF-LO document [RFC4119], unless
398 there were errors in processing the request.
400 The interface between Device (acting as LS) and Location Recipient
401 (LR) is application-specific and outside the scope of this
402 specification.
404 3.1.1. Shaping the PIDF-LO
406 A Device can include additional information in an LI request that
407 controls how the LG populates the fields in a PIDF-LO document.
408 Related to privacy, a presentity URI and usage rules can be
409 specified. The Device can also include a location estimate, or
410 request a specific type of location information, including a request
411 for a signed PIDF-LO.
413 When requesting LI, the Device can include a presentity URI for the
414 Target and a ruleset reference. The LG incorporates this information
415 in the PIDF-LO document, or modifies the document accordingly.
417 LI contained within a PIDF-LO document can be either geodetic
418 (coordinates using latitude and longitude or some other coordinate
419 system) or civic (street or postal addresses). The Device can
420 request that the LG provide a specific type of LI, including whether
421 a jurisdictional or postal civic address is required.
423 If a Device is capable of providing its own location it can include
424 this in a request. The LG is then able to include this LI in the
425 returned PIDF-LO. The type of LI is inferred from the request when
426 LI is provided.
428 The PIDF-LO document generated by an LG MUST follow the rules in
429 [I-D.ietf-geopriv-pdif-lo-profile]. The LI sent in a request MUST
430 follow the subset of those rules relating to the construction of the
431 "location-info" element.
433 3.2. Requesting a Location URI
435 Requesting LI directly does not always address the requirements of an
436 application. A Location URI is a URI [RFC3986] of any scheme, which
437 a Location Recipient (LR) can use to retrieve LI. A Device can
438 request a Location URI instead of LI.
440 Figure 3 illustrates how this usage of HELD fits within the model
441 presented in [RFC3693]. The first aspect of the diagram shows how
442 the Device acts as an agent for the Target and retrieves a Location
443 URI, which it then provides to the Location Recipient. The second
444 aspect has the Device acting as an agent for the Rule Maker; the
445 Device forwards rules to the LG, which forwards them to the LS.
447 +-----------+ Location +--------------+
448 | Location |------URI------>| Device |
449 | Generator | | (Target) |
450 | |<-----Rules-----| (Rule Maker) |
451 +-----------+ +--------------+
452 | |
453 LO & Rules Location URI
454 | |
455 V V
456 +----------+ +------------+
457 | Location | Location | Location |
458 | Server |------Object----->| Recipient |
459 | | | |
460 +----------+ +------------+
462 Figure 3: Location URI Usage Model
464 Note that the Location Server takes the role of a (Private) Rule
465 Holder when the rules are provided by-value. The rules may also be
466 provided to the LG and LS by-reference, in which case, a Public Rule
467 Holder is required; the Public Rule Holder is not shown in this
468 diagram.
470 The interface between Device (acting as LS) and Location Recipient
471 (LR) is application-specific and outside the scope of this
472 specification. Also, any interface between Device (acting as RM) and
473 a Public Rule Holder is not relevant to this specification.
475 The merits and drawbacks of using a Location URI approach are
476 discussed in [I-D.marshall-geopriv-lbyr-requirements].
478 3.2.1. Establishing a Location Server Context
480 A Location URI is allocated for a Device by the LS. If the LS is to
481 be able to service queries for location directed at the Location URI,
482 it must maintain certain information. When the LG receives a request
483 for a Location URI, it requests that the LS allocate a URI for a
484 particular Device. As a part of providing a Location URI, the LS
485 also creates a _context_, which contains the information that it
486 requires to properly service requests to the URI.
488 This document does not make any normative statements about the
489 interface between the LG and LS. Any assumptions that are made about
490 the nature of this interface are stated where necessary.
492 A context contains sufficient information for the LS to identify the
493 Device to the LG, so that LI can be generated as required, which
494 could be on a per-request basis. The context also includes
495 instructions from the Device on how the PIDF-LO is to be generated,
496 as described in Section 3.1.1.
498 The context contains an authorization policy that describes to whom,
499 and how, LI is granted. This is a common-policy document
500 [I-D.ietf-geopriv-common-policy] that is provided by the Device in
501 the context creation request, either directly, or by reference.
503 4. Protocol Description
505 As discussed in Section 3, this protocol provides two basic
506 functions: LI request and Location URI request. Messages are defined
507 as XML documents.
509 The Location Request message is described in Section 4.2. A Location
510 Request from a Device results in a PIDF-LO document in case of
511 success, or an error message.
513 In requesting a Location URI, the Device requests that a context be
514 created on the LS. The parameters for the create context request are
515 described in Section 4.3.1. The response to a context creation
516 request includes Location URIs and a password that can be used to
517 update the information contained in the context. The details stored
518 by the LS can be updated at any time after creation using the update
519 context request, described in Section 4.3.2.
521 Table 1 shows the basic set of messages supported by this protocol
522 and their respective responses, successful or otherwise.
524 +------------+------------------+-------------------+---------------+
525 | Operation | Request Message | Successful | Error |
526 | | | Response | Response |
527 +------------+------------------+-------------------+---------------+
528 | Request | locationRequest | PIDF-LO document | error |
529 | Location | (Section 4.2) | [RFC4119] | (Section 4.5) |
530 | | | | |
531 | Create | createContext | contextResponse | error |
532 | Context | (Section 4.3.1) | | (Section 4.5) |
533 | | | | |
534 | Update | updateContext | contextResponse | error |
535 | Context | (Section 4.3.2) | | (Section 4.5) |
536 +------------+------------------+-------------------+---------------+
538 Table 1: HELD Operations
540 A MIME type "application/held+xml" is registered in Section 10.5 to
541 distinguish HELD messages from other XML document bodies. This
542 specification follows the recommendations and conventions described
543 in [RFC3023], including the naming convention of the type ('+xml'
544 suffix) and the usage of the 'charset' parameter.
546 Section 5 contains a more thorough description of the protocol
547 parameters, valid values, and how each should be handled. Section 6
548 contains a more specific definition of the structure of these
549 messages in the form of an XML Schema [W3C.REC-xmlschema-1-20041028].
551 4.1. Protocol Binding
553 The HELD protocol is an application-layer protocol that is defined
554 independently of any lower layers. This means that any protocol can
555 be used to transport this protocol providing that it can provide a
556 few basic features:
558 o The protocol must have acknowledged delivery.
560 o The protocol must be able to correlate a response with a request.
562 o The protocol must provide authentication, privacy and protection
563 against modification.
565 Candidate protocols that could be used to address these purposes
566 include: TCP [RFC0793], TLS [RFC2246], SASL [RFC2222], HTTP
567 [RFC2616], SIP [RFC3261], BEEP [RFC3080] and SOAP
568 [W3C.REC-soap12-part1-20030624] [W3C.REC-soap12-part2-20030624].
569 This document includes a binding that uses a combination of HTTP, TLS
570 and TCP in Section 7.
572 4.2. Location Request
574 A location request is sent from the Device to the LG when it requires
575 LI. This request can be very simple, including no parameters; in
576 fact, the HTTP binding includes a GET request that does not include a
577 message body.
579 A Device MAY make an assertion about its own location as part of a
580 location request. Devices that have some means of acquiring LI,
581 either from embedded technology like Global Positioning System (GPS)
582 receivers or from user input, can use this to convey that information
583 to the LG. The "assert" element can be used to convey this
584 information.
586 The type of LI that a Device requests is determined by the type of LI
587 that is included in the "assert" element. When asserted LI is not
588 provided, the Device MAY specify the type of location requested using
589 the "locationType" element.
591 LI provided by the Device is potentially more precise than that
592 provided by the LG, therefore the LG MAY use this information to
593 create a response. The LG SHOULD validate the LI provided for
594 accuracy and precision before using this information.
596 The Device MAY specify a "profile" element that instructs the LG on
597 how to construct the LO. Alternatively, if the Device has created a
598 profile in an LS context, the Device can provide a "context" element
599 so that the LG can retrieve the profile from the LS.
601 The location request is made by sending a document formed of a
602 "locationRequest" element. The successful response to a location
603 request is a PIDF-LO document, unless the request fails, in which
604 case the LG SHOULD provide an error indication document.
606 4.3. Contexts
608 A context is established by the LS in order to provide a Location
609 URI. The context includes information necessary to identify the
610 Device and determine its location when an LR requests an LO using the
611 Location URI.
613 4.3.1. Creating Contexts
615 The Device uses the "createContext" message to request that the LG,
616 and the LS, assign a Location URI. This establishes a context at the
617 LS.
619 The LS MUST maintain the information provided in the create context
620 request. The create context request includes a time limit, which
621 sets the maximum time that this context can be maintained.
623 The response to a create context request contains information that
624 the Device can use to identify a context. A set of Location URIs are
625 included, each one MUST uniquely identify the context; that is, the
626 LS MUST be able to identify a context based on a single Location URI.
627 A Device can distribute a Location URI to an LR to allow it retrieve
628 LI from the LS.
630 A Location URI MUST NOT contain any information that could be used to
631 identify the Device or Target. It is RECOMMENDED that a Location URI
632 contain a public address for the LS and a random sequence of
633 characters that the LS can use to identify a particular context. The
634 presentity identifier included in a PIDF-LO document SHOULD NOT be
635 used for either part or the entirety of a Location URI.
637 The response to a create context request MUST include the time when
638 the LS will terminate the context. The LS MUST NOT respond to any
639 queries to the context beyond this time. A response to a context
640 creation also includes a password that the Device uses to identify
641 itself when updating the context at any time before the context
642 expiry time.
644 4.3.2. Updating Contexts
646 A Device can update any of the information it has provided for a
647 context at any time. The update context request includes the same
648 information as the create context request with the addition of
649 information that identifies an existing context.
651 A Device uses any one of the Location URIs provided to uniquely
652 identify a context when updating context information. The context
653 password MUST be provided when updating context information.
655 If a Device includes an authorization policy (or ruleset) in an
656 update context request, the LS MUST refresh any stored copy of the
657 authorization policy. This is especially important for authorization
658 policies that are provided by-reference; the LS MUST update the
659 authorization policy, even if the URI has not changed. Updated
660 authorization policies MUST be processed by the LG and LS before any
661 subsequent requests from LRs are accepted; the LG and LS MAY defer
662 processing of the authorization policy until after a response is sent
663 to the Device.
665 The update context request is constructed using the "updateContext"
666 element. A successful response is the "contextResponse" element,
667 which is the same as the response to a create context response.
669 The update context request can also indicate that data can be removed
670 by the context by specifying a _nil_ value for any of the parameters,
671 using the "xsi:nil" attribute. This applies to the profile
672 (Section 5.4) element.
674 The response to an update context request is identical in form to the
675 create context response, with updated information about the context.
676 The Location URIs MUST be the same as those in the response to the
677 initial create context request, but the password and expiry time MAY
678 be changed.
680 4.3.3. Terminating Contexts
682 The update context request can be used to instruct the LS to
683 terminate a context. The "lifetime" element in the request is set to
684 a zero duration. Once the context has been terminated, or it has
685 expired, Location URIs that reference that context can no longer be
686 used and the Device MUST NOT use the Location URIs or password
687 relating to that context.
689 The LS MAY terminate a context without notifying the Device. The LS
690 SHOULD terminate contexts if it, or the LG, detect that any
691 information relating to the Device changes in a way that invalidates
692 the context.
694 When the Device requests that a context be terminated, the LG
695 responds with a "contextResponse" message that does not include any
696 context information; this message MUST include the HELD "201"
697 response code.
699 4.4. Combined Context and Location Requests
701 HELD supports an optimization that allows for the creation or update
702 of a context while simultaneously requesting location information.
703 The optional "location" attribute on the "createContext" or
704 "updateContext" request can be used to request that the LG include a
705 PIDF-LO in the "contextResponse". This PIDF-LO is formed according
706 to the profile details associated with the context.
708 4.5. Indicating Errors
710 In the event of an error, the LG SHOULD respond to the Device with an
711 error document. The error response applies to all request types and
712 SHOULD also be sent in response to any unrecognized request.
714 An error indication document consists of an "error" element. The
715 "error" element MUST include a "code" attribute that indicates the
716 type of error. A set of predefined error codes are included in
717 Section 5.8.
719 Error responses MAY also include a "message" attribute that can
720 include additional information. This information SHOULD be for
721 diagnostic purposes only, and MAY be in any language. The language
722 of the message SHOULD be indicated with an "xml:lang" attribute.
724 5. Protocol Parameters
726 This section describes, in detail the parameters that are used for
727 this protocol. Table 2 lists the top-level components used within
728 the protocol and where they are used.
730 +------------------------+-------------+-------------+--------------+
731 | Parameter | Location | Create | Update |
732 | | Request | Context | Context |
733 +------------------------+-------------+-------------+--------------+
734 | responseTime | Request | Request | Request |
735 | (Section 5.1) | | | |
736 | | | | |
737 | assert (Section 5.2) | Request | | |
738 | | | | |
739 | exact (assert) | Request | | |
740 | (Section 5.2.4) | | | |
741 | | | | |
742 | locationType | Request | | |
743 | (Section 5.3) | | | |
744 | | | | |
745 | exact (locationType) | Request | | |
746 | (Section 5.3.1) | | | |
747 | | | | |
748 | profile (Section 5.4) | Request | Request | Request |
749 | | | | |
750 | signed (Section 5.5) | Request | | |
751 | | | | |
752 | lifetime (Section 5.6) | | Request | Request |
753 | | | | |
754 | rules (Section 5.7) | | Request | Request |
755 | | | | |
756 | code (Section 5.8) | Error | Error & | Error & |
757 | | | Response | Response |
758 | | | | |
759 | message (Section 5.9) | Error | Error & | Error & |
760 | | | Response | Response |
761 | | | | |
762 | context (Section 5.10) | Request | Response | Request & |
763 | | | | Response |
764 | | | | |
765 | location | | Request | Request |
766 | (Section 5.11) | | | |
767 +------------------------+-------------+-------------+--------------+
769 Table 2: Message Parameter Usage
771 5.1. "responseTime" Parameter
773 The "responseTime" attribute indicates to the LG how long the Device
774 is prepared to wait for a response. This attribute MAY be added to
775 any request message, although it is primarily used with the location
776 request. The value of this attribute is indicative only, the LG is
777 under no obligation to strictly adhere to the time limit implied; any
778 enforcement of the time limit is left to the Device.
780 This attribute MAY be either a duration value as defined in XML
781 Schema [W3C.REC-xmlschema-2-20041028], or a decimal seconds value,
782 which may include a decimal point. It is RECOMMENDED that systems
783 support millisecond precision for this parameter.
785 The LG SHOULD provide the most accurate LI that can be determined
786 within the specified interval. This parameter could be used as input
787 when selecting the method of location determination, where multiple
788 such methods exist. If this parameter is absent, then the LG SHOULD
789 return the most precise LI it is capable of determining.
791 5.2. "assert" Parameter
793 The "assert" element allows a Device to provide LI to the LG as part
794 of a location request. Two types of content are allowed: a geodetic
795 structure made up of a Geography Markup Language (GML) geometry
796 object, "_Geometry" as defined by [OGC.GML-3.1.1]; and a civic
797 address structure, "civicAddress" as defined by
798 [I-D.ietf-geopriv-revised-civic-lo]. The contents of this element
799 SHOULD follow the rules in [I-D.ietf-geopriv-pdif-lo-profile].
801 When used in combination with the "context" element, this LI MAY be
802 used by the LS for requests to Location URIs for that context.
804 This element is mutually exclusive with the "locationType" parameter,
805 defined in Section 5.3. The type of LI requested is implied by the
806 types included in the assertion.
808 5.2.1. "method" Parameter
810 The "method" attribute SHOULD be attached to the "assert" element to
811 indicate the means by which the LI was derived. This attribute
812 follows the rules of the similarly named method element of the
813 PIDF-LO.
815 5.2.2. "timestamp" Parameter
817 The "timestamp" attribute SHOULD be attached to the "assert" element
818 to indicate when the LI was generated.
820 5.2.3. "expires" Parameter
822 The "expires" attribute MAY be attached to the "assert" element to
823 indicate when the included LI is no longer valid. The LG SHOULD set
824 the "retention-expires" element in the returned PIDF-LO to no later
825 than this time if it uses the LI. This attribute SHOULD NOT be
826 included unless this time is definite.
828 5.2.4. "exact" Parameter
830 When the "exact" attribute is set to "true", it indicates to the LG
831 that the contents of the "assert" parameter MUST be strictly
832 followed. The default value of "false" allows the LG the option of
833 ignoring these values.
835 This attribute indicates that the asserted LI MUST be included in the
836 PIDF-LO response. If the LG cannot do this for any reason, which is
837 usually because it determines that the LI was inaccurate or
838 insufficiently precise, the LG MUST indicate an error.
840 5.3. "locationType" Parameter
842 The "locationType" element is included in a location request. It
843 contains a list of LI types that are requested by the Device. The
844 following list describes the possible values:
846 any: The LG SHOULD attempt to provide LI in all forms available to
847 it. This value MUST be assumed as the default if no
848 "locationType" is specified. The LG SHOULD return location
849 information in a form that is suited for routing and responding to
850 an emergency call in its jurisdiction.
852 geodetic: The LG SHOULD return a geodetic location for the Target.
854 civic: The LG SHOULD return a civic address for the Target. Any
855 type of civic address may be returned. The LG SHOULD ignore this
856 value if a request for jurisdictional or postal civic address has
857 been made and can be satisfied.
859 jurisdictionalCivic: The LG SHOULD return a jurisdictional civic
860 address for the Target.
862 postalCivic: The LG SHOULD return a postal civic address for the
863 Target.
865 The "locationType" element is mutually exclusive with the "assert"
866 element, defined in Section 5.2.
868 The LG SHOULD return the requested location type or types. The LG
869 MAY provide additional location types, or it MAY provide alternative
870 types if the request cannot be satisfied for a requested location
871 type. If the "exact" attribute is present and set to "true" in a
872 location request, then a successful LG response MUST provide the
873 requested location type only, with no additional location
874 information. The "exact" attribute has no effect when this element
875 is set to "any".
877 The "SHOULD"-strength requirement on this parameter is included to
878 allow for soft-failover. This enables a fixed client configuration
879 that prefers a specific location type without causing location
880 requests to fail when that location type is unavailable. Unless the
881 "exact" attribute is set, the LG MUST provide LI in any available
882 form if it is unable to comply with the request.
884 For example, a notebook computer could be configured to retrieve
885 civic addresses, which is usually available from typical home or work
886 situations. However, when using a wireless modem, the LG might be
887 unable to provide a civic address.
889 5.3.1. "exact" Parameter
891 When the "exact" attribute is set to "true", it indicates to the LG
892 that the contents of the "locationType" parameter MUST be strictly
893 followed. The default value of "false" allows the LG the option of
894 ignoring these values.
896 A value of "true" indicates that the LG MUST provide a PIDF-LO that
897 includes LI of the requested type or types. The LG MUST provide the
898 requested types only and these types SHOULD be specified in the same
899 order as they were requested. The LG SHOULD handle an exact request
900 that includes a "locationType" element set to "any" as if the "exact"
901 attribute were set to "false".
903 5.4. "profile" Parameter
905 The "profile" element contains a presentity identifier [RFC2778] and
906 GEOPRIV usage rules [RFC4119] information. All fields are optional
907 within this element, but when these fields are included, the LG MUST
908 use these parameters when constructing the PIDF-LO document.
910 This element MAY be included in location requests, create context
911 requests and update context requests. When included in a location
912 request, the profile is used immediately; when used in create context
913 or update context requests, the profile is stored on the LS and is
914 provided to the LG when the LS responds to requests from LRs.
916 5.4.1. "presentity" Parameter
918 The "presentity" element contains a presentity identifier that the LG
919 SHOULD include in the "pres" attribute of the PIDF-LO document.
921 The LG MAY require authentication of the presentity through any
922 means; the LG SHOULD ignore this parameter if authentication
923 information is not present or authentication information cannot be
924 verified.
926 5.4.2. "retentionExpiry" Parameter
928 The "retentionExpiry" element contains an absolute "dateTime"
929 [W3C.REC-xmlschema-2-20041028] value for the "retention-expires"
930 element of the PIDF-LO usage rules. This element is mutually
931 exclusive with the "retentionInterval" element.
933 The LG MAY use a different value than that specified (or the
934 suggested default) as circumstances dictate, but MUST NOT use a value
935 later than specified. If this value indicates a time that has
936 already passed, the request MUST be rejected with an error. See
937 retentionInterval (Section 5.4.3) for more details.
939 5.4.3. "retentionInterval" Parameter
941 The "retentionInterval" element contains a time duration value that
942 is specified in the same fashion as the responseTime attribute
943 (Section 5.1).
945 This value MUST be added to the time at which the PIDF-LO document is
946 created to set the value of the "retention-expires" element. This
947 element enables the Target to set an interval over which a LR can
948 retain a LO, rather than an absolute time. This element is mutually
949 exclusive with the "retentionExpires" element.
951 If neither "retentionExpiry" nor "retentionInterval" are specified,
952 the LG SHOULD provide a default value for the "retention-expires"
953 element of the generated PIDF-LO document. The default for this
954 value SHOULD be 24 hours from the receipt of the location request as
955 defined in [RFC4119].
957 The LG MAY use a different value than that specified (or the
958 suggested default) as circumstances dictate, but MUST NOT use a value
959 larger than specified.
961 5.4.4. "retransmission" Parameter
963 The "retransmission" element contains a boolean value that MUST be
964 included in the "retransmission-allowed" element of the generated
965 PIDF-LO usage rules. When this element is not provided, the LG MUST
966 set the "retransmission-allowed" element to "false".
968 5.4.5. "rulesetURI" Parameter
970 The "rulesetURI" element contains a URI value that MUST be included
971 in the "ruleset-reference" element of the generated PIDF-LO usage
972 rules.
974 This datum is only used to construct the usage rules in the PIDF-LO
975 document. Within the context of a profile, this ruleset is not
976 applied by either LG or LS, and the LS does not apply the rules found
977 at the URI.
979 5.5. "signed" Parameter
981 The "signed" attribute indicates whether the Device requires a
982 digitally signed PIDF-LO. When present and set to "true", the LG
983 MUST provide a PIDF-LO document that is signed according to
984 [I-D.thomson-geopriv-location-dependability].
986 5.6. "lifetime" Parameter
988 The "lifetime" element specifies the maximum time that a context
989 should be maintained by the LS. This parameter MUST be included in
990 the context creation request to indicate to the LS the latest time
991 that the context is allowed to be retained. The parameter MAY be
992 included in context update requests to modify this time; when
993 included in an update request with a zero value, it indicates that
994 the context MUST be removed immediately.
996 The "lifetime" element is a duration value that is specified in the
997 same fashion as the "responseTime" attribute.
999 This value MUST be added to the current time when received by the LS
1000 to determine the time at which the context expires. An LS MAY use
1001 any value less than or equal to this value, but MUST NOT use a longer
1002 value. The actual expiry time of the context MUST be indicated in
1003 the context response.
1005 5.7. "rules" Parameter
1007 The "rules" element contains the authorization policy of the Target
1008 that dictates how and to whom LI is provided by the LS. This policy
1009 MUST be applied by the LS when providing LI to LRs.
1011 Authorization policies MUST conform to
1012 [I-D.ietf-geopriv-common-policy]. If the authorization policy is
1013 invalid, cannot be retrieved, or is otherwise not understood by the
1014 LS, the LG SHOULD fail the request. Note that this implies that the
1015 LS SHOULD attempt to retrieve an authorization policy that is
1016 provided by-reference at the time of a create context request;
1017 however, an LS MAY choose to do this later, if the requested response
1018 time might be exceeded.
1020 In the absence of an authorization policy, the LS MUST NOT provide LI
1021 to any LR. Note that in certain jurisdictions an LS might be
1022 required to provide LI to specific parties irrespective of the
1023 authorization policy, as mandated by legislation; for example,
1024 emergency services in some countries.
1026 5.7.1. "rulesetURI" Parameter
1028 The "rulesetURI" element contains a URI that references the Target's
1029 authorization policy. This URI should reference a document of type
1030 "application/auth-policy+xml" as defined in
1031 [I-D.ietf-geopriv-common-policy].
1033 It is RECOMMENDED that a ruleset URI use the "https" scheme. It is
1034 anticipated that, to improve responsiveness and reduce network usage,
1035 an LS could cache an authorization policy, consistent with the rules
1036 specified by the Rule Holder. For instance, the Rule Holder could
1037 specified retention times using the "Expires" header in HTTP
1038 [RFC2616]. The impact of changes to authorization policies are
1039 discussed in Section 4.3.2.
1041 5.7.2. Common Policy "ruleset" Parameter
1043 The "ruleset" element, which is in the
1044 "urn:ietf:params:xml:ns:common-policy" namespace
1045 [I-D.ietf-geopriv-common-policy], allows for providing an
1046 authorization policy directly as part of a request.
1048 5.8. "code" Parameter
1050 All responses, except a PIDF-LO document, MUST contain a response
1051 code. The "code" attribute applies to the "error" and
1052 "contextResponse" messages.
1054 The following response codes follow a three decimal form similar to
1055 that in HTTP [RFC2616] and SIP [RFC3261]:
1057 200 (Success): This code indicates that the request was successful.
1058 This code MUST not be used for an error response.
1060 201 (Context Terminated): This code indicates that the request to
1061 terminate a context was successful.
1063 400 (Request Error): This code indicates that the request was badly
1064 formed in some fashion.
1066 401 (XML Error): This code indicates that the XML content of the
1067 request was either badly formed or invalid.
1069 402 (Authentication Error): This code indicates that the request
1070 either did not contain authentication information, or the
1071 authentication provided was not accepted.
1073 403 (Asserted Location Error): This code indicates that the LI that
1074 was asserted in the request was not acceptable to the LG. This
1075 code is used when the "exact" attribute on the "assert" parameter
1076 is set to "true".
1078 404 (Context Not Found): This code indicates that the context
1079 identified in the request was not found. This code MAY also be
1080 used if the password provided was incorrect.
1082 500 (General LG Error): This code indicates that an unspecified
1083 error occurred at the LG.
1085 501 (Location Unknown): This code indicates that the LG could not
1086 determine the location of the Device.
1088 502 (Unsupported Message): This code indicates that the request was
1089 not supported or understood by the LG.
1091 503 (Timeout): This code indicates that the LG could not satisfy the
1092 request within the time specified in the "requestTime" parameter.
1094 504 (Cannot Provide LI Type): This code indicates that the LG was
1095 unable to provide LI of the type or types requested. This code is
1096 used when the "exact" attribute on the "locationType" parameter is
1097 set to "true".
1099 Additional response codes within the x00 to x79 range MUST be
1100 specified in published RFCs; the range from x80 to x99 is reserved
1101 for private usage.
1103 5.9. "message" Parameter
1105 The "contextResponse" and "error" messages MAY include a "message"
1106 attribute to convey some additional, human-readable information about
1107 the result of the request. This message MAY be included in any
1108 language, which SHOULD be indicated by the "xml:lang", attribute.
1110 5.10. "context" Parameter
1112 The "context" element includes information that is used to identify a
1113 context and control access to it. The context is identified by one
1114 or more Location URIs and a Device is granted a password which MUST
1115 be provided when accessing the context to update the information
1116 contained.
1118 When a context is created, the LG provides a "contextResponse"
1119 message that contains the "context" element. This element contains
1120 all of the Location URIs that can be used for the context, a
1121 password, and an expiry time.
1123 To update the details in a context, or reuse profile information
1124 stored in the context, the Device provides a "context" element. When
1125 identifying a context in this manner, the Device MUST provide only
1126 one Location URI and the password.
1128 5.10.1. "locationURI" Parameter
1130 The "locationURI" element includes a single Location URI. Each
1131 Location URI is allocated by the LS so that it is able to uniquely
1132 identify the context.
1134 A "contextResponse" message contains any number of "locationURI"
1135 elements. It is RECOMMENDED that the LS allocate a Location URI for
1136 all schemes that it supports and that no scheme is present twice.
1138 All "updateContext" request messages MUST contain only one
1139 "locationURI" element, which is all that is necessary to uniquely
1140 identify a context. The Device MAY select any of the Location URIs
1141 provided by the LS. Location URIs do not change over the lifetime of
1142 a context.
1144 5.10.2. "password" Parameter
1146 The "password" element carries a password that is used to access the
1147 context after it has been created. The LS generates this value when
1148 creating a context and the Device MUST use the exact same value when
1149 it wishes to access the context. This value acts as a shared secret
1150 between Device and LS.
1152 The value of the password MAY be updated in the response to any
1153 "updateContext" message.
1155 This element MAY contain any valid XML character data, within the
1156 constraints of the XML Schema "token" type.
1158 5.10.3. "expires" Parameter
1160 The "expires" attribute indicates the time at which the context
1161 created by the LS will expire. This attribute is included in the
1162 "contextResponse" message only.
1164 Responses to create and update context requests MUST include the
1165 expiry time of the context. If the LS has expired a context in
1166 response to an update context request, this value SHOULD include a
1167 time in the past to avoid problems that could be caused by a slow
1168 clock in the Device.
1170 5.11. "location" Parameter
1172 The "location" parameter is a boolean attribute associated with the
1173 "createContext" or "updateContext" message. The default for this
1174 attribute is "false".
1176 This parameter, when present and set to "true" indicates that the LG
1177 SHOULD include a PIDF-LO document in the "contextResponse" message.
1178 The success of any request that includes this parameter MUST NOT be
1179 affected by any error in providing a location; thus, if the LG is
1180 unable to include a PIDF-LO, it is only omitted from the response.
1181 If a "contextResponse" does not include a PIDF-LO, the Device can
1182 determine the reasons for failure by sending a separate
1183 "locationRequest".
1185 Note: The schema does not include an explicit particle for the
1186 "presence" element. This is because the "any" construct used to
1187 allow for extensions would conflict with any optional element, due to
1188 the Unique Particle Attribution schema rule.
1190 6. XML Schema
1192 This section gives the XML Schema Definition
1193 [W3C.REC-xmlschema-1-20041028] of the "application/held+xml" format.
1194 This is presented as a formal definition of the "application/
1195 held+xml" format. Note that the XML Schema definition is not
1196 intended to be used with on-the-fly validation of the presence XML
1197 document.
1199
1200 Namespace for HELD Messages
2038 urn:ietf:params:xml:ns:geopriv:held
2039 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2040 with the RFC number for this specification.]]
2041
See RFCXXXX.
2042 2043 2044 END 2046 10.3. XML Schema Registration 2048 This section registers an XML schema as per the guidelines in 2049 [RFC3688]. 2051 URI: urn:ietf:params:xml:schema:geopriv:held 2053 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 2054 Martin Thomson (martin.thomson@andrew.com). 2056 Schema: The XML for this schema can be found as the entirety of 2057 Section 6 of this document. 2059 10.4. URN Sub-Namespace Registration for 2060 urn:ietf:params:xml:ns:geopriv:held:http 2062 This section registers a new XML namespace, 2063 "urn:ietf:params:xml:ns:geopriv:held:http", as per the guidelines in 2064 [RFC3688]. 2066 URI: urn:ietf:params:xml:ns:geopriv:held:http 2068 Registrant Contact: IETF, GEOPRIV working group, 2069 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2071 XML: 2073 BEGIN 2074 2075 2077 2078 2079See RFCXXXX.
2087 2088 2089 END 2091 10.5. MIME Media Type Registration for 'application/held+xml' 2093 This section registers the "application/held+xml" MIME type. 2095 To: ietf-types@iana.org 2097 Subject: Registration of MIME media type application/held+xml 2099 MIME media type name: application 2101 MIME subtype name: held+xml 2103 Required parameters: (none) 2105 Optional parameters: charset 2106 Indicates the character encoding of enclosed XML. Default is 2107 UTF-8. 2109 Encoding considerations: Uses XML, which can employ 8-bit 2110 characters, depending on the character encoding used. See RFC 2111 3023 [RFC3023], section 3.2. 2113 Security considerations: This content type is designed to carry 2114 protocol data related to the location of an entity, which could 2115 include information that is considered private. Appropriate 2116 precautions should be taken to limit disclosure of this 2117 information. 2119 Interoperability considerations: This content type provides a basis 2120 for a protocol 2122 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please 2123 replace XXXX with the RFC number for this specification.]] 2125 Applications which use this media type: Location information 2126 providers and consumers. 2128 Additional Information: Magic Number(s): (none) 2129 File extension(s): .xml 2130 Macintosh File Type Code(s): (none) 2132 Person & email address to contact for further information: Martin 2133 Thomson