idnits 2.17.1 draft-ietf-geopriv-http-location-delivery-00.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 1680. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1698. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1704. 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. 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: The following response codes follow a three decimal form similar to that in HTTP [3] and SIP [22]: 200 (Success): This code indicates that the request was successful. This code MUST not be used for an error response. 400 (Request Error): This code indicates that the request was badly formed in some fashion. 401 (XML Error): This code indicates that the XML content of the request was either badly formed or invalid. 402 (Authentication Error): This code indicates that the request either did not contain authentication information, or the authentication provided was not accepted. 500 (General LCS Error): This code indicates that an unspecified error occurred at the LCS. 501 (Location Unknown): This code indicates that the LCS could not determine the location of the Device. 502 (Unsupported Message): This code indicates that the request was not supported or understood by the LCS. 503 (Timeout): This code indicates that the LCS could not satisfy the request within the time specified in the "responseTime" parameter. 504 (Cannot Provide LI Type): This code indicates that the LCS was unable to provide LI of the type or types requested. This code is used when the "exact" attribute on the "locationType" parameter is set to "true". Additional response codes within the x00 to x79 range MUST be specified in published RFCs; the range from x80 to x99 is reserved for private usage. -- 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 (June 7, 2007) is 6165 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) -- Looks like a reference, but probably isn't: '0-5' on line 701 -- Looks like a reference, but probably isn't: '0-9' on line 701 == Unused Reference: '5' is defined on line 1387, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1400, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1419, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1424, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 1447, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (ref. '2') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2616 (ref. '3') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (ref. '4') (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 3693 (ref. '7') == 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-07 == Outdated reference: A later version (-10) exists of draft-ietf-geopriv-l7-lcp-ps-02 ** Downref: Normative reference to an Informational draft: draft-ietf-geopriv-l7-lcp-ps (ref. '11') -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' == 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-01 ** Downref: Normative reference to an Informational draft: draft-marshall-geopriv-lbyr-requirements (ref. '16') -- Obsolete informational reference (is this intentional?): RFC 793 (ref. '17') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2222 (ref. '18') (Obsoleted by RFC 4422, RFC 4752) -- Obsolete informational reference (is this intentional?): RFC 3023 (ref. '20') (Obsoleted by RFC 7303) == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-07 Summary: 8 errors (**), 0 flaws (~~), 13 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV WG M. Barnes, Ed. 3 Internet-Draft Nortel 4 Intended status: Standards Track 5 Expires: December 9, 2007 7 June 7, 2007 9 HTTP Enabled Location Delivery (HELD) 10 draft-ietf-geopriv-http-location-delivery-00.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 December 9, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 A Layer 7 Location Configuration Protocol (L7 LCP) is described that 44 is used for retrieving location information from a server within an 45 access network. The protocol includes options for retrieving 46 location information either by-value or by-reference. The protocol 47 supports mobile and nomadic devices through Location URIs. The 48 protocol is an application-layer protocol that is independent of 49 session-layer; an HTTP, web services binding is specified. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 6 57 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 58 6. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9 59 6.1. Protocol Binding . . . . . . . . . . . . . . . . . . . . . 9 60 6.2. Location Request . . . . . . . . . . . . . . . . . . . . . 9 61 6.3. Held Response . . . . . . . . . . . . . . . . . . . . . . 10 62 6.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 10 63 7. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10 64 7.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11 65 7.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 11 66 7.2.1. "exact" Parameter . . . . . . . . . . . . . . . . . . 12 67 7.3. "options" Parameter . . . . . . . . . . . . . . . . . . . 13 68 7.4. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 13 69 7.5. "message" Parameter . . . . . . . . . . . . . . . . . . . 13 70 7.6. "locationURI" Parameter . . . . . . . . . . . . . . . . . 14 71 7.6.1. "expires" Parameter . . . . . . . . . . . . . . . . . 14 72 8. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 9. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 9.1. HTTP Binding WSDL . . . . . . . . . . . . . . . . . . . . 18 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 76 10.1. Return Routability . . . . . . . . . . . . . . . . . . . . 20 77 10.2. Transaction Layer Security . . . . . . . . . . . . . . . . 21 78 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 79 11.1. Simple HTTP Binding Example Messages . . . . . . . . . . . 21 80 11.2. Simple Location Request Example . . . . . . . . . . . . . 24 81 11.3. Location Request Example with options . . . . . . . . . . 25 82 11.4. Location Request Example for Multiple Location Types . . . 27 83 11.5. Sample LCS WSDL Document . . . . . . . . . . . . . . . . 29 84 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 85 12.1. IANA Registry for HELD Result Codes . . . . . . . . . . . 29 86 12.2. IANA Registry for HELD Location Request Options . . . . . 30 87 12.3. URN Sub-Namespace Registration for 88 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 30 89 12.4. XML Schema Registration . . . . . . . . . . . . . . . . . 31 90 12.5. URN Sub-Namespace Registration for 91 urn:ietf:params:xml:ns:geopriv:held:http . . . . . . . . . 31 92 12.6. MIME Media Type Registration for 'application/held+xml' . 32 93 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33 94 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 95 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 96 15.1. Normative References . . . . . . . . . . . . . . . . . . . 33 97 15.2. Informative References . . . . . . . . . . . . . . . . . . 35 98 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 35 99 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 36 100 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 36 101 A.3. L7-3: Layer 7 and Layer 2/3 Provider Relationship . . . . 36 102 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 37 103 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 37 104 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 37 105 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 38 106 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 38 107 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 38 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 109 Intellectual Property and Copyright Statements . . . . . . . . . . 40 111 1. Introduction 113 The location of a Device is information that is useful for a number 114 of applications. The L7 LCP problem statement and requirements 115 document [11] provides some scenarios in which a Device might rely on 116 its access network to provide the location information, such as such 117 as fixed environments (e.g., DSL/Cable), mobile networks and wireless 118 access networks. This document describes a protocol that can be used 119 to acquire Location Information (LI) from a service within an access 120 network. The service within an access network is assumed to be 121 provided by a Location Configuration Server (LCS), as introduced in 122 the L7 LCP problem statement and requirements document. 124 This specification identifies two methods for acquiring LI. Location 125 may be retrieved from a Location Configuration Server (LCS) by-value, 126 that is, the Device may acquire LI directly. Alternatively, the 127 Device may request that the LCS provide a location URI so that LI can 128 be distributed by-reference. Both of these methods are compatible, 129 and both can be provided concurrently from the same LCS so that 130 application needs can be addressed individually. 132 This specification defines an XML-based protocol that enables the 133 retrieval of LI from a LCS by a Device. This protocol can be bound 134 to any session-layer protocol, particularly those capable of MIME 135 transport; an HTTP binding is included as a minimum requirement. 137 2. Conventions 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [1]. 143 3. Terminology 145 This document uses the terms (and their acronym forms) Access 146 Provider (AP), Location Information (LI), Location Object (LO), 147 Device, Target, Location Server (LS), Location Generator (LG), 148 Location Recipient (LR), Rule Maker (RM) and Rule Holder (RH) as 149 defined in [7]. This document also includes definitions for the 150 terms, Civic Location/Address, Geodetic Location, and Location 151 Configuration Server, used within this document. These definitions 152 may differ slightly from those used in other GEOPRIV documents, but 153 the concepts are the same. 155 For convenience, abbreviated versions of RFC 3693 [7] definitions are 156 included. Notes are included following some of the definitions to 157 clarify the context in which these terms are used in this document: 159 Access Network Provider: See Access Provider (AP). 161 Access Provider (AP): An organization that provides physical network 162 connectivity to its customers or users, e.g., through digital 163 subscriber lines, cable TV plants, Ethernet, leased lines or radio 164 frequencies. Examples of such organizations include 165 telecommunication carriers, municipal utilities, larger 166 enterprises with their own network infrastructure, and government 167 organizations such as the military. 168 Note: this definition differs from that in [7] by the use of the 169 more generic 'organization' rather than 'domain' - the general 170 concept is the same. This term is used interchangeably with 171 Access Network Provider in this document. 173 Civic Location/Address: A location expressed in a form that is 174 defined by civic demarcations. Civic addresses can be specialized 175 for jurisdictional (general use) or postal (message delivery) 176 purposes, or they can apply to either. 178 Device: The technical device whereby the location is tracked as a 179 proxy for the location of a Target. 181 Geodetic Location: A location expressed in coordinate form. 183 Location Configuration Server (LCS): The entity within the Access 184 Provider's network that provides location information to clients. 185 This term is introduced in [11] and it provides the location 186 information that is generated and maintained by the LG and LS 187 functional elements respectively. The details of the interactions 188 between an LG and LS and in particular how the LCS uses these to 189 obtain location information is outside the scope of this document 190 since it is very deployment specific. 192 Location Generator (LG): The entity that initially determines or 193 gathers the location of the Target and creates Location Objects 194 describing that location. 196 Location Information (LI): The data that describes the location of a 197 Device. The term LI does not include the representation of this 198 data. 199 Note: this terms is not officially defined in [7], but rather is 200 assumed from the general usage throughout that document and within 201 the GEOPRIV WG. 203 Location Object (LO): An object conveying Location Information (and 204 possibly privacy rules) to which Geopriv security mechanisms and 205 privacy rules are to be applied. 206 Note: this is a specific by-value representation of Location 207 Information (LI). In this document, LO refers to PIDF-LO [8]. 209 Location Server (LS): The LS is an element that receives 210 publications of Location Objects from Location Generators and may 211 receive subscriptions from Location Recipients. The LS applies 212 the rules (which it learns from the Rule Holder) to LOs it 213 receives from LGs, and then notifies LRs of resulting LOs as 214 necessary. 215 Note: This definition varies from that defined in [7] by defining 216 the roles of the functional elements more explicitly. In some 217 specifications the Location Server is referred to as a Location 218 Information Server or LIS. In this context, the Location Server 219 is distinct from what is alternatively referred to as a Registrar 220 in other contexts. 222 Location Recipient (LR): The entity that receives Location 223 Information (LI). 225 Rule Holder (RH): The entity that provides the rules associated with 226 a particular target for the distribution of Location Information 227 (LI). 229 Rule Maker (RM): The authority that creates rules governing access 230 to location information for a target (typically, this it the 231 Target themselves). 233 Target: A person or other entity whose location is communicated by a 234 GEOPRIV Location Object (LO). 236 4. Overview and Scope 238 This document describes an interface between a Device and a Location 239 Configuration Server (LCS). The LCS is a service present within the 240 same administrative domain as the Device (the access network). An 241 Access Provider (AP) operates the LCS service so that Devices (and 242 Targets) can retrieve LI. The LCS exists because not all Devices are 243 capable of determining LI, and because, even if a device is able to 244 determine its own LI, it may be more efficient with assistance. This 245 document does not specify how LI is derived. 247 This document is based on the attribution of the LI to a device and 248 not specifically a person (end user) or Target, based on the premise 249 that location determination technologies are generally designed to 250 locate a device and not a person. It is expected that, for most 251 applications, LI for the device can be used as an adequate substitute 252 for the end user's LI. Since revealing the location of the device 253 almost invariably reveals some information about the location of the 254 user of the device, the same level of privacy protection demanded by 255 a user is required for the device. This approach may require either 256 some additional assurances about the link between device and target, 257 or an acceptance of the limitation that unless the device requires 258 active user authentication, there is no guarantee that any particular 259 individual is using the device at that instant. 261 This document identifies two methods for acquiring LI. Location may 262 be retrieved from a Location Configuration Server (LCS) by-value, 263 that is, the device may acquire LI directly. Alternatively, the 264 Device may request that the LCS provide a location URI so that LI can 265 be distributed by-reference. Providing LI by-reference implies that 266 a server is able to provide the device with a public, globally- 267 addressable URI. 269 The following diagram shows the logical configuration of some of the 270 functional elements identified in [7] and the LCS defined in [11] and 271 where this protocol applies, with the Rule Maker and Target 272 represented by the role of the Device. 274 +---------------------------------------------+ 275 | Access Network Provider | 276 | | 277 | +--------------------------------------+ | 278 | | Location Configuration Server | | 279 | | | | 280 | | | | 281 | | | | 282 | | | | 283 | +------|---------------------'---------+ | 284 +----------|---------------------'------------+ 285 | ' 286 | ' 287 HELD APP 288 | ' 289 Rule Maker - _ +-----------+ +-----------+ 290 o - - | Device | | Location | 291 and 328 as specified in [8] MUST be applied. A default value of "no" SHALL 329 be used for the element. A default value of 330 24 hours SHALL be used for value of any generated 331 PDIF-LO documents. 333 Requesting location directly does not always address the requirements 334 of an application. A Device can request a location URI instead of 335 literal location. A Location URI is a URI [23] of any scheme, which 336 a Location Recipient (LR) can use to retrieve LI. A location URI 337 provided by an LCS can be assumed to be globally-addressable; that 338 is, anyone in possession of the URI can access the LCS. This does 339 not in any way suggest that the LCS is bound to reveal the location 340 associated with the location URI. This issue is deemed out of scope 341 for this document. The merits and drawbacks of using a Location URI 342 approach are discussed in [16]. 344 6. Protocol Description 346 As discussed in Section 5, this protocol provides for the retrieval 347 of a Location or a Location URI from an LCS. Three messages are 348 defined to support the location retrieval: locationRequest, 349 heldResponse and error. Messages are defined as XML documents. 351 The Location Request (locationRequest) message is described in 352 Section 6.2. A Location Request from a Device indicates whether a 353 Location (and the specific type of location) and/or a Location URI 354 should be returned. The LCS replies with a response (heldResponse), 355 including a PIDF-LO document and/or one or more Location URIs in case 356 of success, or an error message in case of an error. 358 A MIME type "application/held+xml" is registered in Section 12.6 to 359 distinguish HELD messages from other XML document bodies. This 360 specification follows the recommendations and conventions described 361 in [20], including the naming convention of the type ('+xml' suffix) 362 and the usage of the 'charset' parameter. 364 Section 7 contains a more thorough description of the protocol 365 parameters, valid values, and how each should be handled. Section 8 366 contains a more specific definition of the structure of these 367 messages in the form of an XML Schema [12]. 369 6.1. Protocol Binding 371 The HELD protocol is an application-layer protocol that is defined 372 independently of any lower layers. This means that any protocol can 373 be used to transport this protocol providing that it can provide a 374 few basic features: 375 o The protocol must have acknowledged delivery. 376 o The protocol must be able to correlate a response with a request. 377 o The protocol must provide authentication, privacy and protection 378 against modification. 379 Candidate protocols that could be used to address these purposes 380 include: TCP [17], TLS [2], SASL [18], HTTP [3], SIP [22], BEEP [21] 381 and SOAP [25] [26]. This document includes a binding that uses a 382 combination of HTTP, TLS and TCP in Section 9. 384 6.2. Location Request 386 A location request is sent from the Device to the LCS when it 387 requires LI. This request MUST include the type of location being 388 requested such as civic location, location URI, etc. The type of LI 389 that a Device requests is determined by the type of LI that is 390 included in the "locationType" element. 392 The location request is made by sending a document formed of a 393 "locationRequest" element. The successful response to a location 394 request is a document formed of a "heldResponse" element, unless the 395 request fails, in which case the LCS SHOULD provide an error 396 indication document. 398 6.3. Held Response 400 The response to a Location request MUST contain either a PIDF-LO 401 and/or Location URI(s), depending upon the requested "locationType". 402 The "heldResponse" element MUST include a "code" attribute with a 403 value of 200. A set of predefined error codes are included in 404 Section 7.4. The response is in error if there is a value other than 405 200, since those MUST be sent using the error message Section 6.4. 407 A Location URI MUST NOT contain any information that could be used to 408 identify the Device or Target. It is RECOMMENDED that a Location URI 409 contain a public address for the LCS and a random sequence of 410 characters that the LCS can use to identify a particular context. 412 6.4. Indicating Errors 414 In the event of an error, the LCS SHOULD respond to the Device with 415 an error document. The error response applies to all request types 416 and SHOULD also be sent in response to any unrecognized request. 418 An error indication document consists of an "error" element. The 419 "error" element MUST include a "code" attribute that indicates the 420 type of error. A set of predefined error codes are included in 421 Section 7.4. 423 Error responses MAY also include a "message" attribute that can 424 include additional information. This information SHOULD be for 425 diagnostic purposes only, and MAY be in any language. The language 426 of the message SHOULD be indicated with an "xml:lang" attribute. 428 7. Protocol Parameters 430 This section describes, in detail the parameters that are used for 431 this protocol. Table 1 lists the top-level components used within 432 the protocol and where they are mandatory or optional for each of the 433 messages. 435 +-------------------------+-----------------+---------------+-------+ 436 | Parameter | Location | HELD Response | Error | 437 | | Request | | | 438 +-------------------------+-----------------+---------------+-------+ 439 | responseTime | o | | | 440 | (Section 7.1) | | | | 441 | locationType | m | | | 442 | (Section 7.2) | | | | 443 | exact (Section 7.2.1) | o | | | 444 | options (Section 7.3) | o | | | 445 | code (Section 7.4) | | m | m | 446 | message (Section 7.5) | | o | o | 447 | locationURI | | o | | 448 | (Section 7.6) | | | | 449 | expires (Section 7.6.1) | | m | | 450 +-------------------------+-----------------+---------------+-------+ 452 Table 1: Message Parameter Usage 454 7.1. "responseTime" Parameter 456 The "responseTime" attribute indicates to the LCS how long the Device 457 is prepared to wait for a response. This attribute MAY be added to a 458 Location request message. The value of this attribute is indicative 459 only, the LCS is under no obligation to strictly adhere to the time 460 limit implied; any enforcement of the time limit is left to the 461 requesting Device. 463 This attribute is expressed with a decimal seconds value, which may 464 include a decimal point. It is RECOMMENDED that systems support 465 millisecond precision for this parameter. 467 The LCS MUST provide the most accurate LI that can be determined 468 within the specified interval. This parameter could be used as input 469 when selecting the method of location determination, where multiple 470 such methods exist. If this parameter is absent, then the LCS MUST 471 return the most precise LI it is capable of determining. 473 7.2. "locationType" Parameter 475 The "locationType" element is included in a location request. It 476 contains a list of LI types that are requested by the Device. The 477 following list describes the possible values: 478 any: The LCS SHOULD attempt to provide LI in all forms available to 479 it. This value MUST be assumed as the default if no 480 "locationType" is specified. The LCS SHOULD return location 481 information in a form that is suited for routing and responding to 482 an emergency call in its jurisdiction. 484 geodetic: The LCS SHOULD return a geodetic location for the Target. 485 civic: The LCS SHOULD return a civic address for the Target. Any 486 type of civic address may be returned. The LCS SHOULD ignore this 487 value if a request for jurisdictional or postal civic address has 488 been made and can be satisfied. 489 jurisdictionalCivic: The LCS SHOULD return a jurisdictional civic 490 address for the Target. 491 postalCivic: The LCS SHOULD return a postal civic address for the 492 Target. 493 locationURI: The LCS SHOULD return a location URI for the Target. 495 The LCS SHOULD return the requested location type or types. The LCS 496 MAY provide additional location types, or it MAY provide alternative 497 types if the request cannot be satisfied for a requested location 498 type. If the "exact" attribute is present and set to "true" in a 499 location request, then a successful LCS response MUST provide the 500 requested location type only, with no additional location 501 information. The "exact" attribute has no effect when this element 502 is set to "any". 504 The "SHOULD"-strength requirement on this parameter is included to 505 allow for soft-failover. This enables a fixed client configuration 506 that prefers a specific location type without causing location 507 requests to fail when that location type is unavailable. Unless the 508 "exact" attribute is set, the LCS MUST provide LI in any available 509 form if it is unable to comply with the request. 511 For example, a notebook computer could be configured to retrieve 512 civic addresses, which is usually available from typical home or work 513 situations. However, when using a wireless modem, the LCS might be 514 unable to provide a civic address. 516 7.2.1. "exact" Parameter 518 When the "exact" attribute is set to "true", it indicates to the LCS 519 that the contents of the "locationType" parameter MUST be strictly 520 followed. The default value of "false" allows the LCS the option of 521 returning something beyond what is specified, such as a location URI 522 when only a civic location was requested. 524 A value of "true" indicates that the LCS MUST provide a location of 525 the requested type or types or MUST provide an error. The LCS MUST 526 provide the requested types only and these types SHOULD be specified 527 in the same order as they were requested. The LCS SHOULD handle an 528 exact request that includes a "locationType" element set to "any" as 529 if the "exact" attribute were set to "false". 531 7.3. "options" Parameter 533 The "options" attribute provides for extensibility, allowing for the 534 definition of future optional extensions to the location request 535 message without the need to create a new namespace. If multiple 536 options are used, they MUST be separated by a semicolon (;), such as 537 "optionOne=1;optionTwo=2; Option3=3". Options MUST be registered 538 with IANA per Section 12.2. 540 7.4. "code" Parameter 542 All responses MUST contain a response code. The "code" attribute 543 applies to the "error" and "heldResponse" messages. 545 The following response codes follow a three decimal form similar to 546 that in HTTP [3] and SIP [22]: 547 200 (Success): This code indicates that the request was successful. 548 This code MUST not be used for an error response. 549 400 (Request Error): This code indicates that the request was badly 550 formed in some fashion. 551 401 (XML Error): This code indicates that the XML content of the 552 request was either badly formed or invalid. 553 402 (Authentication Error): This code indicates that the request 554 either did not contain authentication information, or the 555 authentication provided was not accepted. 556 500 (General LCS Error): This code indicates that an unspecified 557 error occurred at the LCS. 558 501 (Location Unknown): This code indicates that the LCS could not 559 determine the location of the Device. 560 502 (Unsupported Message): This code indicates that the request was 561 not supported or understood by the LCS. 562 503 (Timeout): This code indicates that the LCS could not satisfy 563 the request within the time specified in the "responseTime" 564 parameter. 565 504 (Cannot Provide LI Type): This code indicates that the LCS was 566 unable to provide LI of the type or types requested. This code is 567 used when the "exact" attribute on the "locationType" parameter is 568 set to "true". 569 Additional response codes within the x00 to x79 range MUST be 570 specified in published RFCs; the range from x80 to x99 is reserved 571 for private usage. 573 7.5. "message" Parameter 575 The "heldResponse" and "error" messages MAY include a "message" 576 attribute to convey some additional, human-readable information about 577 the result of the request. This message MAY be included in any 578 language, which SHOULD be indicated by the "xml:lang", attribute. 580 The default language is assumed to be English. 582 7.6. "locationURI" Parameter 584 The "locationURI" element includes a single Location URI. Each 585 Location URI that is allocated by the LCS is unique to the device 586 that is requesting it. 588 A "heldResponse" message MAY contain any number of "locationURI" 589 elements. It is RECOMMENDED that the LCS allocate a Location URI for 590 each scheme that it supports and that each scheme is present only 591 once. URI schemes and their secure variants such as http and https 592 should be regarded as two separate schemes. 594 7.6.1. "expires" Parameter 596 The "expires" attribute indicates the time at which the Location URI 597 provided by the LCS will expire. This attribute is included in the 598 "heldResponse" message only. 600 Responses to Locations requests for Location URIs MUST include the 601 expiry time of the Location URI. 603 8. XML Schema 605 This section gives the XML Schema Definition [12] of the 606 "application/held+xml" format. This is presented as a formal 607 definition of the "application/held+xml" format. Note that the XML 608 Schema definition is not intended to be used with on-the-fly 609 validation of the presence XML document. 611 612 624 625 626 628 This document defines HELD messages. 629 630 632 634 636 639 641 644 645 646 647 648 649 651 652 654 655 656 658 659 660 661 662 663 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 689 690 691 692 694 695 696 698 699 700 701 702 703 705 706 707 708 709 710 712 713 714 716 717 718 719 720 722 724 725 726 727 729 731 732 733 734 735 736 739 741 742 743 744 746 749 751 752 753 754 755 758 760 761 763 764 765 767 770 772 9. HTTP Binding 774 This section defines an HTTP [3] binding for this protocol, which all 775 conforming implementations MUST support. This binding takes the form 776 of a Web Service (WS) that can be described by the Web Services 777 Description Language (WSDL) document in Section 9.1. 779 The request is carried in this binding as the body of an HTTP POST 780 request. The MIME type of both request and response bodies should be 781 "application/held+xml". 783 The LCS populates the HTTP headers so that they are consistent with 784 the contents of the message. In particular, the "expires" and cache 785 control headers are used to control the caching of any PIDF-LO 786 document or Location URIs. The HTTP status code SHOULD have the same 787 first digit as any "heldResponse" or "error" body included, and it 788 SHOULD indicate a 2xx series response when a PIDF-LO document or 789 Location URI is included. 791 This binding also includes a default behaviour, which is triggered by 792 a GET request, or a POST with no request body. If either of these 793 queries are received, the LCS MUST attempt to provide either a 794 PIDF-LO document or a Location URI, as if the request was a location 795 request. 797 This binding MUST use TLS as described in [4]. TLS provides message 798 integrity and privacy between Device and LCS. The LCS MUST use the 799 server authentication method described in [4]; the Device MUST fail a 800 request if server authentication fails, except in the event of an 801 emergency. 803 9.1. HTTP Binding WSDL 805 The following WSDL 2.0 [27] document describes the HTTP binding for 806 this protocol. Actual service instances MUST provide a "service" 807 with at least one "endpoint" that implements the "heldHTTP" binding. 808 A service description document MAY include this schema directly or by 809 using the "import" or "include" directives. 811 812 821 822 This document describes the basic HELD sighting web service. 823 Please refer to RFCXXXX for details. 824 [[NOTE TO RFC-EDITOR: Please replace XXXX with the RFC number 825 for this specification and remove this note.]] 826 828 829 830 832 833 834 836 838 839 840 841 842 844 847 848 849 851 853 860 861 862 864 866 868 10. Security Considerations 870 The threat model for this protocol assumes that the LCS exists within 871 the same administrative domain as the Device. The LCS requires 872 access to network information so that it can determine Location. 873 Therefore, the LCS can use network information to protect against a 874 number of the possible attacks. 876 Specific requirements and security considerations for location 877 acquisition protocols are provided in [11] including that the LCP 878 MUST NOT assume prior network access authentication, which is 879 addressed in Section 10.2 881 An in-depth discussion of the security considerations applicable to 882 the use of Location URIs and by-reference provision of LI is included 883 in [16]. 885 10.1. Return Routability 887 It is RECOMMENDED that Location Configuration Servers use return 888 routability rather than requiring Device authentication. Device 889 authentication SHOULD NOT be required due to the administrative 890 challenge of issuing and managing of client credentials, particularly 891 when networks allow visiting users to attach devices. However, the 892 LCS MAY require any form of authentication as long as these factors 893 are considered. 895 Addressing information used in a request to the LCS is used to 896 determine the identity of the Device, and to address a response. 897 This ensures that a Device can only request its own LI. 899 A temporary spoofing of IP address could mean that a device could 900 request a Location URI that would result in another Device's 901 location. One or more of the follow approaches are RECOMMENDED to 902 limit this exposure: 903 o Location URIs SHOULD have a limited lifetime, as reflected by the 904 value for the expires element (Section 7.6.1). 905 o The network SHOULD have mechanisms that protect against IP address 906 spoofing. 907 o The LCS SHOULD ensure that requests can only originate from within 908 its administrative domain. 910 o The LCS and network SHOULD be configured so that the LCS is made 911 aware of Device movement within the network and addressing 912 changes. If the LCS detects a change in the network, then all 913 location URIs MUST be invalidated. 915 The above measures are dependent on network configuration and SHOULD 916 be considered with circumstances in mind. For instance, in a fixed 917 internet access, providers may be able to restrict the allocation of 918 IP addresses to a single physical line, ensuring that spoofing is not 919 possible; in such an environment, other measures may not be 920 necessary. 922 10.2. Transaction Layer Security 924 All bindings for this protocol MUST ensure that messages are 925 adequately protected against eavesdropping and modification. 926 Bindings MUST also provide a means of authenticating the LCS. 928 It is RECOMMENDED that all bindings also use TLS [2]. 930 For the HTTP binding, TLS MUST be used. TLS provides protection 931 against eavesdropping and modification. The server authentication 932 methods described in HTTP on TLS [4] MUST be used. 934 11. Examples 936 11.1. Simple HTTP Binding Example Messages 938 The examples in this section show a complete HTTP message that 939 includes the HELD request or response document. 941 This example shows the most basic request for a LO. This uses the 942 GET feature described by the HTTP binding. This example assumes that 943 the LCS service exists at the URL "https://lcs.example.com/location". 945 GET /location HTTP/1.1 946 Host: lcs.example.com 947 Accept: application/pidf+xml,application/held+xml, 948 application/xml;q=0.8, 949 text/xml;q=0.7 950 Accept-Charset: UTF-8,* 952 The GET request is exactly identical to a minimal POST request that 953 includes an empty "locationRequest" element. 955 POST /location HTTP/1.1 956 Host: lcs.example.com 957 Accept: application/pidf+xml,application/held+xml, 958 application/xml;q=0.8, 959 text/xml;q=0.7 960 Accept-Charset: UTF-8,* 961 Content-Type: application/held+xml 962 Content-Length: 87 964 965 967 The successful response to either of these requests is a PIDF-LO 968 document. The following response shows a minimal PIDF-LO response. 970 HTTP/1.x 200 OK 971 Server: Example LCS 972 Date: Tue, 10 Jan 2006 03:42:29 GMT 973 Expires: Tue, 10 Jan 2006 03:42:29 GMT 974 Cache-control: private 975 Content-Type: application/pidf+xml 976 Content-Length: 594 978 979 982 984 985 986 987 988 990 -34.407 150.88001 991 992 993 994 995 2006-01-11T03:42:28+00:00 996 997 998 999 2006-01-10T03:42:28+00:00 1000 1001 1002 1004 The error response to either of these requests is an error document. 1005 The following response shows an example error response. 1007 HTTP/1.x 500 Server Error 1008 Server: Example LCS 1009 Expires: Tue, 10 Jan 2006 03:49:20 GMT 1010 Cache-control: private 1011 Content-Type: application/held+xml 1012 Content-Length: 135 1014 1015 1018 Note: To focus on important portions of messages, all examples 1019 following this note do not show HTTP headers or the XML prologue. 1020 In addition, sections of XML not relevant to the example are 1021 replaced with comments. 1023 11.2. Simple Location Request Example 1025 The location request shown below doesn't specify any location types 1026 or response time. 1028 1030 The response to this location request is a list of Location URIs. 1032 1034 1035 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 1036 1037 sips:9769+357yc6s64ceyoiuy5ax3o@ls.example.com 1038 1039 1040 1042 An error response to this location request is shown below: 1044 1047 11.3. Location Request Example with options 1049 The location request shown below specifies a response time and an 1050 option, but doesn't specify any location type. 1052 1056 The corresponding HELD response shown below includes a PIDF-LO. 1058 1060 1062 1063 1064 1065 1066 1070 -34.407242 150.882518 1071 30 1072 1073 1074 1077 AU 1078 NSW 1079 Wollongong 1080 Gwynneville 1081 Northfield Avenue 1082 University of Wollongong 1083 2 1084 Andrew Corporation 1085 2500 1086 39 1087 WS-183 1088 U40 1089 1090 1091 1092 false 1093 2007-05-25T12:35:02+10:00 1094 1095 1096 Wiremap 1097 1098 1099 2007-05-24T12:35:02+10:00 1100 1101 1102 1104 A corresponding HELD response with Location URIs. 1106 1108 1109 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 1110 1111 sips:9769+357yc6s64ceyoiuy5ax3o@ls.example.com: 1112 1113 1114 1116 11.4. Location Request Example for Multiple Location Types 1118 The following Location Request message includes a request for 1119 geodetic, jurisdictional civic and any Location URIs. 1121 1122 1123 geodetic 1124 jurisdictionalCivic 1125 locationURI 1126 1127 1129 The corresponding HELD Response message includes the requested 1130 location information, including two location URIs. 1132 1134 1135 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 1136 1137 sips:9769+357yc6s64ceyoiuy5ax3o@ls.example.com: 1138 1139 1140 1142 1143 1144 1145 1146 1150 -34.407242 150.882518 1151 30 1152 1153 1154 1157 AU 1158 NSW 1159 Wollongong 1160 Gwynneville 1161 Northfield Avenue 1162 University of Wollongong 1163 2 1164 Andrew Corporation 1165 2500 1166 39 1167 WS-183 1168 U40 1169 1170 1171 1172 false 1173 2007-05-25T12:35:02+10:00 1174 1175 1176 Wiremap 1177 1178 1179 2007-05-24T12:35:02+10:00 1180 1181 1182 1184 11.5. Sample LCS WSDL Document 1186 The following WSDL document demonstrates how a WSDL document can be 1187 created for a specific service, in this case, a service at the URI 1188 "https://lcs.example.com/location". 1190 1191 1196 1199 1200 1203 1205 1207 12. IANA Considerations 1209 According to the guidelines in [6], this document calls for an IANA 1210 registry for result codes and a registry for options in the 1211 locationRequest. This document also registers an XML namespace and 1212 schema and the "application/held+xml" MIME type. 1214 12.1. IANA Registry for HELD Result Codes 1216 IANA will establish and maintain a registry of HELD result codes. 1217 Additional values are registered based on the "specification 1218 required" option in [6]. 1220 Specifications MUST specify the following information when 1221 registering new values in this registry: 1222 Code Value: A three-digit value from 000 to 679. The last 20 codes 1223 in each block of 100 (from x80 to x99) are reserved for private or 1224 experimental use and cannot be registered. 1225 Short Message: A brief message that describes the general reason for 1226 the code. 1228 Publication: A reference to any relevant publication or 1229 specification. 1230 Description and Usage: A longer description of the code and the 1231 circumstances where it applies. This description does not need to 1232 be exhaustive. 1234 The values in Section 7.4 are pre-registered in this registry. 1236 12.2. IANA Registry for HELD Location Request Options 1238 IANA will establish and maintain a registry of HELD Location Request 1239 options to allow for extensibility of the request. Values are 1240 registered based on the "specification required" option in [6]. 1242 Specifications MUST specify the following information when 1243 registering new values in this registry: 1244 Option: Name of the option. 1245 Short Message: A brief message that describes the general reason for 1246 the option and valid values and ranges. 1247 Publication: A reference to any relevant publication or 1248 specification. 1249 Description and Usage: A longer description of the option and the 1250 circumstances where it applies. This description does not need to 1251 be exhaustive. 1253 12.3. URN Sub-Namespace Registration for 1254 urn:ietf:params:xml:ns:geopriv:held 1256 This section registers a new XML namespace, 1257 "urn:ietf:params:xml:ns:geopriv:held", as per the guidelines in [6]. 1258 URI: urn:ietf:params:xml:ns:geopriv:held 1259 Registrant Contact: IETF, GEOPRIV working group, 1260 (geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com). 1261 XML: 1263 BEGIN 1264 1265 1267 1268 1269 HELD Messages 1270 1271 1272

Namespace for HELD Messages

1273

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

1274 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 1275 with the RFC number for this specification.]] 1276

See RFCXXXX.

1277 1278 1279 END 1281 12.4. XML Schema Registration 1283 This section registers an XML schema as per the guidelines in [6]. 1284 URI: urn:ietf:params:xml:schema:geopriv:held 1285 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 1286 Mary Barnes (mary.barnes@nortel.com). 1287 Schema: The XML for this schema can be found as the entirety of 1288 Section 8 of this document. 1290 12.5. URN Sub-Namespace Registration for 1291 urn:ietf:params:xml:ns:geopriv:held:http 1293 This section registers a new XML namespace, 1294 "urn:ietf:params:xml:ns:geopriv:held:http", as per the guidelines in 1295 [6]. 1296 URI: urn:ietf:params:xml:ns:geopriv:held:http 1297 Registrant Contact: IETF, GEOPRIV working group, 1298 (geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com). 1299 XML: 1301 BEGIN 1302 1303 1305 1306 1307 HELD HTTP Binding WS 1308 1309 1310

Namespace for HELD HTTP Binding WS

1311

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

1312 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 1313 with the RFC number for this specification.]] 1314

See RFCXXXX.

1315 1316 1317 END 1319 12.6. MIME Media Type Registration for 'application/held+xml' 1321 This section registers the "application/held+xml" MIME type. 1322 To: ietf-types@iana.org 1323 Subject: Registration of MIME media type application/held+xml 1324 MIME media type name: application 1325 MIME subtype name: held+xml 1326 Required parameters: (none) 1327 Optional parameters: charset 1328 Indicates the character encoding of enclosed XML. Default is 1329 UTF-8. 1330 Encoding considerations: Uses XML, which can employ 8-bit 1331 characters, depending on the character encoding used. See RFC 1332 3023 [20], section 3.2. 1333 Security considerations: This content type is designed to carry 1334 protocol data related to the location of an entity, which could 1335 include information that is considered private. Appropriate 1336 precautions should be taken to limit disclosure of this 1337 information. 1338 Interoperability considerations: This content type provides a basis 1339 for a protocol 1340 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please 1341 replace XXXX with the RFC number for this specification.]] 1342 Applications which use this media type: Location information 1343 providers and consumers. 1344 Additional Information: Magic Number(s): (none) 1345 File extension(s): .xml 1346 Macintosh File Type Code(s): (none) 1348 Person & email address to contact for further information: Mary 1349 Barnes 1350 Intended usage: LIMITED USE 1351 Author/Change controller: This specification is TBD 1352 Other information: This media type is a specialization of 1353 application/xml [20], and many of the considerations described 1354 there also apply to application/held+xml. 1356 13. Contributors 1358 James Winterbottom, Martin Thomson and Barbara Stark are the authors 1359 of the original document, from which this WG document was derived. 1360 Their contact information is included in the Author's address 1361 section. 1363 14. Acknowledgements 1365 The author/contributors would like to thank the following people for 1366 their constructive input to this document (in alphabetical order): 1367 Nadine Abbott, Guy Caron, Martin Dawson, Jerome Grenier, Neil 1368 Justusson, Tat Lam, Patti McCalmont, Perry Prozeniuk, John 1369 Schnizlein, Henning Schulzrinne, Ed Shrum, and Hannes Tschofenig. 1371 15. References 1373 15.1. Normative References 1375 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1376 Levels", BCP 14, RFC 2119, March 1997. 1378 [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1379 RFC 2246, January 1999. 1381 [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 1382 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 1383 HTTP/1.1", RFC 2616, June 1999. 1385 [4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1387 [5] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 1388 Language) XML-Signature Syntax and Processing", RFC 3275, 1389 March 2002. 1391 [6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1392 January 2004. 1394 [7] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 1395 Polk, "Geopriv Requirements", RFC 3693, February 2004. 1397 [8] Peterson, J., "A Presence-based GEOPRIV Location Object 1398 Format", RFC 4119, December 2005. 1400 [9] Thomson, M. and J. Winterbottom, "Revised Civic Location Format 1401 for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in 1402 progress), February 2007. 1404 [10] Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification, 1405 Considerations and Recommendations", 1406 draft-ietf-geopriv-pdif-lo-profile-07 (work in progress), 1407 April 2007. 1409 [11] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location 1410 Configuration Protocol; Problem Statement and Requirements", 1411 draft-ietf-geopriv-l7-lcp-ps-02 (work in progress), April 2007. 1413 [12] Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech, "XML 1414 Schema Part 1: Structures Second Edition", World Wide Web 1415 Consortium Recommendation REC-xmlschema-1-20041028, 1416 October 2004, 1417 . 1419 [13] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second 1420 Edition", World Wide Web Consortium Recommendation REC- 1421 xmlschema-2-20041028, October 2004, 1422 . 1424 [14] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, 1425 "Geographic information - Geography Markup Language (GML)", 1426 OpenGIS 03-105r1, April 2004, 1427 . 1429 [15] Thomson, M. and J. Winterbottom, "Discovering the Local 1430 Location Information Server (LIS)", 1431 draft-thomson-geopriv-lis-discovery-00 (work in progress), 1432 February 2007. 1434 [16] Marshall, R., "Requirements for a Location-by-Reference 1435 Mechanism used in Location Configuration and Conveyance", 1436 draft-marshall-geopriv-lbyr-requirements-01 (work in progress), 1437 March 2007. 1439 15.2. Informative References 1441 [17] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 1442 September 1981. 1444 [18] Myers, J., "Simple Authentication and Security Layer (SASL)", 1445 RFC 2222, October 1997. 1447 [19] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence 1448 and Instant Messaging", RFC 2778, February 2000. 1450 [20] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", 1451 RFC 3023, January 2001. 1453 [21] Rose, M., "The Blocks Extensible Exchange Protocol Core", 1454 RFC 3080, March 2001. 1456 [22] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1457 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1458 Session Initiation Protocol", RFC 3261, June 2002. 1460 [23] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1461 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 1462 January 2005. 1464 [24] Polk, J. and B. Rosen, "Session Initiation Protocol Location 1465 Conveyance", draft-ietf-sip-location-conveyance-07 (work in 1466 progress), February 2007. 1468 [25] Mendelsohn, N., Gudgin, M., Nielsen, H., Moreau, J., and M. 1469 Hadley, "SOAP Version 1.2 Part 1: Messaging Framework", World 1470 Wide Web Consortium FirstEdition REC-soap12-part1-20030624, 1471 June 2003, 1472 . 1474 [26] Nielsen, H., Mendelsohn, N., Gudgin, M., Hadley, M., and J. 1475 Moreau, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Web 1476 Consortium FirstEdition REC-soap12-part2-20030624, June 2003, 1477 . 1479 [27] Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, "Web 1480 Services Description Language (WSDL) Version 2.0 Part 1: Core 1481 Language", W3C CR CR-wsdl20-20060106, January 2006. 1483 Appendix A. HELD Compliance to IETF LCP requirements 1485 This appendix describes HELD's compliance to the requirements 1486 specified in the [11]. 1488 A.1. L7-1: Identifier Choice 1490 "The LIS MUST be presented with a unique identifier of its own 1491 addressing realm associated in some way with the physical location of 1492 the end host." 1494 COMPLY 1496 The identifier used may be the source address of the request packet 1497 and/or additional client identifier values relevant to the scope of 1498 the access network provided within the request. Mapping an IP 1499 address into lower-level attachment data is access network dependent 1500 and is the responsibility the LIS. 1502 A.2. L7-2: Mobility Support 1504 "The GEOPRIV Layer 7 Location Configuration Protocol MUST support a 1505 broad range of mobility from devices that can only move between 1506 reboots, to devices that can change attachment points with the impact 1507 that their IP address is changed, to devices that do not change their 1508 IP address while roaming, to devices that continuously move by being 1509 attached to the same network attachment point." 1511 COMPLY 1513 Mobility support is inherently a characteristic of the access network 1514 technology and HELD is designed to be access network agnostic. 1515 Consequently HELD complies with this requirement. In addition HELD 1516 provides specific support for mobile environments by providing an 1517 optional responseTime attribute in location request messages. 1518 Wireless networks often have several different mechanisms at their 1519 disposal for position determination (e.g. Assisted GPS versus 1520 location based on serving base station identity), each providing 1521 different degrees of accuracy and taking different amounts of time to 1522 yield a result. The responseTime parameter provides the LIS with a 1523 criterion which it can use to select a location determination 1524 technique. 1526 A.3. L7-3: Layer 7 and Layer 2/3 Provider Relationship 1528 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1529 MUST NOT assume a business or trust relationship between the provider 1530 of application layer (e.g., SIP, XMPP, H.323) provider and the access 1531 network provider operating the LIS." 1533 COMPLY 1534 HELD describes a location acquisition protocol and has no 1535 dependencies on how location is used once it has been acquired. 1536 Location acquisition using HELD is subject to the restrictions 1537 described in Section 10. 1539 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship 1541 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1542 MUST assume that there is a trust and business relationship between 1543 the L2 and the L3 provider. The L3 provider operates the LIS and 1544 needs to obtain location information from the L2 provider since this 1545 one is closest to the end host. If the L2 and L3 provider for the 1546 same host are different entities, they cooperate for the purposes 1547 needed to determine end system locations." 1549 COMPLY 1551 HELD was specifically designed with this model in mind and readily 1552 allows itself to chaining requests between operators without a change 1553 in protocol being required. HELD is a webservices protocol it can be 1554 bound to transports other than HTTP, such as BEEP. Using a transport 1555 like BEEP for HELD offers the option of high request throughput over 1556 a dedicated connection between an L3 provider and an L2 provider 1557 without incurring the serial restriction imposed by HTTP. This is 1558 less easy to do with protocols that do not decouple themselves from 1559 the transport. 1561 A.5. L7-5: Legacy Device Considerations 1563 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1564 MUST consider legacy residential NAT devices and NTEs in an DSL 1565 environment that cannot be upgraded to support additional protocols, 1566 for example to pass additional information through DHCP." 1568 COMPLY 1570 HELD is an application protocol and operates on top of IP. A HELD 1571 request from a host behind a residential NAT will traverse the NAT 1572 acquiring the external address of the home router. The location 1573 provided to the host therefore will be the address of the home router 1574 in this circumstance. No changes are required to the home router in 1575 order to support this function, HELD was designed specifically to 1576 address this deployment scenario. 1578 A.6. L7-6: VPN Awareness 1580 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1581 MUST assume that at least one end of a VPN is aware of the VPN 1582 functionality. In an enterprise scenario, the enterprise side will 1583 provide the LIS used by the client and can thereby detect whether the 1584 LIS request was initiated through a VPN tunnel." 1586 COMPLY 1588 HELD does not preclude a LIS on the far end of a VPN tunnel being 1589 aware that the client request is occurring over that tunnel. It also 1590 does not preclude a client device from accessing a LIS serving the 1591 local physical network and subsequently using the location 1592 information with an application that is accessed over a VPN tunnel. 1594 A.7. L7-7: Network Access Authentication 1596 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1597 MUST NOT assume prior network access authentication." 1599 COMPLY 1601 HELD makes no assumptions about prior network access authentication. 1602 HELD strongly recommends the use of TLS with server-side certificates 1603 for communication between the end-point and the LIS. There is no 1604 requirement for the end-point to authenticate with the LIS. 1606 A.8. L7-8: Network Topology Unawareness 1608 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1609 MUST NOT assume end systems being aware of the access network 1610 topology. End systems are, however, able to determine their public 1611 IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP." 1613 COMPLY 1615 HELD makes no assumption about the network topology. HELD doesn't 1616 require that the device know its external IP address, except where 1617 that is required for discovery of the LCS. 1619 A.9. L7-9: Discovery Mechanism 1621 "The L7 LCP MUST define a single mandatory to implement discovery 1622 mechanism." 1624 COMPLY 1626 HELD uses the discovery mechanism in [15]. 1628 Authors' Addresses 1630 Mary Barnes (editor) 1631 Nortel 1632 2201 Lakeside Blvd 1633 Richardson, TX 1635 Email: mary.barnes@nortel.com 1637 James Winterbottom 1638 Andrew 1639 PO Box U40 1640 Wollongong University Campus, NSW 2500 1641 AU 1643 Phone: +61 2 4221 2938 1644 Email: james.winterbottom@andrew.com 1645 URI: http://www.andrew.com/ 1647 Martin Thomson 1648 Andrew 1649 PO Box U40 1650 Wollongong University Campus, NSW 2500 1651 AU 1653 Phone: +61 2 4221 2915 1654 Email: martin.thomson@andrew.com 1655 URI: http://www.andrew.com/ 1657 Barbara Stark 1658 BellSouth 1659 Room 7A41 1660 725 W Peachtree St. 1661 Atlanta, GA 30308 1662 US 1664 Email: barbara.stark@bellsouth.com 1666 Full Copyright Statement 1668 Copyright (C) The IETF Trust (2007). 1670 This document is subject to the rights, licenses and restrictions 1671 contained in BCP 78, and except as set forth therein, the authors 1672 retain all their rights. 1674 This document and the information contained herein are provided on an 1675 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1676 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1677 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1678 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1679 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1680 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1682 Intellectual Property 1684 The IETF takes no position regarding the validity or scope of any 1685 Intellectual Property Rights or other rights that might be claimed to 1686 pertain to the implementation or use of the technology described in 1687 this document or the extent to which any license under such rights 1688 might or might not be available; nor does it represent that it has 1689 made any independent effort to identify any such rights. Information 1690 on the procedures with respect to rights in RFC documents can be 1691 found in BCP 78 and BCP 79. 1693 Copies of IPR disclosures made to the IETF Secretariat and any 1694 assurances of licenses to be made available, or the result of an 1695 attempt made to obtain a general license or permission for the use of 1696 such proprietary rights by implementers or users of this 1697 specification can be obtained from the IETF on-line IPR repository at 1698 http://www.ietf.org/ipr. 1700 The IETF invites any interested party to bring to its attention any 1701 copyrights, patents or patent applications, or other proprietary 1702 rights that may cover technology that may be required to implement 1703 this standard. Please address the information to the IETF at 1704 ietf-ipr@ietf.org. 1706 Acknowledgment 1708 Funding for the RFC Editor function is provided by the IETF 1709 Administrative Support Activity (IASA).