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 1212 1213 1214 1216 This document defines HELD messages. 1217 1218 1220 1221 1222 1224 1225 1227 1228 1229 1230 1231 1232 1234 1235 1236 1239 1240 1241 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1270 1271 1272 1273 1274 1276 1277 1279 1281 1282 1284 1286 1288 1289 1290 1292 1293 1294 1295 1296 1297 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1322 1323 1324 1325 1327 1328 1329 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1347 1348 1349 1351 1352 1353 1354 1355 1356 1358 1359 1360 1361 1362 1363 1365 1366 1367 1369 1370 1371 1372 1373 1375 1377 1378 1379 1380 1382 1383 1384 1385 1386 1387 1388 1389 1391 1393 1395 1396 1398 1399 1400 1402 1404 1405 1406 1407 1408 1409 1411 1413 1414 1415 1416 1418 1421 1422 1423 1424 1425 1426 1427 1429 1432 1434 1436 1437 1439 1440 1441 1443 1445 1447 1448 1449 1450 1451 1452 1453 1455 1457 1458 1459 1460 1462 1463 1465 1466 1468 1469 1470 1472 1475 1477 7. HTTP Binding 1479 This section defines an HTTP [RFC2616] binding for this protocol, 1480 which all conforming implementations MUST support. This binding 1481 takes the form of a Web Service (WS) that can be described by the Web 1482 Services Description Language (WSDL) document in Section 7.1. 1484 The three request messages are carried in this binding as the body of 1485 an HTTP POST request. The MIME type of both request and response 1486 bodies should be "application/held+xml", except that a PIDF-LO 1487 document SHOULD have the MIME type "application/pidf+xml". 1489 The LG populates the HTTP headers so that they are consistent with 1490 the contents of the message. In particular, the "Expires" and cache 1491 control headers are used to control the caching of any PIDF-LO 1492 document. The HTTP status code SHOULD have the same first digit as 1493 any "contextResponse" or "error" body included, and it SHOULD 1494 indicate a 2xx series response when a PIDF-LO document is included. 1496 This binding also includes a default behaviour, which is triggered by 1497 a GET request, or a POST with no request body. If either of these 1498 queries are received, the LG MUST attempt to provide a PIDF-LO 1499 document, as if the request was a location request. 1501 This binding MUST use TLS as described in [RFC2818]. TLS provides 1502 message integrity and privacy between Device and LG. The LG MUST use 1503 the server authentication method described in [RFC2818]; the Device 1504 MUST fail a request if server authentication fails, except in the 1505 event of an emergency. 1507 7.1. HTTP Binding WSDL 1509 The following WSDL 2.0 [W3C.CR-wsdl20-20060106] document describes 1510 the HTTP binding for this protocol. Actual service instances MUST 1511 provide a "service" with at least one "endpoint" that implements the 1512 "heldHTTP" binding. A service description document MAY include this 1513 schema directly or by using the "import" or "include" directives. 1515 1516 1525 1526 This document describes the basic HELD web service. 1527 Please refer to RFCXXXX for details. 1528 [[NOTE TO RFC-EDITOR: Please replace XXXX with the RFC number 1529 for this specification and remove this note.]] 1530 1532 1533 1534 1536 1537 1538 1540 1542 1543 1544 1545 1546 1548 1549 1550 1551 1552 1554 1555 1556 1557 1558 1560 1563 1564 1565 1567 1569 1570 1574 1578 1583 1589 1591 1593 8. Security Considerations 1595 The threat model for this protocol assumes that the LG exists within 1596 the same administrative domain as the Device. The LG requires access 1597 to network information so that it can determine LI. Therefore, the 1598 LG can use network information to protect against a number of the 1599 possible attacks. 1601 Specific requirements and security considerations ofr location 1602 acquisition protocols provided in [I-D.ietf-geopriv-l7-lcp-ps]. 1604 An in-depth discussion of the security considerations applicable to 1605 the use of Location URIs and by-reference provision of LI is included 1606 in [I-D.marshall-geopriv-lbyr-requirements]. 1608 8.1. Return Routability 1610 It is RECOMMENDED that Location Generators use return routability 1611 rather than requiring Device authentication. Device authentication 1612 SHOULD NOT be required due to the administrative challenge of issuing 1613 and managing of client credentials, particularly when networks allow 1614 visiting users to attach devices. However, the LG MAY require any 1615 form of authentication as long as these factors are considered. 1617 Addressing information used in a request to the LG is used to 1618 determine the identity of the Device, and to address a response. 1619 This ensures that a Device can only request its own LI. 1621 A temporary spoofing of IP address could mean that a device could 1622 request a Location URI that would result in another Device's 1623 location. One or more of the follow approaches are RECOMMENDED to 1624 limit this exposure: 1626 o Location URIs SHOULD have a limited lifetime, that is, the LG 1627 SHOULD enforce a maximum value for the lifetime element 1628 (Section 5.6). 1630 o The network SHOULD have mechanisms that protect against IP address 1631 spoofing. 1633 o The LG SHOULD ensure that requests can only originate from within 1634 its administrative domain. 1636 o The LG and network SHOULD be configured so that the LG is made 1637 aware of Device movement within the network and addressing 1638 changes. If the LG and LS detect a change in the network that 1639 invalidates a context, the context MUST be terminated. 1641 The above measures are dependent on network configuration and SHOULD 1642 be considered with circumstances in mind. For instance, in a fixed 1643 internet access providers may be able to restriction the allocation 1644 of IP addresses to a single physical line, ensuring that spoofing is 1645 not possible; in such an environment, the other measures are not 1646 necessary. 1648 8.2. Transaction Layer Security 1650 All bindings for this protocol MUST ensure that messages are 1651 adequately protected against eavesdropping and modification. 1652 Bindings MUST also provide a means of authenticating the LG. 1654 It is RECOMMENDED that all bindings also use TLS [RFC2246]. 1656 For the HTTP binding, TLS MUST be used. TLS provides protection 1657 against eavesdropping and modification. The server authentication 1658 methods described in HTTP on TLS [RFC2818] MUST be used. 1660 8.3. Veracity of Asserted LI 1662 The assert element (Section 5.2) allows a Device the ability to 1663 provide LI. However, if an LG uses asserted LI, it is the LG that 1664 becomes responsible for the veracity of that information. Therefore, 1665 when the Device provides LI in a request, the LG MUST NOT use this 1666 information unless it can ensure its accuracy. This prevents the 1667 fraudulent provision of LI that could be caused by the LG accepting 1668 LI without any checks. 1670 It is unlikely that an LG is able to verify Device-provided LI beyond 1671 any uncertainty. The ability of an LG to verify LI is limited by its 1672 own capacity to determine the location of the Device. The LG SHOULD 1673 indicate the source of LI using the PIDF-LO "method" parameter so 1674 that users of LI can make appropriate judgments on its veracity. 1676 9. Examples 1678 9.1. Simple HTTP Binding Example Messages 1680 The examples in this section show a complete HTTP message that 1681 includes the HELD request or response document. 1683 This example shows the most basic request for a LO. This uses the 1684 GET feature described by the HTTP binding. This example assumes that 1685 the LG service exists at the URL "https://lg.example.com/location". 1687 GET /location HTTP/1.1 1688 Host: lg.example.com 1689 Accept: application/pidf+xml,application/held+xml,application/xml;q=0.8, 1690 text/xml;q=0.7 1691 Accept-Charset: UTF-8,* 1693 The GET request is exactly identical to a minimal POST request that 1694 includes an empty "locationRequest" element. 1696 POST /location HTTP/1.1 1697 Host: lg.example.com 1698 Accept: application/pidf+xml,application/held+xml,application/xml;q=0.8, 1699 text/xml;q=0.7 1700 Accept-Charset: UTF-8,* 1701 Content-Type: application/held+xml 1702 Content-Length: 87 1704 1705 1706 The successful response to either of these requests is a PIDF-LO 1707 document. The following response shows a minimal PIDF-LO response. 1709 HTTP/1.x 200 OK 1710 Server: Example LG 1711 Date: Tue, 10 Jan 2006 03:42:29 GMT 1712 Expires: Tue, 10 Jan 2006 03:42:29 GMT 1713 Cache-control: private 1714 Content-Type: application/pidf+xml 1715 Content-Length: 594 1717 1718 1720 1721 1722 1723 1724 1726 -34.407 150.88001 1727 1728 1729 1730 1731 2006-01-11T03:42:28+00:00 1732 1733 1734 1735 2006-01-10T03:42:28+00:00 1736 1737 1739 The error response to either of these requests is an error document. 1740 The following response shows an example error response. 1742 HTTP/1.x 500 Server Error 1743 Server: Example LG 1744 Date: Tue, 10 Jan 2006 03:49:20 GMT 1745 Expires: Tue, 10 Jan 2006 03:49:20 GMT 1746 Cache-control: private 1747 Content-Type: application/held+xml 1748 Content-Length: 135 1750 1751 1754 Note: To focus on important portions of messages, all examples 1755 following this note do not show HTTP headers or the XML prologue. 1756 In addition, sections of XML not relevant to the example are 1757 replaced with comments. 1759 9.2. Location Request Examples 1761 The location request shown below specifies location types and 1762 provides a profile that the LG applies to the PIDF-LO document. The 1763 request specifies that a response is desired within 10.5 seconds. 1765 1767 1768 jurisdictionalCivic 1769 geodetic 1770 1771 1772 pres:user@example.com 1773 1800 1774 false 1775 https://example.com/~user/ruleset.xml 1776 1777 1778 The response to this location request is the following PIDF-LO 1779 document, which shows how the profile values are applied. 1781 1783 1784 1785 1786 1787 1789 1790 1791 1792 1793 1794 1795 1796 false 1797 1798 2006-01-11T03:42:28+00:00 1799 1800 https://example.com/~user/ruleset.xml 1801 1802 1803 1804 1805 2006-01-10T03:42:28+00:00 1806 1807 1808 The following location request includes a location assertion that 1809 includes a user-provided civic address. This message also requests 1810 that the LG retrieve profile information from a context that exists 1811 on an LS. 1813 1815 1816 1819 1820 1821 1822 1823 1824 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 1825 1826 vs76e8cae9873a079888p9y4txwa 1827 1828 1830 Since this request includes the "exact" parameter set to "true", any 1831 successful response MUST include the provided LI. 1833 9.3. Context Creation and Update Examples 1835 The following create context request shows the simplest form of this 1836 message, which sets a two hour lifetime on the context and includes a 1837 "rulesetURI" element for the LS. 1839 1840 PT2H 1841 1842 1843 https://www.example.com/~user/privacy/ruleset.xml 1844 1845 1846 1847 The following more complex create context request includes additional 1848 information. This includes a profile that sets the presentity and 1849 some of the "usage-rules" components in the PIDF-LO that the LS 1850 serves. 1852 1853 PT2H 1854 1855 pres:user@example.com 1856 2006-01-13T12:00:00+00:00 1857 false 1858 1859 1860 1861 https://www.example.com/~user/privacy/ruleset.xml 1862 1863 1864 1866 A typical successful response to this message provides several 1867 Location URIs in different schemes (in this case: "https" and 1868 "sips"), the exact context expiry time, and a password that can be 1869 used to update the context. 1871 1873 1874 1875 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 1876 1877 1878 sips://ls.example.com:9769/357yc6s64ceyoiuy5ax3o 1879 1880 38cdj38mjcd-0-=54821kj28mp1qms.1 1881 1882 1884 If any aspect of the data stored in a context changes, a 1885 "contextUpdate" request is sent to the LG to request that it update 1886 the information. This request includes the information necessary to 1887 access a context (the location URI and password) and only the 1888 information that has changed. 1890 The following request demonstrates how information stored in a 1891 context could be updated. For the context previously created, this 1892 provides the "retentionInterval" element, which overrides a 1893 previously configured "retentionExpiry" value. 1895 1897 1898 1899 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 1900 1901 38cdj38mjcd-0-=54821kj28mp1qms.1 1902 1903 1904 600 1905 1906 1908 To indicate success, the LG provides a "contextResponse" identical in 1909 form to the original request. 1911 The following request shows that a context lifetime can be extended 1912 or shortened by the Device by updating a context with a new 1913 "lifetime" element. The following message requests that the LS 1914 maintain the context for two hours beyond the current time. 1916 1917 1918 1919 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 1920 1921 38cdj38mjcd-0-=54821kj28mp1qms.1 1922 1923 PT2H 1924 1925 The response to a request to extend the context includes the new 1926 expiry time of the context, if it has changed. 1928 1930 1931 1932 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 1933 1934 1935 sips://ls.example.com:9769/357yc6s64ceyoiuy5ax3o 1936 1937 38cdj38mjcd-0-=54821kj28mp1qms.1 1938 1939 1941 A zero value for the "lifetime" element terminates the context. The 1942 following request terminates the context. 1944 1945 1946 1947 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 1948 1949 38cdj38mjcd-0-=54821kj28mp1qms.1 1950 1951 PT0S 1952 1954 The response to a message that requests the termination of a context 1955 appears as follows. 1957 1960 9.4. Sample LG WSDL Document 1962 The following WSDL document demonstrates how a WSDL document can be 1963 created for a specific service, in this case, a service at the URI 1964 "https://lg.example.com/location". 1966 1967 1972 1975 1976 1979 1981 1983 10. IANA Considerations 1985 According to the guidelines in [RFC3688], this document calls for an 1986 IANA registry for result codes and registers an XML namespace and 1987 schema. It also registers the "application/held+xml" MIME type. 1989 10.1. IANA Registry for HELD Result Codes 1991 IANA will establish and maintain a registry of HELD result codes. 1992 Additional values are registered based on the "specification 1993 required" option in [RFC3688]. 1995 Specifications MUST specify the following information when 1996 registering new values in this registry: 1998 Code Value: A three-digit value from 000 to 679. The last 20 codes 1999 in each block of 100 (from x80 to x99) are reserved for private or 2000 experimental use and cannot be registered. 2002 Short Message: A brief message that describes the general reason for 2003 the code. 2005 Publication: A reference to any relevant publication or 2006 specification. 2008 Description and Usage: A longer description of the code and the 2009 circumstances where it applies. This description does not need to 2010 be exhaustive. 2012 The values in Section 5.8 are pre-registered in this registry. 2014 10.2. URN Sub-Namespace Registration for 2015 urn:ietf:params:xml:ns:geopriv:held 2017 This section registers a new XML namespace, 2018 "urn:ietf:params:xml:ns:geopriv:held", as per the guidelines in 2019 [RFC3688]. 2021 URI: urn:ietf:params:xml:ns:geopriv:held 2023 Registrant Contact: IETF, GEOPRIV working group, 2024 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2026 XML: 2028 BEGIN 2029 2030 2032 2033 2034 HELD Messages 2035 2036 2037

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 2079 HELD HTTP Binding WS 2080 2081 2082

Namespace for HELD HTTP Binding WS

2083

urn:ietf:params:xml:ns:geopriv:held:http

2084 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2085 with the RFC number for this specification.]] 2086

See 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 2135 Intended usage: LIMITED USE 2137 Author/Change controller: This specification is TBD 2139 Other information: This media type is a specialization of 2140 application/xml [RFC3023], and many of the considerations 2141 described there also apply to application/held+xml. 2143 11. Acknowledgements 2145 The authors would like to thank the following people for their 2146 contribution to this document (in alphabetical order): Nadine Abbott, 2147 Guy Caron, Martin Dawson, Jerome Grenier, Neil Justusson, Tat Lam, 2148 Patti McCalmont, Perry Prozeniuk, John Schnizlein, Henning 2149 Schulzrinne, Ed Shrum, and Hannes Tschofenig. 2151 12. References 2153 12.1. Normative References 2155 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2156 Requirement Levels", BCP 14, RFC 2119, March 1997. 2158 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 2159 RFC 2246, January 1999. 2161 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2162 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2163 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2165 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2167 [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 2168 Language) XML-Signature Syntax and Processing", RFC 3275, 2169 March 2002. 2171 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2172 January 2004. 2174 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 2175 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 2177 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 2178 Format", RFC 4119, December 2005. 2180 [I-D.ietf-geopriv-revised-civic-lo] 2181 Thomson, M. and J. Winterbottom, "Revised Civic Location 2182 Format for PIDF-LO", 2183 draft-ietf-geopriv-revised-civic-lo-05 (work in progress), 2184 February 2007. 2186 [I-D.ietf-geopriv-pdif-lo-profile] 2187 Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification, 2188 Considerations and Recommendations", 2189 draft-ietf-geopriv-pdif-lo-profile-05 (work in progress), 2190 October 2006. 2192 [I-D.thomson-geopriv-lis-discovery] 2193 Thomson, M. and J. Winterbottom, "Discovering the Local 2194 Location Information Server (LIS)", 2195 draft-thomson-geopriv-lis-discovery-00 (work in progress), 2196 February 2007. 2198 [I-D.marshall-geopriv-lbyr-requirements] 2199 Marshall, R., "Requirements for a Location-by-Reference 2200 Mechanism used in Location Configuration and Conveyance", 2201 draft-marshall-geopriv-lbyr-requirements-00 (work in 2202 progress), February 2007. 2204 [I-D.ietf-geopriv-l7-lcp-ps] 2205 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 2206 Location Configuration Protocol; Problem Statement and 2207 Requirements", draft-ietf-geopriv-l7-lcp-ps-00 (work in 2208 progress), January 2007. 2210 [I-D.ietf-geopriv-common-policy] 2211 Schulzrinne, H., "Common Policy: A Document Format for 2212 Expressing Privacy Preferences", 2213 draft-ietf-geopriv-common-policy-11 (work in progress), 2214 August 2006. 2216 [W3C.REC-xmlschema-2-20041028] 2217 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 2218 Second Edition", World Wide Web Consortium 2219 Recommendation REC-xmlschema-2-20041028, October 2004, 2220 . 2222 [OGC.GML-3.1.1] 2223 Cox, S., Daisey, P., Lake, R., Portele, C., and A. 2224 Whiteside, "Geographic information - Geography Markup 2225 Language (GML)", OpenGIS 03-105r1, April 2004, 2226 . 2229 [NENA_TID] 2230 National Emergency Number Association (NENA), "NENA 2231 Recommended Method(s) for Location Determination to 2232 Support IP-Based Emergency Services Technical Information 2233 Document", NENA VoIP Location Working Group 08-505 Issue 2234 1, December 2006, 2235 . 2237 [I-D.thomson-geopriv-location-dependability] 2238 Thomson, M. and J. Winterbottom, "Digital Signature 2239 Methods for Location Dependability", February 2007. 2241 12.2. Informative References 2243 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2244 RFC 793, September 1981. 2246 [RFC2222] Myers, J., "Simple Authentication and Security Layer 2247 (SASL)", RFC 2222, October 1997. 2249 [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for 2250 Presence and Instant Messaging", RFC 2778, February 2000. 2252 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 2253 Types", RFC 3023, January 2001. 2255 [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", 2256 RFC 3080, March 2001. 2258 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2259 A., Peterson, J., Sparks, R., Handley, M., and E. 2260 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2261 June 2002. 2263 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2264 Resource Identifier (URI): Generic Syntax", STD 66, 2265 RFC 3986, January 2005. 2267 [W3C.REC-xmlschema-1-20041028] 2268 Maloney, M., Thompson, H., Mendelsohn, N., and D. Beech, 2269 "XML Schema Part 1: Structures Second Edition", World Wide 2270 Web Consortium Recommendation REC-xmlschema-1-20041028, 2271 October 2004, 2272 . 2274 [W3C.REC-soap12-part1-20030624] 2275 Mendelsohn, N., Gudgin, M., Moreau, J., Hadley, M., and H. 2276 Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", 2277 World Wide Web Consortium Recommendation REC-soap12-part1- 2278 20030624, June 2003, 2279 . 2281 [W3C.REC-soap12-part2-20030624] 2282 Gudgin, M., Hadley, M., Nielsen, H., Moreau, J., and N. 2283 Mendelsohn, "SOAP Version 1.2 Part 2: Adjuncts", World 2284 Wide Web Consortium Recommendation REC-soap12-part2- 2285 20030624, June 2003, 2286 . 2288 [W3C.CR-wsdl20-20060106] 2289 Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, 2290 "Web Services Description Language (WSDL) Version 2.0 Part 2291 1: Core Language", W3C CR CR-wsdl20-20060106, 2292 January 2006. 2294 [I-D.winterbottom-geopriv-held-identity-extensions] 2295 Winterbottom, J. and M. Thomson, "HELD End-Point identity 2296 Extensions", 2297 draft-winterbottom-geopriv-held-identity-extensions-00 2298 (work in progress), October 2006. 2300 [I-D.thomson-geopriv-held-capabilities] 2301 Thomson, M. and J. Winterbottom, "Device Capability 2302 Negotiation for Device-Based Location Determination and 2303 Location Measurements in HELD", 2304 draft-thomson-geopriv-held-capabilities-01 (work in 2305 progress), February 2007. 2307 [I-D.thomson-geopriv-held-beep] 2308 Thomson, M. and J. Winterbottom, "A BEEP Binding for the 2309 HELD Protocol", February 2007. 2311 Appendix A. HELD Compliance to IETF LCP requirements 2313 This appendix describes HELD's compliance to the requirements 2314 specified in the [I-D.ietf-geopriv-l7-lcp-ps]. In addition to the 2315 LCP requirements specified by the IETF, HELD has independently been 2316 assessed against and found to comply with all the NENA requirements 2317 for a location acqusition protocol defined in [NENA_TID]. 2319 A.1. L7-1: Identifier Choice 2321 "The LIS MUST be presented with a unique identifier of its own 2322 addressing realm associated in some way with the physical location of 2323 the end host." 2325 COMPLY 2327 The identifier used may be the source address of the request packet 2328 and/or additional client identifier values relevant to the scope of 2329 the access network provided within the request. Mapping an IP 2330 address into lower-level attachment data is access network dependent 2331 and is the responsibility the LIS. HELD can however be used to 2332 provide assistence to the LIS through the inclusion of identity 2333 extensions such as those defined in 2334 [I-D.winterbottom-geopriv-held-identity-extensions]. 2336 A.2. L7-2: Mobility Support 2338 "The GEOPRIV Layer 7 Location Configuration Protocol MUST support a 2339 broad range of mobility from devices that can only move between 2340 reboots, to devices that can change attachment points with the impact 2341 that their IP address is changed, to devices that do not change their 2342 IP address while roaming, to devices that continuously move by being 2343 attached to the same network attachment point." 2345 COMPLY 2347 Mobility support is inherently a characteristic of the access network 2348 technology and HELD is designed to be access network agnostic. 2349 Consequently HELD complies with this requirement. In addition HELD 2350 provides specific support for mobile environments by providing an 2351 optional responseTime attribute in location request messages. 2352 Wireless networks often have several different mechanisms at their 2353 disposal for position determination (e.g. Assisted GPS versus 2354 location based on serving base station identity), each providing 2355 different degrees of accuracy and taking different amounts of time to 2356 yield a result. The responseTime parameter provides the LIS with a 2357 criterion which it can use to select a location determination 2358 technique. 2360 HELD also supports an extension mechanism that allows location 2361 measurement capabilities to be exchanged between the end-point and 2362 the LIS. This mechanism allows for a greater number of location 2363 determination techniques to be used by both the end-point and the 2364 LIS. The specification describing this capability is provided in 2365 [I-D.thomson-geopriv-held-capabilities]. 2367 A.3. L7-3: Layer 7 and Layer 2/3 Provider Relationship 2369 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 2370 MUST NOT assume a business or trust relationship between the provider 2371 of application layer (e.g., SIP, XMPP, H.323) provider and the access 2372 network provider operating the LIS." 2374 COMPLY 2376 HELD describes a location acquisition protocol and has no 2377 dependencies on how location is used once it has been acquired. 2378 Location acquisition using HELD is subject to the restrictions 2379 described in Section 8. 2381 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship 2383 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 2384 MUST assume that there is a trust and business relationship between 2385 the L2 and the L3 provider. The L3 provider operates the LIS and 2386 needs to obtain location information from the L2 provider since this 2387 one is closest to the end host. If the L2 and L3 provider for the 2388 same host are different entities, they cooperate for the purposes 2389 needed to determine end system locations." 2391 COMPLY 2393 HELD was specifically designed with this model in mind and readily 2394 allows itself to chaining requests between operators without a change 2395 in protocol being required. Examples of how HELD can be used in this 2396 manner are provided in detail in [NENA_TID]. HELD is a webservices 2397 protocol it can be bound to transports other than HTTP, for example a 2398 BEEP binding for HELD, [I-D.thomson-geopriv-held-beep]. Using a 2399 transport like BEEP for HELD offers the option of high request 2400 throughput over a dedicated connection between an L3 provider and an 2401 L2 provider without incurring the serial restriction imposed by HTTP. 2402 This is less easy to do with protocols that do not decouple 2403 themselves from the transport. 2405 A.5. L7-5: Legacy Device Considerations 2407 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 2408 MUST consider legacy residential NAT devices and NTEs in an DSL 2409 environment that cannot be upgraded to support additional protocols, 2410 for example to pass additional information through DHCP." 2412 COMPLY 2414 HELD is an application protocol and operates on top of IP. A HELD 2415 request from a host behind a residential NAT will traverse the NAT 2416 acquiring the external address of the home router. The location 2417 provided to the host therefore will be the address of the home router 2418 in this circumstance. No changes are required to the home router in 2419 order to support this function, HELD was designed specifically to 2420 address this deployment scenario. Examples of how HELD can be used 2421 in this type of network environment are provided in [NENA_TID]. 2423 A.6. L7-6: VPN Awareness 2425 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 2426 MUST assume that at least one end of a VPN is aware of the VPN 2427 functionality. In an enterprise scenario, the enterprise side will 2428 provide the LIS used by the client and can thereby detect whether the 2429 LIS request was initiated through a VPN tunnel." 2431 COMPLY 2433 HELD does not preclude a LIS on the far end of a VPN tunnel being 2434 aware that the client request is occurring over that tunnel. It also 2435 does not preclude a client device from accessing a LIS serving the 2436 local physical network and subsequently using the location 2437 information with an application that is accessed over a VPN tunnel. 2439 A.7. L7-7: Network Access Authentication 2441 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 2442 MUST NOT assume prior network access authentication." 2444 COMPLY 2446 HELD makes no assumptions about prior network access authentication. 2447 HELD strongly recommends the use of TLS with server-side certificates 2448 for communication between the end-point and the LIS. There is no 2449 requirement for the end-point to authenticate with the LIS. 2451 A.8. L7-8: Network Topology Unawareness 2453 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 2454 MUST NOT assume end systems being aware of the access network 2455 topology. End systems are, however, able to determine their public 2456 IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP." 2458 COMPLY 2460 HELD makes no assumption about the network topology. HELD doesn't 2461 require that the device know its external IP address, except where 2462 that is required for discovery of the LIS. LIS disocvery techniques 2463 available to a HELD client are described in 2464 [I-D.thomson-geopriv-lis-discovery]. In certain network environments 2465 an end-point maybe able to ascertain information about the topology 2466 of the access network which may assist the LIS in location 2467 determination. HELD provides support for extensions that allow this 2468 information to be communicated to the LIS when it is available. 2470 Appendix B. HELD Compliance to NENA Location Acqusition Requirements 2472 This section details how HELD complies to each of the requirements 2473 provided in section 4 of [NENA_TID]. 2475 B.1. DA1 2477 "The access network shall provide a mechanism for determination and 2478 acquisition of location information, and support queries for 2479 location." 2481 COMPLY 2483 HELD provides location acqusition functionality. A LIS may use any 2484 means to obtain measurements from the network to assist with location 2485 determination. 2487 B.2. DA2 2489 "The location estimate used shall be that associated with the 2490 physically (wire, fiber, air) connected network." 2492 COMPLY 2494 HELD is designed to support the acquisition of location information 2495 determined on the basis of the physical access network with which the 2496 device is associated. HELD does not preclude any specific technology 2497 used by that access. 2499 B.3. DA3 2501 "Location may be requested at any time. Location information must be 2502 associated with the device at the time the location is requested." 2504 COMPLY 2506 HELD location requests can be made at any time to the identified LIS 2507 serving the access network. It is the responsibility of the LIS to 2508 use the IP address and/or other identifiers included in the location 2509 request and determine the current location of the Target. Where more 2510 than one determination technology is available, the requesting entity 2511 may specify a response time to assist the LIS in selecting the 2512 appropriate location determination technology to use. The HELD 2513 protocol does not impose any physical constraints that prevent the 2514 LIS from reassessing the location at the time of each request. 2516 B.4. DA4 2518 "Location acquisition should be provided by a consistent method 2519 across all network configurations." 2521 COMPLY 2523 HELD requires an end-point to be able to discover the LIS in the 2524 local access network. Once the LIS is known HELD is access network 2525 agnostic and can be used in the same way in any network topology. 2527 B.5. DA5 2529 "Location determination and acquisition mechanisms must be applicable 2530 to emergency calling, and may also be applicable to a wide range of 2531 value-added location-based services." 2533 COMPLY 2535 HELD has specific semantics defined for obtaining locations suitable 2536 for routing emergency calls. In particular, HELD provides a rich set 2537 of location request options so that an application can retrieve 2538 location information in the form most suitable for its purpose. 2540 B.6. DA6 2542 "Location determination and acquisition techniques shall support both 2543 NENA i2 and i3 network architectures." 2545 COMPLY 2547 HELD provides all of the functions necessary to support emergency 2548 calling applications. HELD has a specific semantic for requesting 2549 location information suitable to inclusion in emergency calling 2550 applications. Location information acquired using HELD is contained 2551 in a PIDF-LO the form required by both the NENA i2 and i3 2552 architectures. It also supports location by reference mechanisms for 2553 out-of-band mid-call location updates as required, for example, for 2554 mobile wireless networks. 2556 B.7. DA7 2558 "When measurement based-location determination mechanisms fail, the 2559 most accurate location information available should be provided. 2560 Examples include: For mobile, the Wireless Service Provider might 2561 provide tower or Access Point location, last known fix, etc. For 2562 wireline, a LIS might provide a civic location that defines the 2563 serving area of an access point, e.g., the State of Texas." 2564 Not Applicable 2566 HELD is a location acqusition protocol and will return the location 2567 determined by the LIS. HELD does not preclude the LIS from applying 2568 any arbitrarily sophisticated set of location determination 2569 techniques and associated fallback policy appropriate to the access 2570 technology it supports. 2572 B.8. DA8 2574 "Location determination and acquisition must provide minimal impact 2575 to call setup time in the event that location is not known ahead of 2576 time." 2578 COMPLY 2580 HELD allows a location to be requested at any time, including prior 2581 to or during a call. Where time is of the essence the requesting 2582 entity can provide a response time indicating to the LIS that 2583 location is needed in the period specified. This allows the LIS to 2584 select the most accurate location determination technology available 2585 to it that can yield a location in the allotted time. This is of 2586 particular importance in wireless networks where the most accurate 2587 location determination techniques may take 10s of seconds. 2589 B.9. DA9 2591 "Where a device is not location aware the IP Access network should 2592 have the ability to provide a location estimate on behalf of the 2593 device." 2595 COMPLY 2597 In order to support this functionality the requesting node must have 2598 a pre-existing trust relationship with the LIS, and HELD identity 2599 extensions as described in 2600 [I-D.winterbottom-geopriv-held-identity-extensions]. Where these 2601 requirements are satisfied, the LIS may provide a HELD response to 2602 the requesting device that has the same form as if the target device 2603 had been the requestor. If the traffic volume between the trusted 2604 node and the LIS is likely to be high, the HELD BEEP binding 2605 [I-D.thomson-geopriv-held-beep] may be used. 2607 B.10. DA10 2609 "Location acquisition methods should not require modification of 2610 hardware/firmware in home-routers or modems." 2611 COMPLY 2613 This requirement is essentially the same as Appendix A.5. HELD is an 2614 application protocol and operates on top of IP. A HELD request from 2615 a host behind a residential NAT will traverse the NAT acquiring the 2616 external address of the home router. The location provided to the 2617 host therefore will be the address of the home router in this 2618 circumstance. No changes are required to the home router in order to 2619 support this function, HELD was designed specifically to address this 2620 deployment scenario. 2622 B.11. DA11 2624 "A location determination method must exist that does not require 2625 network hardware replacement." 2627 Not Applicable 2629 HELD is a location acquisition protocol and does not directly specify 2630 how location is determined in the network. However, HELD does not 2631 require additions to or replacement of existing network server 2632 implementations because it is not defined as an extension to any 2633 existing non-location service protocol. 2635 B.12. DA12 2637 "The location acquisition protocol shall allow the requesting device 2638 to specify a response time requirement to the LIS when requesting 2639 location information. The response time is expressed as the maximum 2640 time that the requesting node is prepared to wait for location 2641 information. The LIS is required to provide the most accurate 2642 location fix it can within the specified response time." 2644 COMPLY 2646 HELD has an explicit "responseTime" parameter that can be used with 2647 any request to the LIS. This parameter provides an indication to the 2648 LIS of how long the requesting node is prepared to wait for location, 2649 allowing the LIS to select the appropriate location determination 2650 technology to invoke particularly where it may need to trade off the 2651 accuracy of the result to meet the time constraint. 2653 B.13. Rep1 2655 "Location information may be provided as location-by-value or 2656 location-by-reference and the form is subject to the nature of the 2657 request." 2658 COMPLY 2660 HELD supports requesting either a location reference in the form a 2661 location URI and/or a literal location. Literal locations are 2662 provided as a PIDF-LO. 2664 B.14. Rep2 2666 "Location determination and acquisition mechanisms must support all 2667 location information fields defined within a PIDF-LO." 2669 COMPLY 2671 HELD provides location information in the form of a PIDF-LO, 2672 consequently all PIDF-LO fields are implicitly supported. 2674 B.15. Rep3 2676 "Location acquisition mechanisms must allow for easy backwards 2677 compatibility as the representation of location information evolves." 2679 COMPLY 2681 HELD provides location as a PIDF-LO, any changes made to the PIDF-LO 2682 definition are made independently and without impact to the HELD 2683 definition. 2685 B.16. Rep4 2687 "All representations of location shall include the ability to carry 2688 altitude and/or floor designation. This requirement does not imply 2689 altitude and/or floor designation is always used or supplied." 2691 COMPLY 2693 The PIDF-LO has explicit support for both civic and geodtic location 2694 types and consequently provides support for encoding both altitude 2695 and building floor values. Since HELD provides location as a 2696 PIDF-LO, any location that can be expressed in a PIDF-LO is 2697 compatible with HELD. HELD recommends that PIDF-LOs be constructed 2698 in accordance with the rules laid out in 2699 [I-D.ietf-geopriv-pdif-lo-profile]. 2701 B.17. LocSec1 2703 "Location information shall only be provided to authenticated and 2704 authorized network devices. The degree of authentication and 2705 authorization required may vary depending on the network." 2706 COMPLY 2708 A LIS generally authenticates a Target using HELD to request its own 2709 location implicitly. Authentication is based on the IP address of 2710 the source request packet, inband indentifiers, and return 2711 routability. Where this level of authentication is not deemed 2712 sufficient other authentications mechanisms can be used, such as 2713 client-side certificates, shared-secret keys and HTTP digest. 2715 B.18. LocSec2 2717 "Location determination and acquisition methods should preserve 2718 privacy of location information, subject to local laws and 2719 regulations." 2721 COMPLY 2723 This requirement is of particular significance where the acqusition 2724 protocol is also being used as a dereference protocol for a location 2725 URI. HELD supports this function by allowing a Target to provide 2726 access rules to the LIS. The Target may provide either an explicit 2727 set of rules defined using common policy syntax as described in 2728 [I-D.ietf-geopriv-common-policy], or the Target may provide a ruleset 2729 URI allowing the LIS to retrieve the ruleset from a third-party. LIS 2730 operators are also able to provide a default set of overiding 2731 policies to support, for example, emergency services. How these 2732 additional rules are provisioned and applied is a matter of LIS 2733 implementation and is outside the scope of any location acquisition 2734 protocol. 2736 B.19. LocSec3 2738 "The location or location estimate of a caller should be dependable." 2740 COMPLY 2742 HELD supports this through two mechanisms. The first is a "signed" 2743 attribute that can be included with a location request. This allows 2744 the user to explicitly request a signed location object. The second 2745 is through location assertion. This allows an end-point to proffer a 2746 location to the LIS, and for the LIS to assert this location against 2747 the location that the LIS would provide. The assert function is 2748 described in more detail in Section 5.2. 2750 B.20. LocSec4 2752 "The location acquisition protocol must support authentication of the 2753 Location Information Server, integrity protection of the Location 2754 Information, and protection against replay." 2756 COMPLY 2758 HELD recommends the use of TLS with server-side certificates for LIS 2759 authentication to requesting nodes where considered necessary. TLS 2760 when used in this fashion mitigates the risks of impersonation of the 2761 LIS. TLS also provides confidentiality and replay protection for 2762 requests and location information. 2764 B.21. LocSec5 2766 "The location source shall be identified and should be authenticated. 2767 This includes manually entered location." 2769 COMPLY 2771 HELD provides a "signed" attribute that can be used to request a 2772 signed location object as described in Section 5.5. For Target 2773 provided locations, be for manually entered or device-determined 2774 location, HELD provides the location assertion function, which when 2775 combined with the "signed" attribute provides location source 2776 identification and authentication. 2778 B.22. LocSec6 2780 "Where a location is acquired and cached prior to an emergency call, 2781 it should be refreshed at regular intervals to ensure that it is as 2782 current as possible, in the event location information cannot be 2783 obtained in real time." 2785 COMPLY 2787 HELD supports the ability to request location at any time. 2789 B.23. LocSec7 2791 "Where location by-reference is used the appropriate privacy policies 2792 must be implemented and enforced by the LIS operator." 2794 COMPLY 2796 HELD allows a Target to provide access rules ot the LIS. The Target 2797 may provide either an explicit set of rules defined using common 2798 policy syntax as described in [I-D.ietf-geopriv-common-policy], or 2799 the Target may provide a ruleset URI allowing the LIS to retrieve the 2800 ruleset from a third-party. 2802 Authors' Addresses 2804 James Winterbottom 2805 Andrew 2806 PO Box U40 2807 Wollongong University Campus, NSW 2500 2808 AU 2810 Phone: +61 2 4221 2938 2811 Email: james.winterbottom@andrew.com 2812 URI: http://www.andrew.com/ 2814 Martin Thomson 2815 Andrew 2816 PO Box U40 2817 Wollongong University Campus, NSW 2500 2818 AU 2820 Phone: +61 2 4221 2915 2821 Email: martin.thomson@andrew.com 2822 URI: http://www.andrew.com/ 2824 Barbara Stark 2825 BellSouth 2826 Room 7A41 2827 725 W Peachtree St. 2828 Atlanta, GA 30308 2829 US 2831 Email: barbara.stark@bellsouth.com 2833 Full Copyright Statement 2835 Copyright (C) The IETF Trust (2007). 2837 This document is subject to the rights, licenses and restrictions 2838 contained in BCP 78, and except as set forth therein, the authors 2839 retain all their rights. 2841 This document and the information contained herein are provided on an 2842 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2843 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2844 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2845 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2846 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2847 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2849 Intellectual Property 2851 The IETF takes no position regarding the validity or scope of any 2852 Intellectual Property Rights or other rights that might be claimed to 2853 pertain to the implementation or use of the technology described in 2854 this document or the extent to which any license under such rights 2855 might or might not be available; nor does it represent that it has 2856 made any independent effort to identify any such rights. Information 2857 on the procedures with respect to rights in RFC documents can be 2858 found in BCP 78 and BCP 79. 2860 Copies of IPR disclosures made to the IETF Secretariat and any 2861 assurances of licenses to be made available, or the result of an 2862 attempt made to obtain a general license or permission for the use of 2863 such proprietary rights by implementers or users of this 2864 specification can be obtained from the IETF on-line IPR repository at 2865 http://www.ietf.org/ipr. 2867 The IETF invites any interested party to bring to its attention any 2868 copyrights, patents or patent applications, or other proprietary 2869 rights that may cover technology that may be required to implement 2870 this standard. Please address the information to the IETF at 2871 ietf-ipr@ietf.org. 2873 Acknowledgment 2875 Funding for the RFC Editor function is provided by the IETF 2876 Administrative Support Activity (IASA).