idnits 2.17.1 draft-ietf-geopriv-http-location-delivery-01.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 1621. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1632. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1639. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1645. 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: HELD error responses may be one of the following tokens: success: This code indicates that the request was successful. This code MUST not be used for an error response. requestError: This code indicates that the request was badly formed in some fashion. xmlError: This code indicates that the XML content of the request was either badly formed or invalid. generalLcsError: This code indicates that an unspecified error occurred at the LCS. locationUnknown: This code indicates that the LCS could not determine the location of the Device. unsupportedMessage: This code indicates that the request was not supported or understood by the LCS. timeout: This code indicates that the LCS could not satisfy the request within the time specified in the "responseTime" parameter. cannotProvideLiType: 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". -- 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 (July 9, 2007) is 6135 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) == Unused Reference: '5' is defined on line 1325, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1338, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1357, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1362, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 1385, 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-08 == 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: 7 errors (**), 0 flaws (~~), 13 warnings (==), 13 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: January 10, 2008 7 July 9, 2007 9 HTTP Enabled Location Delivery (HELD) 10 draft-ietf-geopriv-http-location-delivery-01.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 January 10, 2008. 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 . . . . . . . . . . . . . . . . . . . . . 10 61 6.3. Location Response . . . . . . . . . . . . . . . . . . . . 10 62 6.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 10 63 7. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11 64 7.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11 65 7.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12 66 7.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 12 67 7.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 13 68 7.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 13 69 7.5. "locationURI" Parameter . . . . . . . . . . . . . . . . . 14 70 7.5.1. "expires" Parameter . . . . . . . . . . . . . . . . . 14 71 8. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 9. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 18 73 9.1. HTTP Binding WSDL . . . . . . . . . . . . . . . . . . . . 19 74 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 75 10.1. Return Routability . . . . . . . . . . . . . . . . . . . . 20 76 10.2. Transaction Layer Security . . . . . . . . . . . . . . . . 21 77 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 78 11.1. Simple HTTP Binding Example Messages . . . . . . . . . . . 21 79 11.2. Simple Location Request Example . . . . . . . . . . . . . 24 80 11.3. Location Request Example for Multiple Location Types . . . 25 81 11.4. Sample LCS WSDL Document . . . . . . . . . . . . . . . . 26 82 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 83 12.1. URN Sub-Namespace Registration for 84 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 27 85 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 27 86 12.3. URN Sub-Namespace Registration for 87 urn:ietf:params:xml:ns:geopriv:held:http . . . . . . . . . 27 88 12.4. MIME Media Type Registration for 'application/held+xml' . 28 89 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29 90 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 91 15. Changes since last Version . . . . . . . . . . . . . . . . . . 29 92 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 93 16.1. Normative References . . . . . . . . . . . . . . . . . . . 30 94 16.2. Informative References . . . . . . . . . . . . . . . . . . 32 95 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 32 96 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 33 97 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 33 98 A.3. L7-3: Layer 7 and Layer 2/3 Provider Relationship . . . . 33 99 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 34 100 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 34 101 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 35 102 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 35 103 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 35 104 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 35 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 106 Intellectual Property and Copyright Statements . . . . . . . . . . 37 108 1. Introduction 110 The location of a Device is information that is useful for a number 111 of applications. The L7 LCP problem statement and requirements 112 document [11] provides some scenarios in which a Device might rely on 113 its access network to provide the location information, such as such 114 as fixed environments (e.g., DSL/Cable), mobile networks and wireless 115 access networks. This document describes a protocol that can be used 116 to acquire Location Information (LI) from a service within an access 117 network. The service within an access network is assumed to be 118 provided by a Location Configuration Server (LCS), as introduced in 119 the L7 LCP problem statement and requirements document. 121 This specification identifies two methods for acquiring LI. Location 122 may be retrieved from a Location Configuration Server (LCS) by-value, 123 that is, the Device may acquire a literal location object describing 124 the location of the Device. Alternatively, the Device may request 125 that the LCS provide a location reference in the form of a location 126 URI or set of location URIs, allowing the Device to distribute its LI 127 by-reference. Both of these methods are compatible, and both can be 128 provided concurrently from the same LCS so that application needs can 129 be addressed individually. 131 This specification defines an XML-based protocol that enables the 132 retrieval of LI from a LCS by a Device. This protocol can be bound 133 to any session-layer protocol, particularly those capable of MIME 134 transport; an HTTP binding is included as a minimum requirement. 136 2. Conventions 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [1]. 142 3. Terminology 144 This document uses the terms (and their acronym forms) Access 145 Provider (AP), Location Information (LI), Location Object (LO), 146 Device, Target, Location Server (LS), Location Generator (LG), 147 Location Recipient (LR), Rule Maker (RM) and Rule Holder (RH) as 148 defined in [7]. This document also includes definitions for the 149 terms, Civic Location/Address, Geodetic Location, and Location 150 Configuration Server, used within this document. These definitions 151 may differ slightly from those used in other GEOPRIV documents, but 152 the concepts are the same. 154 For convenience, abbreviated versions of RFC 3693 [7] definitions are 155 included. Notes are included following some of the definitions to 156 clarify the context in which these terms are used in this document: 158 Access Network Provider: See Access Provider (AP). 160 Access Provider (AP): An organization that provides physical network 161 connectivity to its customers or users, e.g., through digital 162 subscriber lines, cable TV plants, Ethernet, leased lines or radio 163 frequencies. Examples of such organizations include 164 telecommunication carriers, municipal utilities, larger 165 enterprises with their own network infrastructure, and government 166 organizations such as the military. 167 Note: this definition differs from that in [7] by the use of the 168 more generic 'organization' rather than 'domain' - the general 169 concept is the same. This term is used interchangeably with 170 Access Network Provider in this document. 172 Civic Location/Address: A location expressed in a form that is 173 defined by civic demarcations. Civic addresses can be specialized 174 for jurisdictional (general use) or postal (message delivery) 175 purposes, or they can apply to either. 177 Device: The technical device whereby the location is tracked as a 178 proxy for the location of a Target. 180 Geodetic Location: A location expressed in coordinate form. 182 Location Configuration Server (LCS): The entity within the Access 183 Provider's network that provides location information to clients. 184 This term is introduced in [11] and refers to an entity capable of 185 determining the location of an end point and providing that 186 location information via the Location Configuration Protocol (LCP) 187 to the requesting party. The requesting party is the end point 188 itself or an authorized entity that acts on its behalf. 190 Location Generator (LG): The entity that initially determines or 191 gathers the location of the Target and creates Location Objects 192 describing that location. 194 Location Information (LI): The data that describes the location of a 195 Device, either by-value or by-reference. The term LI does not 196 include the representation of this data. 197 Note: this terms is not officially defined in [7], but rather is 198 assumed from the general usage throughout that document and within 199 the GEOPRIV WG. 201 Location Object (LO): An object conveying Location Information (and 202 possibly privacy rules) to which Geopriv security mechanisms and 203 privacy rules are to be applied. 204 Note: this is a specific by-value representation of Location 205 Information (LI). In this document, LO refers to PIDF-LO [8]. 207 Location Server (LS): The LS is an element that receives 208 publications of Location Objects from Location Generators and may 209 receive subscriptions from Location Recipients. The LS applies 210 the rules (which it learns from the Rule Holder) to LOs it 211 receives from LGs, and then notifies LRs of resulting LOs as 212 necessary. 213 Note: This definition varies from that defined in [7] by defining 214 the roles of the functional elements more explicitly. In some 215 specifications the Location Server is referred to as a Location 216 Information Server or LIS. In this context, the Location Server 217 is distinct from what is alternatively referred to as a Registrar 218 in other contexts. 220 Location Recipient (LR): The entity that receives Location 221 Information (LI). 223 Rule Holder (RH): The entity that provides the rules associated with 224 a particular target for the distribution of Location Information 225 (LI). 227 Rule Maker (RM): The authority that creates rules governing access 228 to location information for a target (typically, this it the 229 Target themselves). 231 Target: A person or other entity whose location is communicated by a 232 GEOPRIV Location Object (LO). 234 4. Overview and Scope 236 This document describes an interface between a Device and a Location 237 Configuration Server (LCS). The LCS is a service present within the 238 same administrative domain as the Device (the access network). An 239 Access Provider (AP) operates the LCS service so that Devices (and 240 Targets) can retrieve LI. The LCS exists because not all Devices are 241 capable of determining LI, and because, even if a device is able to 242 determine its own LI, it may be more efficient with assistance. This 243 document does not specify how LI is derived. 245 This document is based on the attribution of the LI to a Device and 246 not specifically a person (end user) or Target, based on the premise 247 that location determination technologies are generally designed to 248 locate a device and not a person. It is expected that, for most 249 applications, LI for the device can be used as an adequate substitute 250 for the end user's LI. Since revealing the location of the device 251 almost invariably reveals some information about the location of the 252 user of the device, the same level of privacy protection demanded by 253 a user is required for the device. This approach may require either 254 some additional assurances about the link between device and target, 255 or an acceptance of the limitation that unless the device requires 256 active user authentication, there is no guarantee that any particular 257 individual is using the device at that instant. 259 This document identifies two methods for acquiring LI. Location may 260 be retrieved from a Location Configuration Server (LCS) by-value, 261 that is, the Device may acquire a literal location in ther form of a 262 PIDF-LO. Alternatively, the Device may request that the LCS provide 263 a location reference in the form of a location URI or set of location 264 URIs, allowing the Device to distribute its LI by-reference. 265 Providing LI by-reference implies that a server is able to provide 266 the Device with a public, globally-addressable URI. 268 The following diagram shows the logical configuration of some of the 269 functional elements identified in [7] and the LCS defined in [11] and 270 where this protocol applies, with the Rule Maker and Target 271 represented by the role of the Device. 273 +---------------------------------------------+ 274 | Access Network Provider | 275 | | 276 | +--------------------------------------+ | 277 | | Location Configuration Server | | 278 | | | | 279 | | | | 280 | | | | 281 | | | | 282 | +------|---------------------'---------+ | 283 +----------|---------------------'------------+ 284 | ' 285 | ' 286 HELD APP 287 | ' 288 Rule Maker - _ +-----------+ +-----------+ 289 o - - | Device | | Location | 290 and as 326 specified in [8] MUST be applied. A default value of "no" SHALL be 327 used for the element. A default value of 24 328 hours SHALL be used for value of any generated 329 PIDF-LO documents. An LCS MAY provide a shorter value for 330 but MUST NOT provide a value longer than 24 hours. 332 Requesting location directly does not always address the requirements 333 of an application. A Device can request a location URI instead of 334 literal location. A Location URI is a URI [23] of any scheme, which 335 a Location Recipient (LR) can use to retrieve LI. A location URI 336 provided by an LCS can be assumed to be globally-addressable; that 337 is, anyone in possession of the URI can access the LCS. This does 338 not in any way suggest that the LCS is bound to reveal the location 339 associated with the location URI. This issue is deemed out of scope 340 for this document. The merits and drawbacks of using a Location URI 341 approach are discussed in [16]. 343 6. Protocol Description 345 As discussed in Section 5, this protocol provides for the retrieval 346 of a Location or a Location URI from an LCS. Three messages are 347 defined to support the location retrieval: locationRequest, 348 locationResponse and error. Messages are defined as XML documents. 350 The Location Request (locationRequest) message is described in 351 Section 6.2. A Location Request from a Device indicates whether a 352 Location (and the specific type of location) and/or a Location URI 353 should be returned. The LCS replies with a response 354 (locationResponse), including a PIDF-LO document and/or one or more 355 Location URIs in case of success, or an error message in case of an 356 error. 358 A MIME type "application/held+xml" is registered in Section 12.4 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 LCS uses the source IP address of the 394 location request message as the primary source of identity for the 395 requesting device or target. It is anticipated that other Device 396 identities MAY be provided through schema extensions. The successful 397 response to a location request is a document formed of a 398 "locationResponse" element, unless the request fails, in which case 399 the LCS SHOULD provide an error indication document. 401 6.3. Location Response 403 The response to a Location request MUST contain either a PIDF-LO 404 and/or Location URI(s), depending upon the requested "locationType". 405 The "locationResponse" element MUST include a "code" attribute with a 406 value of "success". A set of predefined error codes are included in 407 Section 7.3. The response is in error if there is a value other than 408 "success", since those MUST be sent using the error message 409 Section 6.4. 411 A Location URI MUST NOT contain any information that could be used to 412 identify the Device or Target. It is RECOMMENDED that a Location URI 413 contain a public address for the LCS and an anonymous identifier, 414 such as a local identifer or unlinked pseudonym. 416 6.4. Indicating Errors 418 In the event of an error, the LCS SHOULD respond to the Device with 419 an error document. The error response applies to all request types 420 and SHOULD also be sent in response to any unrecognized request. 422 An error indication document consists of an "error" element. The 423 "error" element MUST include a "code" attribute that indicates the 424 type of error. A set of predefined error codes are included in 425 Section 7.3. A code of "success" MUST NOT be used in an "error" 426 element. 428 Error responses MAY also include a "message" attribute that can 429 include additional information. This information SHOULD be for 430 diagnostic purposes only, and MAY be in any language. The language 431 of the message SHOULD be indicated with an "xml:lang" attribute. 433 7. Protocol Parameters 435 This section describes, in detail the parameters that are used for 436 this protocol. Table 1 lists the top-level components used within 437 the protocol and where they are mandatory or optional for each of the 438 messages. 440 +------------------------+----------------+-----------------+-------+ 441 | Parameter | Location | Location | Error | 442 | | Request | Response | | 443 +------------------------+----------------+-----------------+-------+ 444 | responseTime | o | | | 445 | (Section 7.1) | | | | 446 | locationType | m | | | 447 | (Section 7.2) | | | | 448 | exact (Section 7.2.1) | o | | | 449 | code (Section 7.3) | | m | m | 450 | message (Section 7.4) | | o | o | 451 | locationURI | | o | | 452 | (Section 7.5) | | | | 453 | expires | | m | | 454 | (Section 7.5.1) | | | | 455 +------------------------+----------------+-----------------+-------+ 457 Table 1: Message Parameter Usage 459 7.1. "responseTime" Parameter 461 The "responseTime" attribute indicates to the LCS how long the Device 462 is prepared to wait for a response. This attribute MAY be added to a 463 Location request message. The value of this attribute is indicative 464 only, the LCS is under no obligation to strictly adhere to the time 465 limit implied; any enforcement of the time limit is left to the 466 requesting Device. 468 This attribute is expressed with a decimal seconds value, which may 469 include a decimal point. It is RECOMMENDED that systems support 470 millisecond precision for this parameter. 472 The LCS MUST provide the most accurate LI that can be determined 473 within the specified interval. This parameter could be used as input 474 when selecting the method of location determination, where multiple 475 such methods exist. If this parameter is absent, then the LCS MUST 476 return the most precise LI it is capable of determining. 478 7.2. "locationType" Parameter 480 The "locationType" element is included in a location request. It 481 contains a list of LI types that are requested by the Device. The 482 following list describes the possible values: 483 any: The LCS SHOULD attempt to provide LI in all forms available to 484 it. This value MUST be assumed as the default if no 485 "locationType" is specified. The LCS SHOULD return location 486 information in a form that is suited for routing and responding to 487 an emergency call in its jurisdiction. The LCS MAY alternatively 488 or additionally return a location URI. 489 geodetic: The LCS SHOULD return a geodetic location for the Target. 490 civic: The LCS SHOULD return a civic address for the Target. Any 491 type of civic address may be returned. The LCS SHOULD ignore this 492 value if a request for jurisdictional or postal civic address has 493 been made and can be satisfied. 494 jurisdictionalCivic: The LCS SHOULD return a jurisdictional civic 495 address for the Target. 496 postalCivic: The LCS SHOULD return a postal civic address for the 497 Target. 498 locationURI: The LCS SHOULD return a location URI for the Target. 500 The LCS SHOULD return the requested location type or types. The LCS 501 MAY provide additional location types, or it MAY provide alternative 502 types if the request cannot be satisfied for a requested location 503 type. If the "exact" attribute is present and set to "true" in a 504 location request, then a successful LCS response MUST provide the 505 requested location type only, with no additional location 506 information. The "exact" attribute has no effect when this element 507 is set to "any". 509 The "SHOULD"-strength requirement on this parameter is included to 510 allow for soft-failover. This enables a fixed client configuration 511 that prefers a specific location type without causing location 512 requests to fail when that location type is unavailable. Unless the 513 "exact" attribute is set, the LCS MUST provide LI in any available 514 form if it is unable to comply with the request. 516 For example, a notebook computer could be configured to retrieve 517 civic addresses, which is usually available from typical home or work 518 situations. However, when using a wireless modem, the LCS might be 519 unable to provide a civic address. 521 7.2.1. "exact" Attribute 523 When the "exact" attribute is set to "true", it indicates to the LCS 524 that the contents of the "locationType" parameter MUST be strictly 525 followed. The default value of "false" allows the LCS the option of 526 returning something beyond what is specified, such as a location URI 527 when only a civic location was requested. 529 A value of "true" indicates that the LCS MUST provide a location of 530 the requested type or types or MUST provide an error. The LCS MUST 531 provide the requested types only and these types SHOULD be specified 532 in the same order as they were requested. The LCS SHOULD handle an 533 exact request that includes a "locationType" element set to "any" as 534 if the "exact" attribute were set to "false". 536 7.3. "code" Parameter 538 All responses MUST contain a response code. The "code" attribute 539 applies to the "error" and "locationResponse" messages. All errors 540 are application-level errors, and MUST only be provided in 541 successfully processed transport-level responses. For example where 542 HTTP is used as the transport, HELD error messages MUST be 543 accompanied by a 200 OK HTTP response. 545 HELD error responses may be one of the following tokens: 546 success: This code indicates that the request was successful. This 547 code MUST not be used for an error response. 548 requestError: This code indicates that the request was badly formed 549 in some fashion. 550 xmlError: This code indicates that the XML content of the request 551 was either badly formed or invalid. 552 generalLcsError: This code indicates that an unspecified error 553 occurred at the LCS. 554 locationUnknown: This code indicates that the LCS could not 555 determine the location of the Device. 556 unsupportedMessage: This code indicates that the request was not 557 supported or understood by the LCS. 558 timeout: This code indicates that the LCS could not satisfy the 559 request within the time specified in the "responseTime" parameter. 560 cannotProvideLiType: This code indicates that the LCS was unable to 561 provide LI of the type or types requested. This code is used when 562 the "exact" attribute on the "locationType" parameter is set to 563 "true". 565 7.4. "message" Parameter 567 The "locationResponse" and "error" messages MAY include a "message" 568 attribute to convey some additional, human-readable information about 569 the result of the request. This message MAY be included in any 570 language, which SHOULD be indicated by the "xml:lang", attribute. 571 The default language is assumed to be English. 573 7.5. "locationURI" Parameter 575 The "locationURI" element includes a single Location URI. Each 576 Location URI that is allocated by the LCS is unique to the device 577 that is requesting it. 579 A "locationResponse" message MAY contain any number of "locationURI" 580 elements. It is RECOMMENDED that the LCS allocate a Location URI for 581 each scheme that it supports and that each scheme is present only 582 once. URI schemes and their secure variants such as http and https 583 should be regarded as two separate schemes. 585 7.5.1. "expires" Parameter 587 The "expires" attribute indicates the time at which the Location URI 588 provided by the LCS will expire. This attribute is included in the 589 "locationResponse" message only. 591 Responses to Locations requests for Location URIs MUST include the 592 expiry time of the Location URI. 594 8. XML Schema 596 This section gives the XML Schema Definition [12] of the 597 "application/held+xml" format. This is presented as a formal 598 definition of the "application/held+xml" format. Note that the XML 599 Schema definition is not intended to be used with on-the-fly 600 validation of the presence XML document. 602 603 615 616 617 619 This document defines HELD messages. 621 622 624 626 628 631 633 636 637 638 639 640 641 643 644 646 647 648 650 651 652 653 654 655 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 681 682 683 684 686 687 688 690 691 692 693 694 695 696 697 698 699 700 701 702 704 705 706 707 708 709 711 712 713 714 715 716 717 718 720 722 723 724 725 727 729 730 731 732 733 734 737 739 740 741 742 744 747 748 749 750 locationRequest message requests a location 751 and/or a location URI. locationType being requested 752 is specified as an element. A locationURI is explicitly 753 requested by setting the locationURI attribute to true. 754 755 757 758 759 760 761 764 766 767 768 769 771 774 776 9. HTTP Binding 778 This section defines an HTTP [3] binding for this protocol, which all 779 conforming implementations MUST support. This binding takes the form 780 of a Web Service (WS) that can be described by the Web Services 781 Description Language (WSDL) document in Section 9.1. 783 The request is carried in this binding as the body of an HTTP POST 784 request. The MIME type of both request and response bodies should be 785 "application/held+xml". 787 The LCS populates the HTTP headers so that they are consistent with 788 the contents of the message. In particular, the "expires" and cache 789 control headers are used to control the caching of any PIDF-LO 790 document or Location URIs. The HTTP status code SHOULD have the same 791 first digit as any "locationResponse" or "error" body included, and 792 it SHOULD indicate a 2xx series response when a PIDF-LO document or 793 Location URI is included. 795 This binding also includes a default behaviour, which is triggered by 796 a GET request, or a POST with no request body. If either of these 797 queries are received, the LCS MUST attempt to provide either a 798 PIDF-LO document or a Location URI, as if the request was a location 799 request. 801 This binding MUST use TLS as described in [4]. TLS provides message 802 integrity and privacy between Device and LCS. The LCS MUST use the 803 server authentication method described in [4]; the Device MUST fail a 804 request if server authentication fails, except in the event of an 805 emergency. 807 9.1. HTTP Binding WSDL 809 The following WSDL 2.0 [27] document describes the HTTP binding for 810 this protocol. Actual service instances MUST provide a "service" 811 with at least one "endpoint" that implements the "heldHTTP" binding. 812 A service description document MAY include this schema directly or by 813 using the "import" or "include" directives. 815 816 825 826 This document describes the basic HELD sighting web service. 827 Please refer to RFCXXXX for details. 828 [[NOTE TO RFC-EDITOR: Please replace XXXX with the RFC number 829 for this specification and remove this note.]] 830 832 833 834 836 837 838 840 842 843 844 845 846 848 851 852 853 855 857 864 865 866 867 869 871 10. Security Considerations 873 The threat model for this protocol assumes that the LCS exists within 874 the same administrative domain as the Device. The LCS requires 875 access to network information so that it can determine Location. 876 Therefore, the LCS can use network information to protect against a 877 number of the possible attacks. 879 Specific requirements and security considerations for location 880 acquisition protocols are provided in [11] including that the LCP 881 MUST NOT assume prior network access authentication, which is 882 addressed in Section 10.2 884 An in-depth discussion of the security considerations applicable to 885 the use of Location URIs and by-reference provision of LI is included 886 in [16]. 888 10.1. Return Routability 890 It is RECOMMENDED that Location Configuration Servers use return 891 routability rather than requiring Device authentication. Device 892 authentication SHOULD NOT be required due to the administrative 893 challenge of issuing and managing of client credentials, particularly 894 when networks allow visiting users to attach devices. However, the 895 LCS MAY require any form of authentication as long as these factors 896 are considered. 898 Addressing information used in a request to the LCS is used to 899 determine the identity of the Device, and to address a response. 900 This ensures that a Device can only request its own LI. 902 A temporary spoofing of IP address could mean that a device could 903 request a Location URI that would result in another Device's 904 location. One or more of the follow approaches are RECOMMENDED to 905 limit this exposure: 906 o Location URIs SHOULD have a limited lifetime, as reflected by the 907 value for the expires element (Section 7.5.1). 908 o The network SHOULD have mechanisms that protect against IP address 909 spoofing. 910 o The LCS SHOULD ensure that requests can only originate from within 911 its administrative domain. 912 o The LCS and network SHOULD be configured so that the LCS is made 913 aware of Device movement within the network and addressing 914 changes. If the LCS detects a change in the network, then all 915 location URIs MUST be invalidated. 917 The above measures are dependent on network configuration and SHOULD 918 be considered with circumstances in mind. For instance, in a fixed 919 internet access, providers may be able to restrict the allocation of 920 IP addresses to a single physical line, ensuring that spoofing is not 921 possible; in such an environment, other measures may not be 922 necessary. 924 10.2. Transaction Layer Security 926 All bindings for this protocol MUST ensure that messages are 927 adequately protected against eavesdropping and modification. 928 Bindings MUST also provide a means of authenticating the LCS. 930 It is RECOMMENDED that all bindings also use TLS [2]. 932 For the HTTP binding, TLS MUST be used. TLS provides protection 933 against eavesdropping and modification. The server authentication 934 methods described in HTTP on TLS [4] MUST be used. 936 11. Examples 938 11.1. Simple HTTP Binding Example Messages 940 The examples in this section show a complete HTTP message that 941 includes the HELD request or response document. 943 This example shows the most basic request for a LO. This uses the 944 GET feature described by the HTTP binding. This example assumes that 945 the LCS service exists at the URL "https://lcs.example.com/location". 947 GET /location HTTP/1.1 948 Host: lcs.example.com 949 Accept:application/held+xml, 950 application/xml;q=0.8, 951 text/xml;q=0.7 952 Accept-Charset: UTF-8,* 954 The GET request is exactly identical to a minimal POST request that 955 includes an empty "locationRequest" element. 957 POST /location HTTP/1.1 958 Host: lcs.example.com 959 Accept: application/held+xml, 960 application/xml;q=0.8, 961 text/xml;q=0.7 962 Accept-Charset: UTF-8,* 963 Content-Type: application/held+xml 964 Content-Length: 87 966 967 969 The successful response to either of these requests is a PIDF-LO 970 document. The following response shows a minimal PIDF-LO response. 972 HTTP/1.x 200 OK 973 Server: Example LCS 974 Date: Tue, 10 Jan 2006 03:42:29 GMT 975 Expires: Tue, 10 Jan 2006 03:42:29 GMT 976 Cache-control: private 977 Content-Type: application/held+xml 978 Content-Length: 594 980 981 984 986 987 988 989 990 992 -34.407 150.88001 993 994 995 996 997 2006-01-11T03:42:28+00:00 998 999 1000 1001 2006-01-10T03:42:28+00:00 1002 1003 1004 1006 The error response to either of these requests is an error document. 1007 The following response shows an example error response. 1009 HTTP/1.x 200 OK 1010 Server: Example LCS 1011 Expires: Tue, 10 Jan 2006 03:49:20 GMT 1012 Cache-control: private 1013 Content-Type: application/held+xml 1014 Content-Length: 135 1016 1017 1021 Note: To focus on important portions of messages, all examples 1022 following this note do not show HTTP headers or the XML prologue. 1023 In addition, sections of XML not relevant to the example are 1024 replaced with comments. 1026 11.2. Simple Location Request Example 1028 The location request shown below doesn't specify any location types 1029 or response time. 1031 1033 The response to this location request is a list of Location URIs. 1035 1037 1038 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 1039 1040 sips:9769+357yc6s64ceyoiuy5ax3o@ls.example.com 1041 1042 1043 1045 An error response to this location request is shown below: 1047 1051 11.3. Location Request Example for Multiple Location Types 1053 The following Location Request message includes a request for 1054 geodetic, jurisdictional civic and any Location URIs. 1056 1057 1058 geodetic 1059 jurisdictionalCivic 1060 locationURI 1061 1062 1064 The corresponding Location Response message includes the requested 1065 location information, including two location URIs. 1067 1069 1070 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 1071 1072 sips:9769+357yc6s64ceyoiuy5ax3o@ls.example.com: 1073 1074 1075 1077 1078 1079 1080 1081 1085 -34.407242 150.882518 1086 30 1087 1088 1089 1092 AU 1093 NSW 1094 Wollongong 1095 Gwynneville 1096 Northfield Avenue 1097 University of Wollongong 1098 2 1099 Andrew Corporation 1100 2500 1101 39 1102 WS-183 1103 U40 1104 1105 1106 1107 false 1108 2007-05-25T12:35:02+10:00 1109 1110 1111 Wiremap 1112 1113 1114 2007-05-24T12:35:02+10:00 1115 1116 1117 1119 11.4. Sample LCS WSDL Document 1121 The following WSDL document demonstrates how a WSDL document can be 1122 created for a specific service, in this case, a service at the URI 1123 "https://lcs.example.com/location". 1125 1126 1131 1134 1135 1138 1140 1142 12. IANA Considerations 1144 This document registers an XML namespace and schema and the 1145 "application/held+xml" MIME type. 1147 12.1. URN Sub-Namespace Registration for 1148 urn:ietf:params:xml:ns:geopriv:held 1150 This section registers a new XML namespace, 1151 "urn:ietf:params:xml:ns:geopriv:held", as per the guidelines in [6]. 1152 URI: urn:ietf:params:xml:ns:geopriv:held 1153 Registrant Contact: IETF, GEOPRIV working group, 1154 (geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com). 1155 XML: 1157 BEGIN 1158 1159 1161 1162 1163 HELD Messages 1164 1165 1166

Namespace for HELD Messages

1167

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

1168 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 1169 with the RFC number for this specification.]] 1170

See RFCXXXX.

1171 1172 1173 END 1175 12.2. XML Schema Registration 1177 This section registers an XML schema as per the guidelines in [6]. 1178 URI: urn:ietf:params:xml:schema:geopriv:held 1179 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 1180 Mary Barnes (mary.barnes@nortel.com). 1181 Schema: The XML for this schema can be found as the entirety of 1182 Section 8 of this document. 1184 12.3. URN Sub-Namespace Registration for 1185 urn:ietf:params:xml:ns:geopriv:held:http 1187 This section registers a new XML namespace, 1188 "urn:ietf:params:xml:ns:geopriv:held:http", as per the guidelines in 1189 [6]. 1191 URI: urn:ietf:params:xml:ns:geopriv:held:http 1192 Registrant Contact: IETF, GEOPRIV working group, 1193 (geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com). 1194 XML: 1196 BEGIN 1197 1198 1200 1201 1202 HELD HTTP Binding WS 1203 1204 1205

Namespace for HELD HTTP Binding WS

1206

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

1207 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 1208 with the RFC number for this specification.]] 1209

See RFCXXXX.

1210 1211 1212 END 1214 12.4. MIME Media Type Registration for 'application/held+xml' 1216 This section registers the "application/held+xml" MIME type. 1217 To: ietf-types@iana.org 1218 Subject: Registration of MIME media type application/held+xml 1219 MIME media type name: application 1220 MIME subtype name: held+xml 1221 Required parameters: (none) 1222 Optional parameters: charset 1223 Indicates the character encoding of enclosed XML. Default is 1224 UTF-8. 1225 Encoding considerations: Uses XML, which can employ 8-bit 1226 characters, depending on the character encoding used. See RFC 1227 3023 [20], section 3.2. 1228 Security considerations: This content type is designed to carry 1229 protocol data related to the location of an entity, which could 1230 include information that is considered private. Appropriate 1231 precautions should be taken to limit disclosure of this 1232 information. 1233 Interoperability considerations: This content type provides a basis 1234 for a protocol 1236 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please 1237 replace XXXX with the RFC number for this specification.]] 1238 Applications which use this media type: Location information 1239 providers and consumers. 1240 Additional Information: Magic Number(s): (none) 1241 File extension(s): .xml 1242 Macintosh File Type Code(s): (none) 1243 Person & email address to contact for further information: Mary 1244 Barnes 1245 Intended usage: LIMITED USE 1246 Author/Change controller: This specification is TBD 1247 Other information: This media type is a specialization of 1248 application/xml [20], and many of the considerations described 1249 there also apply to application/held+xml. 1251 13. Contributors 1253 James Winterbottom, Martin Thomson and Barbara Stark are the authors 1254 of the original document, from which this WG document was derived. 1255 Their contact information is included in the Author's address 1256 section. James Winterbottom also contributed to the WG document. 1258 14. Acknowledgements 1260 The author/contributors would like to thank the following people for 1261 their constructive input to this document (in alphabetical order): 1262 Nadine Abbott, Eric Arolick, Guy Caron, Martin Dawson, Jerome 1263 Grenier, Neil Justusson, Tat Lam, Patti McCalmont, Perry Prozeniuk, 1264 John Schnizlein, Henning Schulzrinne, Ed Shrum, and Hannes 1265 Tschofenig. 1267 15. Changes since last Version 1269 NOTE TO THE RFC-Editor: Please remove this section prior to 1270 publication as an RFC. 1272 Changes from WG 00 to 01: 1274 1) heldResponse renamed to locationResponse. 1276 2) Changed namespace references for the PIDF-LO geoShape in the 1277 schema to match the agreed GML PIDF-LO Geometry Shape Application 1278 Schema. 1280 3) Removed "options" element - leaving optionality/extensibility to 1281 XML mechanisms. 1283 4) Changed error codes to be enumerations and not redefinitions of 1284 HTTP response codes. 1286 5) Updated schema/examples for the above and removed some remnants of 1287 the context element. 1289 6) Clarified the definition of "Location Information (LI)" to include 1290 a reference to the location (to match the XML schema and provide 1291 consistency of usage throughout the document). Added an additional 1292 statement in section 7.2 (locationType) to clarify that LCS MAY also 1293 return a Location URI. 1295 7) Modifed the definition of "Location Configuration Server (LCS)" to 1296 be consistent with the current definiton in the requirements 1297 document. 1299 8) Updated Location Response (section 6.3) to remove reference to 1300 context and discuss the used of a local identifier or unlinked 1301 pseudonym in providing privacy/security. 1303 9) Clarified that the source IP address in the request is used as the 1304 identifier for the target/device for the HELD protocol as defined in 1305 this document. 1307 10) Miscellaneous editorial clarifications. 1309 16. References 1311 16.1. Normative References 1313 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1314 Levels", BCP 14, RFC 2119, March 1997. 1316 [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1317 RFC 2246, January 1999. 1319 [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 1320 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 1321 HTTP/1.1", RFC 2616, June 1999. 1323 [4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1325 [5] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 1326 Language) XML-Signature Syntax and Processing", RFC 3275, 1327 March 2002. 1329 [6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1330 January 2004. 1332 [7] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 1333 Polk, "Geopriv Requirements", RFC 3693, February 2004. 1335 [8] Peterson, J., "A Presence-based GEOPRIV Location Object 1336 Format", RFC 4119, December 2005. 1338 [9] Thomson, M. and J. Winterbottom, "Revised Civic Location Format 1339 for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in 1340 progress), February 2007. 1342 [10] Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification, 1343 Considerations and Recommendations", 1344 draft-ietf-geopriv-pdif-lo-profile-08 (work in progress), 1345 July 2007. 1347 [11] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location 1348 Configuration Protocol; Problem Statement and Requirements", 1349 draft-ietf-geopriv-l7-lcp-ps-02 (work in progress), April 2007. 1351 [12] Thompson, H., Mendelsohn, N., Maloney, M., and D. Beech, "XML 1352 Schema Part 1: Structures Second Edition", World Wide Web 1353 Consortium Recommendation REC-xmlschema-1-20041028, 1354 October 2004, 1355 . 1357 [13] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second 1358 Edition", World Wide Web Consortium Recommendation REC- 1359 xmlschema-2-20041028, October 2004, 1360 . 1362 [14] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, 1363 "Geographic information - Geography Markup Language (GML)", 1364 OpenGIS 03-105r1, April 2004, 1365 . 1367 [15] Thomson, M. and J. Winterbottom, "Discovering the Local 1368 Location Information Server (LIS)", 1369 draft-thomson-geopriv-lis-discovery-00 (work in progress), 1370 February 2007. 1372 [16] Marshall, R., "Requirements for a Location-by-Reference 1373 Mechanism used in Location Configuration and Conveyance", 1374 draft-marshall-geopriv-lbyr-requirements-01 (work in progress), 1375 March 2007. 1377 16.2. Informative References 1379 [17] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 1380 September 1981. 1382 [18] Myers, J., "Simple Authentication and Security Layer (SASL)", 1383 RFC 2222, October 1997. 1385 [19] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence 1386 and Instant Messaging", RFC 2778, February 2000. 1388 [20] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", 1389 RFC 3023, January 2001. 1391 [21] Rose, M., "The Blocks Extensible Exchange Protocol Core", 1392 RFC 3080, March 2001. 1394 [22] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1395 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1396 Session Initiation Protocol", RFC 3261, June 2002. 1398 [23] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1399 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 1400 January 2005. 1402 [24] Polk, J. and B. Rosen, "Session Initiation Protocol Location 1403 Conveyance", draft-ietf-sip-location-conveyance-07 (work in 1404 progress), February 2007. 1406 [25] Gudgin, M., Mendelsohn, N., Nielsen, H., Moreau, J., and M. 1407 Hadley, "SOAP Version 1.2 Part 1: Messaging Framework", World 1408 Wide Web Consortium FirstEdition REC-soap12-part1-20030624, 1409 June 2003, 1410 . 1412 [26] Mendelsohn, N., Nielsen, H., Hadley, M., Gudgin, M., and J. 1413 Moreau, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Web 1414 Consortium FirstEdition REC-soap12-part2-20030624, June 2003, 1415 . 1417 [27] Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, "Web 1418 Services Description Language (WSDL) Version 2.0 Part 1: Core 1419 Language", W3C CR CR-wsdl20-20060106, January 2006. 1421 Appendix A. HELD Compliance to IETF LCP requirements 1423 This appendix describes HELD's compliance to the requirements 1424 specified in the [11]. 1426 A.1. L7-1: Identifier Choice 1428 "The LIS MUST be presented with a unique identifier of its own 1429 addressing realm associated in some way with the physical location of 1430 the end host." 1432 COMPLY 1434 HELD uses the IP address of the location request message as the 1435 primary source of identity for the requesting device or target. This 1436 identity can be used with other contextual network information to 1437 provide a physical location for the Target for many network 1438 deployments. There may be network deployments where an IP address 1439 alone is insufficient to identify a Target in a network. However, 1440 any necessary identity extensions for these networks is beyond the 1441 scope of this document. 1443 A.2. L7-2: Mobility Support 1445 "The GEOPRIV Layer 7 Location Configuration Protocol MUST support a 1446 broad range of mobility from devices that can only move between 1447 reboots, to devices that can change attachment points with the impact 1448 that their IP address is changed, to devices that do not change their 1449 IP address while roaming, to devices that continuously move by being 1450 attached to the same network attachment point." 1452 COMPLY 1454 Mobility support is inherently a characteristic of the access network 1455 technology and HELD is designed to be access network agnostic. 1456 Consequently HELD complies with this requirement. In addition HELD 1457 provides specific support for mobile environments by providing an 1458 optional responseTime attribute in location request messages. 1459 Wireless networks often have several different mechanisms at their 1460 disposal for position determination (e.g. Assisted GPS versus 1461 location based on serving base station identity), each providing 1462 different degrees of accuracy and taking different amounts of time to 1463 yield a result. The responseTime parameter provides the LIS with a 1464 criterion which it can use to select a location determination 1465 technique. 1467 A.3. L7-3: Layer 7 and Layer 2/3 Provider Relationship 1469 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1470 MUST NOT assume a business or trust relationship between the provider 1471 of application layer (e.g., SIP, XMPP, H.323) provider and the access 1472 network provider operating the LIS." 1474 COMPLY 1476 HELD describes a location acquisition protocol and has no 1477 dependencies on how location is used once it has been acquired. 1478 Location acquisition using HELD is subject to the restrictions 1479 described in Section 10. 1481 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship 1483 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1484 MUST assume that there is a trust and business relationship between 1485 the L2 and the L3 provider. The L3 provider operates the LIS and 1486 needs to obtain location information from the L2 provider since this 1487 one is closest to the end host. If the L2 and L3 provider for the 1488 same host are different entities, they cooperate for the purposes 1489 needed to determine end system locations." 1491 COMPLY 1493 HELD was specifically designed with this model in mind and readily 1494 allows itself to chaining requests between operators without a change 1495 in protocol being required. HELD is a webservices protocol it can be 1496 bound to transports other than HTTP, such as BEEP. Using a transport 1497 like BEEP for HELD offers the option of high request throughput over 1498 a dedicated connection between an L3 provider and an L2 provider 1499 without incurring the serial restriction imposed by HTTP. This is 1500 less easy to do with protocols that do not decouple themselves from 1501 the transport. 1503 A.5. L7-5: Legacy Device Considerations 1505 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1506 MUST consider legacy residential NAT devices and NTEs in an DSL 1507 environment that cannot be upgraded to support additional protocols, 1508 for example to pass additional information through DHCP." 1510 COMPLY 1512 HELD is an application protocol and operates on top of IP. A HELD 1513 request from a host behind a residential NAT will traverse the NAT 1514 acquiring the external address of the home router. The location 1515 provided to the host therefore will be the address of the home router 1516 in this circumstance. No changes are required to the home router in 1517 order to support this function, HELD was designed specifically to 1518 address this deployment scenario. 1520 A.6. L7-6: VPN Awareness 1522 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1523 MUST assume that at least one end of a VPN is aware of the VPN 1524 functionality. In an enterprise scenario, the enterprise side will 1525 provide the LIS used by the client and can thereby detect whether the 1526 LIS request was initiated through a VPN tunnel." 1528 COMPLY 1530 HELD does not preclude a LIS on the far end of a VPN tunnel being 1531 aware that the client request is occurring over that tunnel. It also 1532 does not preclude a client device from accessing a LIS serving the 1533 local physical network and subsequently using the location 1534 information with an application that is accessed over a VPN tunnel. 1536 A.7. L7-7: Network Access Authentication 1538 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1539 MUST NOT assume prior network access authentication." 1541 COMPLY 1543 HELD makes no assumptions about prior network access authentication. 1544 HELD strongly recommends the use of TLS with server-side certificates 1545 for communication between the end-point and the LIS. There is no 1546 requirement for the end-point to authenticate with the LIS. 1548 A.8. L7-8: Network Topology Unawareness 1550 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1551 MUST NOT assume end systems being aware of the access network 1552 topology. End systems are, however, able to determine their public 1553 IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP." 1555 COMPLY 1557 HELD makes no assumption about the network topology. HELD doesn't 1558 require that the device know its external IP address, except where 1559 that is required for discovery of the LCS. 1561 A.9. L7-9: Discovery Mechanism 1563 "The L7 LCP MUST define a single mandatory to implement discovery 1564 mechanism." 1566 COMPLY 1567 HELD uses the discovery mechanism in [15]. 1569 Authors' Addresses 1571 Mary Barnes (editor) 1572 Nortel 1573 2201 Lakeside Blvd 1574 Richardson, TX 1576 Email: mary.barnes@nortel.com 1578 James Winterbottom 1579 Andrew 1580 PO Box U40 1581 Wollongong University Campus, NSW 2500 1582 AU 1584 Phone: +61 2 4221 2938 1585 Email: james.winterbottom@andrew.com 1586 URI: http://www.andrew.com/ 1588 Martin Thomson 1589 Andrew 1590 PO Box U40 1591 Wollongong University Campus, NSW 2500 1592 AU 1594 Phone: +61 2 4221 2915 1595 Email: martin.thomson@andrew.com 1596 URI: http://www.andrew.com/ 1598 Barbara Stark 1599 BellSouth 1600 Room 7A41 1601 725 W Peachtree St. 1602 Atlanta, GA 30308 1603 US 1605 Email: barbara.stark@bellsouth.com 1607 Full Copyright Statement 1609 Copyright (C) The IETF Trust (2007). 1611 This document is subject to the rights, licenses and restrictions 1612 contained in BCP 78, and except as set forth therein, the authors 1613 retain all their rights. 1615 This document and the information contained herein are provided on an 1616 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1617 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1618 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1619 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1620 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1621 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1623 Intellectual Property 1625 The IETF takes no position regarding the validity or scope of any 1626 Intellectual Property Rights or other rights that might be claimed to 1627 pertain to the implementation or use of the technology described in 1628 this document or the extent to which any license under such rights 1629 might or might not be available; nor does it represent that it has 1630 made any independent effort to identify any such rights. Information 1631 on the procedures with respect to rights in RFC documents can be 1632 found in BCP 78 and BCP 79. 1634 Copies of IPR disclosures made to the IETF Secretariat and any 1635 assurances of licenses to be made available, or the result of an 1636 attempt made to obtain a general license or permission for the use of 1637 such proprietary rights by implementers or users of this 1638 specification can be obtained from the IETF on-line IPR repository at 1639 http://www.ietf.org/ipr. 1641 The IETF invites any interested party to bring to its attention any 1642 copyrights, patents or patent applications, or other proprietary 1643 rights that may cover technology that may be required to implement 1644 this standard. Please address the information to the IETF at 1645 ietf-ipr@ietf.org. 1647 Acknowledgment 1649 Funding for the RFC Editor function is provided by the IETF 1650 Administrative Support Activity (IASA).