idnits 2.17.1 draft-ietf-geopriv-http-location-delivery-03.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 1531. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1542. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1549. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1555. 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 -- 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 (November 17, 2007) is 6004 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 1241, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1254, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1274, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1293, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 1299, 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-06 == Outdated reference: A later version (-14) exists of draft-ietf-geopriv-pdif-lo-profile-10 == Outdated reference: A later version (-10) exists of draft-ietf-geopriv-l7-lcp-ps-05 ** 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' == Outdated reference: A later version (-09) exists of draft-ietf-geopriv-lbyr-requirements-01 ** Downref: Normative reference to an Informational draft: draft-ietf-geopriv-lbyr-requirements (ref. '15') -- Obsolete informational reference (is this intentional?): RFC 793 (ref. '16') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 3023 (ref. '18') (Obsoleted by RFC 7303) -- Obsolete informational reference (is this intentional?): RFC 3825 (ref. '20') (Obsoleted by RFC 6225) == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-08 Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 12 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: May 20, 2008 7 November 17, 2007 9 HTTP Enabled Location Delivery (HELD) 10 draft-ietf-geopriv-http-location-delivery-03.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 May 20, 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 is an application-layer protocol that is independent of session- 48 layer. This document describes the use of Hypertext Transfer 49 Protocol (HTTP) as a delivery mechanism for the protocol. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 55 3. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 5 56 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 57 4.1. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 7 58 4.1.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 8 59 4.1.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 8 60 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8 61 5.1. Delivery Protocol . . . . . . . . . . . . . . . . . . . . 9 62 5.2. Location Request . . . . . . . . . . . . . . . . . . . . . 9 63 5.3. Location Response . . . . . . . . . . . . . . . . . . . . 10 64 5.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 10 65 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10 66 6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11 67 6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 11 68 6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 12 69 6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 12 70 6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 13 71 6.5. "locationURI" Parameter . . . . . . . . . . . . . . . . . 13 72 6.5.1. "expires" Parameter . . . . . . . . . . . . . . . . . 13 73 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 8. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 76 9.1. Return Routability . . . . . . . . . . . . . . . . . . . . 18 77 9.2. Transaction Layer Security . . . . . . . . . . . . . . . . 19 78 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 79 10.1. HTTP Example Messages . . . . . . . . . . . . . . . . . . 19 80 10.2. Simple Location Request Example . . . . . . . . . . . . . 22 81 10.3. Location Request Example for Multiple Location Types . . . 23 82 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 83 11.1. URN Sub-Namespace Registration for 84 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 24 85 11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 25 86 11.3. URN Sub-Namespace Registration for 87 urn:ietf:params:xml:ns:geopriv:held:http . . . . . . . . . 25 88 11.4. MIME Media Type Registration for 'application/held+xml' . 26 89 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 90 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 91 14. Changes since last Version . . . . . . . . . . . . . . . . . . 27 92 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 93 15.1. Normative References . . . . . . . . . . . . . . . . . . . 29 94 15.2. Informative References . . . . . . . . . . . . . . . . . . 31 95 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 31 96 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 31 97 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 32 98 A.3. L7-3: ASP and Access Network Provider Relationship . . . . 32 99 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 33 100 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 33 101 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 33 102 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 34 103 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 34 104 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 34 105 A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 34 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 107 Intellectual Property and Copyright Statements . . . . . . . . . . 37 109 1. Introduction 111 The location of a Device is information that is useful for a number 112 of applications. The L7 Location Configuration Protocol (LCP) 113 problem statement and requirements document [11] provides some 114 scenarios in which a Device might rely on its access network to 115 provide the location information, such as fixed environments (e.g., 116 DSL/Cable), mobile networks and wireless access networks. This 117 document describes a protocol that can be used to acquire Location 118 Information (LI) from a Location Information Server (LIS) within an 119 access network. 121 This specification identifies two methods for acquiring LI. Location 122 may be retrieved from a LIS by-value, that is, the Device may acquire 123 a literal location object describing the location of the Device. 124 Alternatively, the Device may request that the LIS provide a location 125 reference in the form of a location URI or set of location URIs, 126 allowing the Device to distribute its LI by-reference. Both of these 127 methods are compatible, and both can be provided concurrently from 128 the same LIS so that application needs can be addressed individually. 130 This specification defines an XML-based protocol that enables the 131 retrieval of LI from a LIS by a Device. This protocol can be bound 132 to any session-layer protocol, particularly those capable of MIME 133 transport. This document describes the use of Hypertext Transfer 134 Protocol (HTTP) as a delivery mechanism for the protocol. 136 2. Conventions & Terminology 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 This document uses the terms (and their acronym forms) Access 143 Provider (AP), Location Information (LI), Location Object (LO), 144 Device, Target, Location Generator (LG), Location Recipient (LR), 145 Rule Maker (RM) and Rule Holder (RH) as defined in RFC 3693, GEOPRIV 146 Requirements [7] . The terms Location Information Server (LIS), 147 Access Network, Access Provider (AP) and Access Network Provider are 148 used in the same context as defined in the L7 LCP Problem statement 149 and Requirements document [11]. The usage of the terms, Civic 150 Location/Address and Geodetic Location follows the usage in many of 151 the referenced documents. 153 3. Overview and Scope 155 This document describes an interface between a Device and a Location 156 Information Server (LIS). The LIS is present within the same 157 administrative domain as the Device (the access network). An Access 158 Provider (AP) operates the LIS so that Devices (and Targets) can 159 retrieve LI. The LIS exists because not all Devices are capable of 160 determining LI, and because, even if a device is able to determine 161 its own LI, it may be more efficient with assistance. This document 162 does not specify how LI is derived. 164 This document is based on the attribution of the LI to a Device and 165 not specifically a person (end user) or Target, based on the premise 166 that location determination technologies are generally designed to 167 locate a device and not a person. It is expected that, for most 168 applications, LI for the device can be used as an adequate substitute 169 for the end user's LI. Since revealing the location of the device 170 almost invariably reveals some information about the location of the 171 user of the device, the same level of privacy protection demanded by 172 a user is required for the device. This approach may require either 173 some additional assurances about the link between device and target, 174 or an acceptance of the limitation that unless the device requires 175 active user authentication, there is no guarantee that any particular 176 individual is using the device at that instant. 178 The following diagram shows the logical configuration of some of the 179 functional elements identified in [7] and the LIS defined in [11] and 180 where this protocol applies, with the Rule Maker and Target 181 represented by the role of the Device. 183 +---------------------------------------------+ 184 | Access Network Provider | 185 | | 186 | +--------------------------------------+ | 187 | | Location Information Server | | 188 | | | | 189 | | | | 190 | | | | 191 | | | | 192 | +------|---------------------'---------+ | 193 +----------|---------------------'------------+ 194 | ' 195 | ' 196 HELD APP 197 | ' 198 Rule Maker - _ +-----------+ +-----------+ 199 o - - | Device | | Location | 200 and as specified in [8] 241 MUST be applied. A default value of "no" SHALL be used for the 242 element. A default value of 24 hours SHALL 243 be used for value of any generated PIDF-LO 244 documents. A LIS MAY provide a shorter value for 245 but MUST NOT provide a value longer than 24 hours. 247 Requesting location directly does not always address the requirements 248 of an application. A Device can request a location URI instead of 249 literal location. A Location URI is a URI [21] of any scheme, which 250 a Location Recipient (LR) can use to retrieve LI. A location URI 251 provided by a LIS can be assumed to be globally-addressable; that is, 252 anyone in possession of the URI can access the LIS. This does not in 253 any way suggest that the LIS is bound to reveal the location 254 associated with the location URI. This issue is deemed out of scope 255 for this document. The merits and drawbacks of using a Location URI 256 approach are discussed in [15]. 258 4.1. Device Identifiers, NAT and VPNs 260 Use of the HELD protocol is subject to the viability of the 261 identifier used by the LIS to determine location. As described in 262 Section 3, this document describes the use of the IP address of the 263 Device as the identifier. When Network Address Translation (NAT), a 264 Virtual Private Network (VPN) or other forms of address modification 265 occur between the Device and the LIS, the location returned could be 266 inaccurate. 268 This is not always the case. For example, a NAT used in a 269 residential Local Area Network (LAN) is typically not a problem. The 270 external IP address used on the Wide Area Network (WAN) side of the 271 NAT is an acceptable identifier for all of the devices in the 272 residence since the covered geographical area is small. 274 On the other hand, if there is a VPN between the Device and the LIS, 275 for example for a teleworker, then the address seen by the LIS might 276 not be the right address to identify the location of the Device. 278 4.1.1. Devices and VPNs 280 To minimize the impact of VPNs, Devices SHOULD perform their HELD 281 query prior to establishing a VPN tunnel. It is RECOMMENDED that 282 discovery [14] and an initial query are performed before establishing 283 the VPN. 285 Devices that establish VPN connections for use by other devices 286 inside a LAN or other closed network MAY act as a HELD LIS for those 287 other devices. Devices within the closed network are not necessarily 288 able to detect the presence of the VPN and are reliant on the VPN 289 device. To this end, a VPN device SHOULD provide the address, of the 290 LIS server it provides, in response to discovery queries. 292 It could also be useful for a VPN device to act as a LIS for other 293 location configuration options such as Dynamic Host Configuration 294 Protocol (DHCP)[20] or Link Layer Discovery Protocol - Media Endpoint 295 Discovery (LLDP-MED) [23]. VPN devices that act as a LIS MAY acquire 296 their own location using HELD. 298 4.1.2. LIS Handling of NATs and VPNs 300 A LIS MUST NOT provide location information to a Device if it cannot 301 provide accurate information. This applies where the Device uses a 302 VPN connection or is behind a NAT that serves a large geographic area 303 or multiple geographic locations (for example, a NAT used by an 304 enterprise to connect their private network to the Internet). The 305 LIS needs to be configured to recognize identifiers that represent 306 these conditions. 308 LIS operators have a large role in ensuring the best possible 309 environment for location determination. The LIS operator needs to 310 ensure that the LIS is properly configured with identifiers that fall 311 within NATs and VPNs. In order to serve a Device on a remote side of 312 a NAT or VPN a LIS needs to have a presence on the side of the NAT or 313 VPN nearest the Device. 315 5. Protocol Description 317 As discussed in Section 4, this protocol provides for the retrieval 318 of a Location or a Location URI from a LIS. Three messages are 319 defined to support the location retrieval: locationRequest, 320 locationResponse and error. Messages are defined as XML documents. 322 The Location Request (locationRequest) message is described in 323 Section 5.2. A Location Request message from a Device indicates 324 whether a Location (and the specific type of location) and/or a 325 Location URI should be returned. The LIS replies with a response 326 (locationResponse), including a PIDF-LO document and/or one or more 327 Location URIs in case of success, or an error message in case of an 328 error. 330 A MIME type "application/held+xml" is registered in Section 11.4 to 331 distinguish HELD messages from other XML document bodies. This 332 specification follows the recommendations and conventions described 333 in [18], including the naming convention of the type ('+xml' suffix) 334 and the usage of the 'charset' parameter. 336 Section 6 contains a more thorough description of the protocol 337 parameters, valid values, and how each should be handled. Section 7 338 contains a more specific definition of the structure of these 339 messages in the form of an XML Schema [12]. 341 5.1. Delivery Protocol 343 The HELD protocol is an application-layer protocol that is defined 344 independently of any lower layers. This means that any protocol can 345 be used to transport this protocol providing that it can provide a 346 few basic features: 347 o The protocol must have acknowledged delivery. 348 o The protocol must be able to correlate a response with a request. 349 o The protocol must provide authentication, privacy and protection 350 against modification. 351 This document describes the use of a combination of HTTP [3], TLS [2] 352 and TCP [16] in Section 8 . 354 5.2. Location Request 356 A location request message is sent from the Device to the LIS when it 357 requires LI. The type of LI that a Device requests is determined by 358 the type of LI that is included in the "locationType" element. 360 The location request is made by sending a document formed of a 361 "locationRequest" element. The LIS uses the source IP address of the 362 location request message as the primary source of identity for the 363 requesting device or target. It is anticipated that other Device 364 identities MAY be provided through schema extensions. The successful 365 response to a location request message is a document formed of a 366 "locationResponse" element, unless the request fails, in which case 367 the LIS MUST provide an error indication document. 369 The LIS MUST ignore any part of a location request message that it 370 does not understand. 372 5.3. Location Response 374 The response to a Location request MUST contain either a PIDF-LO 375 and/or Location URI(s), depending upon the requested "locationType". 377 5.4. Indicating Errors 379 In the event of an error, the LIS MUST respond to the Device with an 380 error document. The error response applies to all request types and 381 MUST also be sent in response to any unrecognized request. 383 An error indication document consists of an "error" element. The 384 "error" element MUST include a "code" attribute that indicates the 385 type of error. A set of predefined error codes are included in 386 Section 6.3. 388 Error responses MAY also include a "message" attribute that can 389 include additional information. This information SHOULD be for 390 diagnostic purposes only, and MAY be in any language. The language 391 of the message SHOULD be indicated with an "xml:lang" attribute. 393 6. Protocol Parameters 395 This section describes, in detail the parameters that are used for 396 this protocol. Table 1 lists the top-level components used within 397 the protocol and where they are mandatory or optional for each of the 398 messages. 400 +------------------------+----------------+-----------------+-------+ 401 | Parameter | Location | Location | Error | 402 | | Request | Response | | 403 +------------------------+----------------+-----------------+-------+ 404 | responseTime | o | | | 405 | (Section 6.1) | | | | 406 | locationType | o | | | 407 | (Section 6.2) | | | | 408 | exact (Section 6.2.1) | o | | | 409 | code (Section 6.3) | | m | m | 410 | message (Section 6.4) | | | o | 411 | locationURI | | o | | 412 | (Section 6.5) | | | | 413 | expires | | m | | 414 | (Section 6.5.1) | | | | 415 +------------------------+----------------+-----------------+-------+ 417 Table 1: Message Parameter Usage 419 6.1. "responseTime" Parameter 421 The "responseTime" parameter is optional and indicates to the LIS how 422 long the Device is prepared to wait for a response and/or the purpose 423 for which the Device needs the location. In the case of emergency 424 services, the purpose of obtaining the LI could be either for routing 425 a call to the appropriate PSAP or indicating the location to which 426 responders should be dispatched. The time values defined for those 427 purposes, emergencyRouting and emergencyDispatch, will likely be 428 governed by jurisdictional policies, and SHOULD be configurable on 429 the LIS. 431 The value of the "responseTime" parameter is indicative only and the 432 LIS is under no obligation to strictly adhere to the time limit 433 implied; any enforcement of the time limit is left to the requesting 434 Device. The "responseTime" parameter is expressed with a decimal 435 seconds value, which may include a decimal point. It is RECOMMENDED 436 that systems support millisecond precision for this parameter. The 437 LIS SHOULD provide the most accurate LI that can be determined within 438 the specified interval for the specific service. 440 The LIS MAY use the value of the "responseTime" parameter as input 441 when selecting the method of location determination, where multiple 442 such methods exist. If this parameter is absent, then the LIS MUST 443 return the most precise LI it is capable of determining, with the 444 time interval being implementation dependent. 446 6.2. "locationType" Parameter 448 The "locationType" element MAY be included in a location request 449 message. It contains a list of LI types that are requested by the 450 Device. The following list describes the possible values: 451 any: The LIS SHOULD attempt to provide LI in all forms available to 452 it. This value MUST be assumed as the default if no 453 "locationType" is specified. The LIS SHOULD return location 454 information in a form that is suited for routing and responding to 455 an emergency call in its jurisdiction. The LIS MAY alternatively 456 or additionally return a location URI. 458 geodetic: The LIS SHOULD return a geodetic location for the Target. 459 civic: The LIS SHOULD return a civic address for the Target. Any 460 type of civic address may be returned. 461 locationURI: The LIS SHOULD return a location URI for the Target. 463 The LIS SHOULD return the requested location type or types. The LIS 464 MAY provide additional location types, or it MAY provide alternative 465 types if the request cannot be satisfied for a requested location 466 type. If the "exact" attribute is present and set to "true" in a 467 location request, then a successful LIS response MUST provide the 468 requested location type only, with no additional location 469 information. The "exact" attribute has no effect when this element 470 is set to "any". 472 The "SHOULD"-strength requirement on this parameter is included to 473 allow for soft-failover. This enables a fixed client configuration 474 that prefers a specific location type without causing location 475 requests to fail when that location type is unavailable. Unless the 476 "exact" attribute is set, the LIS MUST provide LI in any available 477 form if it is unable to comply with the request. 479 For example, a notebook computer could be configured to retrieve 480 civic addresses, which is usually available from typical home or work 481 situations. However, when using a wireless modem, the LIS might be 482 unable to provide a civic address and thus provides a geodetic 483 address. 485 6.2.1. "exact" Attribute 487 When the "exact" attribute is set to "true", it indicates to the LIS 488 that the contents of the "locationType" parameter MUST be strictly 489 followed. The default value of "false" allows the LIS the option of 490 returning something beyond what is specified, such as a location URI 491 when only a civic location was requested. 493 A value of "true" indicates that the LIS MUST provide a location of 494 the requested type or types or MUST provide an error. The LIS MUST 495 provide the requested types only. The LIS MUST handle an exact 496 request that includes a "locationType" element set to "any" as if the 497 "exact" attribute were set to "false". 499 6.3. "code" Parameter 501 All "error" responses MUST contain a response code. All errors are 502 application-level errors, and MUST only be provided in successfully 503 processed transport-level responses. For example where HTTP is used 504 as the transport, HELD error messages MUST be accompanied by a 200 OK 505 HTTP response. 507 HELD error responses may be one of the following tokens: 508 requestError: This code indicates that the request was badly formed 509 in some fashion. 510 xmlError: This code indicates that the XML content of the request 511 was either badly formed or invalid. 512 generalLisError: This code indicates that an unspecified error 513 occurred at the LIS. 514 locationUnknown: This code indicates that the LIS could not 515 determine the location of the Device. 516 unsupportedMessage: This code indicates that the request was not 517 supported or understood by the LIS. 518 timeout: This code indicates that the LIS could not satisfy the 519 request within the time specified in the "responseTime" parameter. 520 cannotProvideLiType: This code indicates that the LIS was unable to 521 provide LI of the type or types requested. This code is used when 522 the "exact" attribute on the "locationType" parameter is set to 523 "true". 525 6.4. "message" Parameter 527 The "error" message MAY include a "message" attribute to convey some 528 additional, human-readable information about the result of the 529 request. This message MAY be included in any language, which SHOULD 530 be indicated by the "xml:lang", attribute. The default language is 531 assumed to be English. 533 6.5. "locationURI" Parameter 535 The "locationURI" element includes a single Location URI. Each 536 Location URI that is allocated by the LIS is unique to the device 537 that is requesting it. 539 A "locationResponse" message MAY contain any number of "locationURI" 540 elements. It is RECOMMENDED that the LIS allocate a Location URI for 541 each scheme that it supports and that each scheme is present only 542 once. URI schemes and their secure variants such as http and https 543 MUST be regarded as two separate schemes. 545 A "locationURI" MUST NOT contain any information that could be used 546 to identify the Device or Target. It is RECOMMENDED that a 547 "locationURI" contain a public address for the LIS and an anonymous 548 identifier, such as a local identifer or unlinked pseudonym. 550 6.5.1. "expires" Parameter 552 The "expires" attribute is optional and is only included in a 553 "locationResponse" message when a Location URI is included. The 554 "expires" attribute indicates the time at which the Location URI 555 provided by the LIS will expire. 557 Responses to Locations requests for Location URIs MUST include the 558 expiry time of the Location URI. 560 7. XML Schema 562 This section gives the XML Schema Definition [12] of the 563 "application/held+xml" format. This is presented as a formal 564 definition of the "application/held+xml" format. Note that the XML 565 Schema definition is not intended to be used with on-the-fly 566 validation of the presence XML document. 568 569 577 578 579 581 This document defines HELD messages. 582 583 585 587 588 589 590 591 592 594 595 597 598 599 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 618 619 620 621 622 623 624 625 626 628 629 630 631 632 633 634 635 636 637 638 639 641 642 643 644 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 662 663 664 665 666 667 669 670 671 672 674 675 676 677 678 680 682 683 684 685 687 689 690 691 692 693 694 697 699 700 701 702 704 707 709 710 711 712 713 716 718 719 720 721 723 726 728 8. HTTP Binding 730 This section describes the use of HTTP [3] as a delivery mechanism 731 for this protocol, which all conforming implementations MUST support. 733 The request is carried in the body of an HTTP POST request. The MIME 734 type of both request and response bodies should be 735 "application/held+xml". 737 The LIS populates the HTTP headers so that they are consistent with 738 the contents of the message. In particular, the "expires" and cache 739 control headers are used to control the caching of any PIDF-LO 740 document or Location URIs. The HTTP status code SHOULD indicate a 741 2xx series response when a PIDF-LO document or Location URI is 742 included. 744 The use of HTTP also includes a default behaviour, which is triggered 745 by a GET request, or a POST with no request body. If either of these 746 queries are received, the LIS MUST attempt to provide either a 747 PIDF-LO document or a Location URI, as if the request was a location 748 request. 750 The implementation of HTTP as a delivery mechanism MUST implement TLS 751 as described in [4]. TLS provides message integrity and privacy 752 between Device and LIS. The LIS MUST use the server authentication 753 method described in [4]; the Device MUST fail a request if server 754 authentication fails, except in the event of an emergency. 756 9. Security Considerations 758 The threat model for this protocol assumes that the LIS exists within 759 the same administrative domain as the Device. The LIS requires 760 access to network information so that it can determine Location. 761 Therefore, the LIS can use network information to protect against a 762 number of the possible attacks. 764 Specific requirements and security considerations for location 765 acquisition protocols are provided in [11] including that the LCP 766 MUST NOT assume prior network access authentication, which is 767 addressed in Section 9.2 769 An in-depth discussion of the security considerations applicable to 770 the use of Location URIs and by-reference provision of LI is included 771 in [15]. 773 9.1. Return Routability 775 It is RECOMMENDED that Location Information Servers use return 776 routability rather than requiring Device authentication. Device 777 authentication SHOULD NOT be required due to the administrative 778 challenge of issuing and managing of client credentials, particularly 779 when networks allow visiting users to attach devices. However, the 780 LIS MAY require any form of authentication as long as these factors 781 are considered. 783 Addressing information used in a request to the LIS is used to 784 determine the identity of the Device, and to address a response. 785 This ensures that a Device can only request its own LI. 787 A temporary spoofing of IP address could mean that a device could 788 request a Location URI that would result in another Device's 789 location. One or more of the follow approaches are RECOMMENDED to 790 limit this exposure: 791 o Location URIs SHOULD have a limited lifetime, as reflected by the 792 value for the expires element (Section 6.5.1). 793 o The network SHOULD have mechanisms that protect against IP address 794 spoofing. 795 o The LIS SHOULD ensure that requests can only originate from within 796 its administrative domain. 797 o The LIS and network SHOULD be configured so that the LIS is made 798 aware of Device movement within the network and addressing 799 changes. If the LIS detects a change in the network, then all 800 location URIs MUST be invalidated. 802 The above measures are dependent on network configuration and SHOULD 803 be considered with circumstances in mind. For instance, in a fixed 804 internet access, providers may be able to restrict the allocation of 805 IP addresses to a single physical line, ensuring that spoofing is not 806 possible; in such an environment, other measures may not be 807 necessary. 809 9.2. Transaction Layer Security 811 All bindings for this protocol MUST ensure that messages are 812 adequately protected against eavesdropping and modification. 813 Bindings MUST also provide a means of authenticating the LIS. 815 It is RECOMMENDED that all bindings also use TLS [2]. 817 For the HTTP binding, TLS MUST be used. TLS provides protection 818 against eavesdropping and modification. The server authentication 819 methods described in HTTP on TLS [4] MUST be used. 821 10. Examples 823 10.1. HTTP Example Messages 825 The examples in this section show a complete HTTP message that 826 includes the HELD request or response document. 828 This example shows the most basic request for a LO. This uses the 829 GET feature described by the HTTP binding. This example assumes that 830 the LIS service exists at the URL "https://lis.example.com/location". 832 GET /location HTTP/1.1 833 Host: lis.example.com 834 Accept:application/held+xml, 835 application/xml;q=0.8, 836 text/xml;q=0.7 837 Accept-Charset: UTF-8,* 839 The GET request is exactly identical to a minimal POST request that 840 includes an empty "locationRequest" element. 842 POST /location HTTP/1.1 843 Host: lis.example.com 844 Accept: application/held+xml, 845 application/xml;q=0.8, 846 text/xml;q=0.7 847 Accept-Charset: UTF-8,* 848 Content-Type: application/held+xml 849 Content-Length: 87 851 852 854 The successful response to either of these requests is a PIDF-LO 855 document. The following response shows a minimal PIDF-LO response. 857 HTTP/1.x 200 OK 858 Server: Example LIS 859 Date: Tue, 10 Jan 2006 03:42:29 GMT 860 Expires: Tue, 10 Jan 2006 03:42:29 GMT 861 Cache-control: private 862 Content-Type: application/held+xml 863 Content-Length: 594 865 866 867 869 870 871 872 873 875 -34.407 150.88001 876 877 878 879 880 2006-01-11T03:42:28+00:00 881 882 883 884 2006-01-10T03:42:28+00:00 885 886 887 889 The error response to either of these requests is an error document. 890 The following response shows an example error response. 892 HTTP/1.x 200 OK 893 Server: Example LIS 894 Expires: Tue, 10 Jan 2006 03:49:20 GMT 895 Cache-control: private 896 Content-Type: application/held+xml 897 Content-Length: 135 899 900 904 Note: To focus on important portions of messages, all examples 905 following this note do not show HTTP headers or the XML prologue. 906 In addition, sections of XML not relevant to the example are 907 replaced with comments. 909 10.2. Simple Location Request Example 911 The location request shown below doesn't specify any location types 912 or response time. 914 916 The response to this location request is a list of Location URIs. 918 919 920 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 921 922 sips:9769+357yc6s64ceyoiuy5ax3o@ls.example.com 923 924 925 927 An error response to this location request is shown below: 929 933 10.3. Location Request Example for Multiple Location Types 935 The following Location Request message includes a request for 936 geodetic, civic and any Location URIs. 938 939 940 geodetic 941 civic 942 locationURI 943 944 946 The corresponding Location Response message includes the requested 947 location information, including two location URIs. 949 950 951 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 952 953 sips:9769+357yc6s64ceyoiuy5ax3o@ls.example.com: 954 955 956 958 959 960 961 962 966 -34.407242 150.882518 967 30 968 969 970 973 AU 974 NSW 975 Wollongong 976 Gwynneville 977 Northfield Avenue 978 University of Wollongong 979 2 980 Andrew Corporation 981 2500 982 39 983 WS-183 984 U40 985 986 987 988 false 989 2007-05-25T12:35:02+10:00 990 991 992 Wiremap 993 994 995 2007-05-24T12:35:02+10:00 996 997 998 1000 11. IANA Considerations 1002 This document registers an XML namespace and schema and the 1003 "application/held+xml" MIME type. 1005 11.1. URN Sub-Namespace Registration for 1006 urn:ietf:params:xml:ns:geopriv:held 1008 This section registers a new XML namespace, 1009 "urn:ietf:params:xml:ns:geopriv:held", as per the guidelines in [6]. 1010 URI: urn:ietf:params:xml:ns:geopriv:held 1011 Registrant Contact: IETF, GEOPRIV working group, 1012 (geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com). 1013 XML: 1015 BEGIN 1016 1017 1019 1020 1021 HELD Messages 1022 1023 1024

Namespace for HELD Messages

1025

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

1026 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 1027 with the RFC number for this specification.]] 1028

See RFCXXXX.

1029 1030 1031 END 1033 11.2. XML Schema Registration 1035 This section registers an XML schema as per the guidelines in [6]. 1036 URI: urn:ietf:params:xml:schema:geopriv:held 1037 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 1038 Mary Barnes (mary.barnes@nortel.com). 1039 Schema: The XML for this schema can be found as the entirety of 1040 Section 7 of this document. 1042 11.3. URN Sub-Namespace Registration for 1043 urn:ietf:params:xml:ns:geopriv:held:http 1045 This section registers a new XML namespace, 1046 "urn:ietf:params:xml:ns:geopriv:held:http", as per the guidelines in 1047 [6]. 1048 URI: urn:ietf:params:xml:ns:geopriv:held:http 1049 Registrant Contact: IETF, GEOPRIV working group, 1050 (geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com). 1051 XML: 1053 BEGIN 1054 1055 1057 1058 1059 HELD HTTP Binding WS 1060 1061 1062

Namespace for HELD HTTP Binding WS

1063

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

1064 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 1065 with the RFC number for this specification.]] 1066

See RFCXXXX.

1067 1068 1069 END 1071 11.4. MIME Media Type Registration for 'application/held+xml' 1073 This section registers the "application/held+xml" MIME type. 1074 To: ietf-types@iana.org 1075 Subject: Registration of MIME media type application/held+xml 1076 MIME media type name: application 1077 MIME subtype name: held+xml 1078 Required parameters: (none) 1079 Optional parameters: charset 1080 Indicates the character encoding of enclosed XML. Default is 1081 UTF-8. 1082 Encoding considerations: Uses XML, which can employ 8-bit 1083 characters, depending on the character encoding used. See RFC 1084 3023 [18], section 3.2. 1085 Security considerations: This content type is designed to carry 1086 protocol data related to the location of an entity, which could 1087 include information that is considered private. Appropriate 1088 precautions should be taken to limit disclosure of this 1089 information. 1090 Interoperability considerations: This content type provides a basis 1091 for a protocol 1092 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please 1093 replace XXXX with the RFC number for this specification.]] 1094 Applications which use this media type: Location information 1095 providers and consumers. 1096 Additional Information: Magic Number(s): (none) 1097 File extension(s): .xml 1098 Macintosh File Type Code(s): (none) 1100 Person & email address to contact for further information: Mary 1101 Barnes 1102 Intended usage: LIMITED USE 1103 Author/Change controller: This specification is TBD 1104 Other information: This media type is a specialization of 1105 application/xml [18], and many of the considerations described 1106 there also apply to application/held+xml. 1108 12. Contributors 1110 James Winterbottom, Martin Thomson and Barbara Stark are the authors 1111 of the original document, from which this WG document was derived. 1112 Their contact information is included in the Author's address 1113 section. In addition, they also contributed to the WG document, 1114 including the XML schema. 1116 13. Acknowledgements 1118 The author/contributors would like to thank the participants in the 1119 GEOPRIV WG and the following people for their constructive input and 1120 feedback on this document (in alphabetical order): Nadine Abbott, 1121 Eric Arolick, Richard Barnes, Peter Blatherwick, Guy Caron, Martin 1122 Dawson, Lisa Dusseault, Jerome Grenier, Ted Hardie, Neil Justusson, 1123 Tat Lam, Marc Linsner, Patti McCalmont, Roger Marshall, Perry 1124 Prozeniuk, Carl Reed, Brian Rosen, John Schnizlein, Shida Schubert, 1125 Henning Schulzrinne, Ed Shrum, Doug Stuard, and Hannes Tschofenig. 1127 14. Changes since last Version 1129 NOTE TO THE RFC-Editor: Please remove this section prior to 1130 publication as an RFC. 1132 Changes from WG 02 to 03: 1134 1) Added text to address concern over use of IP address as device 1135 identifier, per long email thread - changes to section 3 (overview) 1136 and section 4 (protocol overview). 1138 2) Removed WSDL (section 8 updated, section 8.1 and 10.4 removed) 1140 3) Added extensibility to baseRequestType in the schema (an oversight 1141 from previous edits), along with fixing some other nits in schema 1142 (section 7) 1144 4) Moved discussion of Location URI from section 5.3 (Location 1145 Response) to where it rightly belonged in Section 6.5 (Location URI 1146 Parameter). 1148 5) Clarified text for "expires" parameter (6.5.1) - it's an optional 1149 parm, but required for LocationURIs 1151 6) Clarified responseTime parameter: when missing, then the LCS 1152 provides most precise LI, with the time required being implementation 1153 specific. 1155 7) Clarified that the MUST use in section 8 (HTTP binding) is a MUST 1156 implement. 1158 8) Updated references (removed unused/added new). 1160 Changes from WG 01 to 02: 1162 1) Updated Terminology to be consistent with WG agreements and other 1163 documents (e.g., LCS -> LIS and removed duplicate terms). In the 1164 end, there are no new terms defined in this document. 1166 2) Modified definition of responseTime to reflect WG consensus. 1168 3) Removed jurisdictionalCivic and postalCivic locationTypes (leaving 1169 just "civic"). 1171 4) Clarified text that locationType is optional. Fixed table 1 and 1172 text in section 5.2 (locationRequest description). Text in section 1173 6.2 (description of locationType element) already defined the default 1174 to be "any". 1176 5) Simplified error responses. Separated the definition of error 1177 response type from the locationResponse type thus no need for 1178 defining an error code of "success". This simplifies the schema and 1179 processing. 1181 6) Updated schema/examples for the above. 1183 7) Updated Appendix A based on updates to requirements document, 1184 specifically changes to A.1, A.3 and adding A.10. 1186 8) Miscellaneous editorial clarifications. 1188 Changes from WG 00 to 01: 1190 1) heldResponse renamed to locationResponse. 1192 2) Changed namespace references for the PIDF-LO geoShape in the 1193 schema to match the agreed GML PIDF-LO Geometry Shape Application 1194 Schema. 1196 3) Removed "options" element - leaving optionality/extensibility to 1197 XML mechanisms. 1199 4) Changed error codes to be enumerations and not redefinitions of 1200 HTTP response codes. 1202 5) Updated schema/examples for the above and removed some remnants of 1203 the context element. 1205 6) Clarified the definition of "Location Information (LI)" to include 1206 a reference to the location (to match the XML schema and provide 1207 consistency of usage throughout the document). Added an additional 1208 statement in section 7.2 (locationType) to clarify that LCS MAY also 1209 return a Location URI. 1211 7) Modifed the definition of "Location Configuration Server (LCS)" to 1212 be consistent with the current definiton in the requirements 1213 document. 1215 8) Updated Location Response (section 6.3) to remove reference to 1216 context and discuss the used of a local identifier or unlinked 1217 pseudonym in providing privacy/security. 1219 9) Clarified that the source IP address in the request is used as the 1220 identifier for the target/device for the HELD protocol as defined in 1221 this document. 1223 10) Miscellaneous editorial clarifications. 1225 15. References 1227 15.1. Normative References 1229 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1230 Levels", BCP 14, RFC 2119, March 1997. 1232 [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1233 RFC 2246, January 1999. 1235 [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 1236 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 1237 HTTP/1.1", RFC 2616, June 1999. 1239 [4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1241 [5] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 1242 Language) XML-Signature Syntax and Processing", RFC 3275, 1243 March 2002. 1245 [6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1246 January 2004. 1248 [7] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 1249 Polk, "Geopriv Requirements", RFC 3693, February 2004. 1251 [8] Peterson, J., "A Presence-based GEOPRIV Location Object 1252 Format", RFC 4119, December 2005. 1254 [9] Thomson, M. and J. Winterbottom, "Revised Civic Location Format 1255 for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-06 (work in 1256 progress), October 2007. 1258 [10] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 1259 PIDF-LO Usage Clarification, Considerations and 1260 Recommendations", draft-ietf-geopriv-pdif-lo-profile-10 (work 1261 in progress), October 2007. 1263 [11] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location 1264 Configuration Protocol; Problem Statement and Requirements", 1265 draft-ietf-geopriv-l7-lcp-ps-05 (work in progress), 1266 September 2007. 1268 [12] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML 1269 Schema Part 1: Structures Second Edition", World Wide Web 1270 Consortium Recommendation REC-xmlschema-1-20041028, 1271 October 2004, 1272 . 1274 [13] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second 1275 Edition", World Wide Web Consortium Recommendation REC- 1276 xmlschema-2-20041028, October 2004, 1277 . 1279 [14] Thomson, M. and J. Winterbottom, "Discovering the Local 1280 Location Information Server (LIS)", 1281 draft-thomson-geopriv-lis-discovery-03 (work in progress), 1282 September 2007. 1284 [15] Marshall, R., "Requirements for a Location-by-Reference 1285 Mechanism", draft-ietf-geopriv-lbyr-requirements-01 (work in 1286 progress), October 2007. 1288 15.2. Informative References 1290 [16] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 1291 September 1981. 1293 [17] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence 1294 and Instant Messaging", RFC 2778, February 2000. 1296 [18] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", 1297 RFC 3023, January 2001. 1299 [19] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1300 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1301 Session Initiation Protocol", RFC 3261, June 2002. 1303 [20] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 1304 Configuration Protocol Option for Coordinate-based Location 1305 Configuration Information", RFC 3825, July 2004. 1307 [21] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1308 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 1309 January 2005. 1311 [22] Polk, J. and B. Rosen, "Location Conveyance for the Session 1312 Initiation Protocol", draft-ietf-sip-location-conveyance-08 1313 (work in progress), July 2007. 1315 [23] TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media 1316 Endpoint Discovery". 1318 Appendix A. HELD Compliance to IETF LCP requirements 1320 This appendix describes HELD's compliance to the requirements 1321 specified in the [11]. 1323 A.1. L7-1: Identifier Choice 1325 "The L7 LCP MUST be able to carry different identifiers or MUST 1326 define an identifier that is mandatory to implement. Regarding the 1327 latter aspect, such an identifier is only appropriate if it is from 1328 the same realm as the one for which the location information service 1329 maintains identifier to location mapping." 1331 COMPLY 1333 HELD uses the IP address of the location request message as the 1334 primary source of identity for the requesting device or target. This 1335 identity can be used with other contextual network information to 1336 provide a physical location for the Target for many network 1337 deployments. There may be network deployments where an IP address 1338 alone is insufficient to identify a Target in a network. However, 1339 any necessary identity extensions for these networks is beyond the 1340 scope of this document. 1342 A.2. L7-2: Mobility Support 1344 "The GEOPRIV Layer 7 Location Configuration Protocol MUST support a 1345 broad range of mobility from devices that can only move between 1346 reboots, to devices that can change attachment points with the impact 1347 that their IP address is changed, to devices that do not change their 1348 IP address while roaming, to devices that continuously move by being 1349 attached to the same network attachment point." 1351 COMPLY 1353 Mobility support is inherently a characteristic of the access network 1354 technology and HELD is designed to be access network agnostic. 1355 Consequently HELD complies with this requirement. In addition HELD 1356 provides specific support for mobile environments by providing an 1357 optional responseTime attribute in location request messages. 1358 Wireless networks often have several different mechanisms at their 1359 disposal for position determination (e.g. Assisted GPS versus 1360 location based on serving base station identity), each providing 1361 different degrees of accuracy and taking different amounts of time to 1362 yield a result. The responseTime parameter provides the LIS with a 1363 criterion which it can use to select a location determination 1364 technique. 1366 A.3. L7-3: ASP and Access Network Provider Relationship 1368 "The design of the L7 LCP MUST NOT assume a business or trust 1369 relationship between the Application Service Provider (ASP) and the 1370 Access Network Provider. Requirements for resolving a reference to 1371 location information are not discussed in this document." 1373 COMPLY 1375 HELD describes a location acquisition protocol and has no 1376 dependencies on the business or trust relationship between the ASP 1377 and the Access Network Provider. Location acquisition using HELD is 1378 subject to the restrictions described in Section 9. 1380 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship 1382 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1383 MUST assume that there is a trust and business relationship between 1384 the L2 and the L3 provider. The L3 provider operates the LIS and 1385 needs to obtain location information from the L2 provider since this 1386 one is closest to the end host. If the L2 and L3 provider for the 1387 same host are different entities, they cooperate for the purposes 1388 needed to determine end system locations." 1390 COMPLY 1392 HELD was specifically designed with this model in mind and readily 1393 allows itself to chaining requests between operators without a change 1394 in protocol being required. HELD is a webservices protocol it can be 1395 bound to transports other than HTTP. Using o offers the option of 1396 high request throughput over a dedicated connection between an L3 1397 provider and an L2 provider without incurring the serial restriction 1398 imposed by HTTP. This is less easy to do with protocols that do not 1399 decouple themselves from the transport. 1401 A.5. L7-5: Legacy Device Considerations 1403 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1404 MUST consider legacy residential NAT devices and NTEs in an DSL 1405 environment that cannot be upgraded to support additional protocols, 1406 for example to pass additional information through DHCP." 1408 COMPLY 1410 HELD is an application protocol and operates on top of IP. A HELD 1411 request from a host behind a residential NAT will traverse the NAT 1412 acquiring the external address of the home router. The location 1413 provided to the host therefore will be the address of the home router 1414 in this circumstance. No changes are required to the home router in 1415 order to support this function, HELD was designed specifically to 1416 address this deployment scenario. 1418 A.6. L7-6: VPN Awareness 1420 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1421 MUST assume that at least one end of a VPN is aware of the VPN 1422 functionality. In an enterprise scenario, the enterprise side will 1423 provide the LIS used by the client and can thereby detect whether the 1424 LIS request was initiated through a VPN tunnel." 1426 COMPLY 1427 HELD does not preclude a LIS on the far end of a VPN tunnel being 1428 aware that the client request is occurring over that tunnel. It also 1429 does not preclude a client device from accessing a LIS serving the 1430 local physical network and subsequently using the location 1431 information with an application that is accessed over a VPN tunnel. 1433 A.7. L7-7: Network Access Authentication 1435 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1436 MUST NOT assume prior network access authentication." 1438 COMPLY 1440 HELD makes no assumptions about prior network access authentication. 1441 HELD strongly recommends the use of TLS with server-side certificates 1442 for communication between the end-point and the LIS. There is no 1443 requirement for the end-point to authenticate with the LIS. 1445 A.8. L7-8: Network Topology Unawareness 1447 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1448 MUST NOT assume end systems being aware of the access network 1449 topology. End systems are, however, able to determine their public 1450 IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP." 1452 COMPLY 1454 HELD makes no assumption about the network topology. HELD doesn't 1455 require that the device know its external IP address, except where 1456 that is required for discovery of the LIS. 1458 A.9. L7-9: Discovery Mechanism 1460 "The L7 LCP MUST define a single mandatory to implement discovery 1461 mechanism." 1463 COMPLY 1465 HELD uses the discovery mechanism in [14]. 1467 A.10. L7-10: PIDF-LO Creation 1469 "When a LIS creates a PIDF-LO per RFC 4119 then it MUST put the 1470 element into the element of the presence document 1471 (see RFC 4479). This ensures that the resulting PIDF-LO document, 1472 which is subsequently distributed to other entities, conforms to the 1473 rules outlined in ". [10] 1474 COMPLY 1476 HELD protocol overview (Section 4 ) describes the requirements on the 1477 LIS in creating the PIDF-LO and prescribes that the PIDF-LO generated 1478 by the LIS MUST conform to [10]. 1480 Authors' Addresses 1482 Mary Barnes (editor) 1483 Nortel 1484 2201 Lakeside Blvd 1485 Richardson, TX 1487 Email: mary.barnes@nortel.com 1489 James Winterbottom 1490 Andrew 1491 PO Box U40 1492 Wollongong University Campus, NSW 2500 1493 AU 1495 Phone: +61 2 4221 2938 1496 Email: james.winterbottom@andrew.com 1497 URI: http://www.andrew.com/ 1499 Martin Thomson 1500 Andrew 1501 PO Box U40 1502 Wollongong University Campus, NSW 2500 1503 AU 1505 Phone: +61 2 4221 2915 1506 Email: martin.thomson@andrew.com 1507 URI: http://www.andrew.com/ 1508 Barbara Stark 1509 BellSouth 1510 Room 7A41 1511 725 W Peachtree St. 1512 Atlanta, GA 30308 1513 US 1515 Email: barbara.stark@bellsouth.com 1517 Full Copyright Statement 1519 Copyright (C) The IETF Trust (2007). 1521 This document is subject to the rights, licenses and restrictions 1522 contained in BCP 78, and except as set forth therein, the authors 1523 retain all their rights. 1525 This document and the information contained herein are provided on an 1526 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1527 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1528 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1529 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1530 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1531 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1533 Intellectual Property 1535 The IETF takes no position regarding the validity or scope of any 1536 Intellectual Property Rights or other rights that might be claimed to 1537 pertain to the implementation or use of the technology described in 1538 this document or the extent to which any license under such rights 1539 might or might not be available; nor does it represent that it has 1540 made any independent effort to identify any such rights. Information 1541 on the procedures with respect to rights in RFC documents can be 1542 found in BCP 78 and BCP 79. 1544 Copies of IPR disclosures made to the IETF Secretariat and any 1545 assurances of licenses to be made available, or the result of an 1546 attempt made to obtain a general license or permission for the use of 1547 such proprietary rights by implementers or users of this 1548 specification can be obtained from the IETF on-line IPR repository at 1549 http://www.ietf.org/ipr. 1551 The IETF invites any interested party to bring to its attention any 1552 copyrights, patents or patent applications, or other proprietary 1553 rights that may cover technology that may be required to implement 1554 this standard. Please address the information to the IETF at 1555 ietf-ipr@ietf.org. 1557 Acknowledgment 1559 Funding for the RFC Editor function is provided by the IETF 1560 Administrative Support Activity (IASA).