draft-ietf-geopriv-http-location-delivery-07.txt   draft-ietf-geopriv-http-location-delivery-08.txt 
GEOPRIV WG M. Barnes, Ed. GEOPRIV WG M. Barnes, Ed.
Internet-Draft Nortel Internet-Draft Nortel
Intended status: Standards Track Intended status: Standards Track
Expires: October 19, 2008 Expires: January 11, 2009
April 17, 2008 July 10, 2008
HTTP Enabled Location Delivery (HELD) HTTP Enabled Location Delivery (HELD)
draft-ietf-geopriv-http-location-delivery-07.txt draft-ietf-geopriv-http-location-delivery-08.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 19, 2008. This Internet-Draft will expire on January 11, 2009.
Abstract Abstract
A Layer 7 Location Configuration Protocol (L7 LCP) is described that A Layer 7 Location Configuration Protocol (L7 LCP) is described that
is used for retrieving location information from a server within an is used for retrieving location information from a server within an
access network. The protocol includes options for retrieving access network. The protocol includes options for retrieving
location information in two forms: by value and by reference. The location information in two forms: by value and by reference. The
protocol is an extensible application-layer protocol that is protocol is an extensible application-layer protocol that is
independent of session-layer. This document describes the use of independent of session-layer. This document describes the use of
Hypertext Transfer Protocol (HTTP) as a transport for the protocol. HyperText Transfer Protocol (HTTP) and HTTP over Transport Layer
Security (HTTP/TLS) as transports for the protocol.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4
3. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Location by Value . . . . . . . . . . . . . . . . . . . . 7 4.1. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 7
4.2. Location by Reference . . . . . . . . . . . . . . . . . . 7 4.1.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 7
4.3. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 7 4.1.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 8
4.3.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 8 4.2. Location by Value . . . . . . . . . . . . . . . . . . . . 8
4.3.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 8 4.3. Location by Reference . . . . . . . . . . . . . . . . . . 8
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9
5.1. Delivery Protocol . . . . . . . . . . . . . . . . . . . . 9 5.1. Delivery Protocol . . . . . . . . . . . . . . . . . . . . 10
5.2. Location Request . . . . . . . . . . . . . . . . . . . . . 10 5.2. Location Request . . . . . . . . . . . . . . . . . . . . . 10
5.3. Location Response . . . . . . . . . . . . . . . . . . . . 10 5.3. Location Response . . . . . . . . . . . . . . . . . . . . 10
5.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 10 5.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 10
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11
6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11 6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11
6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12 6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12
6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 12 6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 14
6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 13 6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 14
6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 13 6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 15
6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 14 6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 15
6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 14 6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 15
6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 14 6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 16
6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 14 6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 16
7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. HELDS: URI Definition . . . . . . . . . . . . . . . . . . . . 18 8. HELD URI Definitions . . . . . . . . . . . . . . . . . . . . . 20
9. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. heldref: URI Definition . . . . . . . . . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8.2. heldrefs: URI Definition . . . . . . . . . . . . . . . . . 21
10.1. Assuring that the proper LIS has been contacted . . . . . 21 9. HTTP/HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . 22
10.2. Protecting responses from modification . . . . . . . . . . 21 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 21 10.1. Assuring that the proper LIS has been contacted . . . . . 24
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10.2. Protecting responses from modification . . . . . . . . . . 24
11.1. HTTP Example Messages . . . . . . . . . . . . . . . . . . 23 10.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 24
11.2. Simple Location Request Example . . . . . . . . . . . . . 25 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.3. Location Request Example for Multiple Location Types . . . 26 11.1. HTTPS Example Messages . . . . . . . . . . . . . . . . . . 26
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 11.2. Simple Location Request Example . . . . . . . . . . . . . 28
11.3. Location Request Example for Multiple Location Types . . . 29
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
12.1. URN Sub-Namespace Registration for 12.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 27 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 30
12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 28 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 31
12.3. MIME Media Type Registration for 'application/held+xml' . 28 12.3. MIME Media Type Registration for 'application/held+xml' . 31
12.4. Error code Registry . . . . . . . . . . . . . . . . . . . 29 12.4. Error code Registry . . . . . . . . . . . . . . . . . . . 32
12.5. URI Registration . . . . . . . . . . . . . . . . . . . . . 30 12.5. URI Registrations . . . . . . . . . . . . . . . . . . . . 33
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31 12.5.1. heldref: URI Registration . . . . . . . . . . . . . . 33
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 12.5.2. heldrefs: URI Registration . . . . . . . . . . . . . . 34
15. Changes since last Version . . . . . . . . . . . . . . . . . . 31 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
16.1. Normative References . . . . . . . . . . . . . . . . . . . 35 15. Changes since last Version . . . . . . . . . . . . . . . . . . 35
16.2. Informative References . . . . . . . . . . . . . . . . . . 36 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 37 16.1. Normative References . . . . . . . . . . . . . . . . . . . 40
A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 38 16.2. Informative References . . . . . . . . . . . . . . . . . . 41
A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 38 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 42
A.3. L7-3: ASP and Access Network Provider Relationship . . . . 38 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 42
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 39 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 43
A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 39 A.3. L7-3: ASP and Access Network Provider Relationship . . . . 43
A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 40 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 44
A.7. L7-7: Network Access Authentication . . . . . . . . . . . 40 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 44
A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 40 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 44
A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 40 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 45
A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 41 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . . . . 43 A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
Intellectual Property and Copyright Statements . . . . . . . . . . 48
1. Introduction 1. Introduction
The location of a Device is information that is useful for a number The location of a Device is information that is useful for a number
of applications. The L7 Location Configuration Protocol (LCP) of applications. The L7 Location Configuration Protocol (LCP)
problem statement and requirements document problem statement and requirements document
[I-D.ietf-geopriv-l7-lcp-ps] provides some scenarios in which the [I-D.ietf-geopriv-l7-lcp-ps] provides some scenarios in which a
Device might rely on its access network to provide location Device might rely on its access network to provide location
information. The LIS service applies to access networks employing information. The Location Information Server (LIS) service applies
both wired technology (e.g. DSL, Cable) and wireless technology to access networks employing both wired technology (e.g. DSL, Cable)
(e.g. WiMAX) with varying degrees of Device mobility. This document and wireless technology (e.g. WiMAX) with varying degrees of Device
describes a protocol that can be used to acquire Location Information mobility. This document describes a protocol that can be used to
(LI) from a Location Information Server (LIS) within an access acquire Location Information (LI) from a LIS within an access
network. network.
This specification identifies two types of location information that This specification identifies two types of location information that
may be retrieved from the LIS. Location may be retrieved from the may be retrieved from the LIS. Location may be retrieved from the
LIS by value, that is, the Device may acquire a literal location LIS by value, that is, the Device may acquire a literal location
object describing the location of the Device. The Device may also object describing the location of the Device. The Device may also
request that the LIS provide a location reference in the form of a request that the LIS provide a location reference in the form of a
location URI or set of location URIs, allowing the Device to location URI or set of location URIs, allowing the Device to
distribute its LI by reference. Both of these methods can be distribute its LI by reference. Both of these methods can be
provided concurrently from the same LIS to accommodate application provided concurrently from the same LIS to accommodate application
requirements for different types of location information. requirements for different types of location information.
This specification defines an extensible XML-based protocol that This specification defines an extensible XML-based protocol that
enables the retrieval of LI from a LIS by a Device. This protocol enables the retrieval of LI from a LIS by a Device. This protocol
can be bound to any session-layer protocol, particularly those can be bound to any session-layer protocol, particularly those
capable of MIME transport. This document describes the use of capable of MIME transport. This document describes the use of
Hypertext Transfer Protocol (HTTP) as a transport for the protocol. HyperText Transfer Protocol (HTTP) and HTTP over Transport Layer
Security (HTTP/TLS) as transports for the protocol.
2. Conventions & Terminology 2. Conventions & Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses the terms (and their acronym forms) Access This document uses the terms (and their acronym forms) Access
Provider (AP), Location Information (LI), Location Object (LO), Provider (AP), Location Information (LI), Location Object (LO),
Device, Target, Location Generator (LG), Location Recipient (LR), Device, Target, Location Generator (LG), Location Recipient (LR),
skipping to change at page 7, line 15 skipping to change at page 7, line 15
for the LIS for sending the HELD protocol requests. The discovery for the LIS for sending the HELD protocol requests. The discovery
methods are specified in [I-D.ietf-geopriv-lis-discovery]. methods are specified in [I-D.ietf-geopriv-lis-discovery].
The LIS requires an identifier for the Device in order to determine The LIS requires an identifier for the Device in order to determine
the appropriate location to include in the location response message. the appropriate location to include in the location response message.
In this document, the IP address of the Device, as reflected by the In this document, the IP address of the Device, as reflected by the
source IP address in the location request message, is used as the source IP address in the location request message, is used as the
identifier. Other identifiers are possible, but are beyond the scope identifier. Other identifiers are possible, but are beyond the scope
of this document. of this document.
4.1. Location by Value 4.1. Device Identifiers, NAT and VPNs
Where a Device requires LI directly, it can request that the LIS
create a PIDF-LO document. This approach fits well with a
configuration whereby the device directly makes use of the provided
PIDF-LO document. The details on the information that may be
included in the PIDF-LO MUST follow the subset of those rules
relating to the construction of the "location-info" element in the
PIDF-LO Usage Clarification, Considerations and Recommendations
document [I-D.ietf-geopriv-pdif-lo-profile]. Further detail is
included in the detailed protocol section of this document Section 6
4.2. Location by Reference
Requesting location directly does not always address the requirements
of an application. A Device can request a location URI instead of
literal location. A Location URI is a URI [RFC3986] of any scheme,
which a Location Recipient (LR) can use to retrieve LI. A location
URI provided by a LIS can be assumed to be globally-addressable; that
is, anyone in possession of the URI can access the LIS. However,
this does not in any way suggest that the LIS is bound to reveal the
location associated with the location URI. This issue is deemed out
of scope for this document. The merits and drawbacks of using a
Location URI approach are discussed in
[I-D.ietf-geopriv-lbyr-requirements].
4.3. Device Identifiers, NAT and VPNs
Use of the HELD protocol is subject to the viability of the Use of the HELD protocol is subject to the viability of the
identifier used by the LIS to determine location. This document identifier used by the LIS to determine location. This document
describes the use of the source IP address sent from the Device as describes the use of the source IP address sent from the Device as
the identifier used by the LIS. When Network Address Translation the identifier used by the LIS. When Network Address Translation
(NAT), a Virtual Private Network (VPN) or other forms of address (NAT), a Virtual Private Network (VPN) or other forms of address
modification occur between the Device and the LIS the location modification occur between the Device and the LIS the location
returned could be inaccurate. returned could be inaccurate.
Not all cases of NATs introduce inaccuracies in the returned Not all cases of NATs introduce inaccuracies in the returned
location. For example, a NAT used in a residential Local Area location. For example, a NAT used in a residential Local Area
Network (LAN) is typically not a problem. The external IP address Network (LAN) is typically not a problem. The external IP address
used on the Wide Area Network (WAN) side of the NAT is an acceptable used on the Wide Area Network (WAN) side of the NAT is an acceptable
identifier for all of the devices in the residence, on the LAN side identifier for all of the devices in the residence, on the LAN side
of the NAT, since the covered geographical area is small. of the NAT, since the covered geographical area is small.
On the other hand, if there is a VPN between the Device and the LIS, On the other hand, if there is a VPN between the Device and the LIS,
for example for a teleworker, then the IP address seen by a LIS for example for a teleworker, then the IP address seen by a LIS
inside the enterprise network might not be the right address to inside the enterprise network might not be the right address to
identify the location of the Device. Section 4.3.2 provides identify the location of the Device. Section 4.1.2 provides
recommendations to address this issue. recommendations to address this issue.
4.3.1. Devices and VPNs 4.1.1. Devices and VPNs
To minimize the impact of VPNs, Devices should perform their HELD To minimize the impact of VPNs, Devices should perform their HELD
query prior to establishing a VPN tunnel. It is RECOMMENDED that query prior to establishing a VPN tunnel. It is RECOMMENDED that
discovery [I-D.ietf-geopriv-lis-discovery] and an initial query are discovery [I-D.ietf-geopriv-lis-discovery] and an initial query are
performed before establishing the VPN. If a Device performs the HELD performed before establishing the VPN. If a Device performs the HELD
query after establishing the VPN tunnel the Device may receive query after establishing the VPN tunnel the Device may receive
inaccurate location information. inaccurate location information.
Devices that establish VPN connections for use by other devices Devices that establish VPN connections for use by other devices
inside a LAN or other closed network could serve as a LIS, that inside a LAN or other closed network could serve as a LIS, that
implements the HELD protocol, for those other Devices. Devices implements the HELD protocol, for those other Devices. Devices
within the closed network are not necessarily able to detect the within the closed network are not necessarily able to detect the
presence of the VPN and rely on the VPN device. To this end, a VPN presence of the VPN and rely on the VPN device. To this end, a VPN
device should provide the address of the LIS server it provides, in device should provide the address of the LIS server it provides, in
response to discovery queries, rather than passing such queries response to discovery queries, rather than passing such queries
through the VPN tunnel. through the VPN tunnel. Otherwise, the other devices would be
totally unaware that they could receive inaccurate location
information.
4.3.2. LIS Handling of NATs and VPNs It could also be useful for a VPN device to serve as a LIS for other
location configuration options such as Dynamic Host Configuration
Protocol (DHCP)[RFC3825] or Link Layer Discovery Protocol - Media
Endpoint Discovery (LLDP-MED) [LLDP-MED]. For this case, the VPN
device that serves as a LIS may first acquire its own location using
HELD.
4.1.2. LIS Handling of NATs and VPNs
In the cases where the Device connects to the LIS through a VPN or a In the cases where the Device connects to the LIS through a VPN or a
NAT that serves a large geographic area or multiple geographic NAT that serves a large geographic area or multiple geographic
locations (for example, a NAT used by an enterprise to connect their locations (for example, a NAT used by an enterprise to connect their
private network to the Internet), the LIS might not be able to return private network to the Internet), the LIS might not be able to return
an accurate LI. If the LIS cannot determine an accurate LI, it an accurate LI. If the LIS cannot determine LI for the device, it
should not provide location information to the requesting device. should provide an error response to the requesting device. The LIS
The LIS needs to be configured to recognize identifiers that needs to be configured to recognize identifiers that represent these
represent these conditions. conditions.
LIS operators have a large role in ensuring the best possible LIS operators have a large role in ensuring the best possible
environment for location determination. The LIS operator needs to environment for location determination. The LIS operator needs to
ensure that the LIS is properly configured with identifiers that fall ensure that the LIS is properly configured with identifiers that fall
within NATs and VPNs. In order to serve a Device on a remote side of within NATs and VPNs. In order to serve a Device on a remote side of
a NAT or VPN a LIS needs to have a presence on the side of the NAT or a NAT or VPN a LIS needs to have a presence on the side of the NAT or
VPN nearest the Device. VPN nearest the Device.
4.2. Location by Value
Where a Device requires LI directly, it can request that the LIS
create a PIDF-LO document. This approach fits well with a
configuration whereby the device directly makes use of the provided
PIDF-LO document. The details on the information that may be
included in the PIDF-LO MUST follow the subset of those rules
relating to the construction of the "location-info" element in the
PIDF-LO Usage Clarification, Considerations and Recommendations
document [I-D.ietf-geopriv-pdif-lo-profile]. Further detail is
included in the detailed protocol section of this document Section 6
4.3. Location by Reference
Requesting location directly does not always address the requirements
of an application. A Device can request a location URI instead of
literal location. A Location URI is a URI [RFC3986] of any scheme,
which a Location Recipient (LR) can use to retrieve LI. A location
URI provided by a LIS can be assumed to be globally-addressable; that
is, anyone in possession of the URI can access the LIS.
However, possession of the URI does not in any way suggest that the
LIS indiscriminately reveals the location associated with the
location URI. The specific requirements associated with the
dereference of the location are specified in
[I-D.ietf-geopriv-lbyr-requirements]. The location dereference
protocol details are out of scope of this document and are specified
in [I-D.winterbottom-geopriv-deref-protocol].
It should also be noted that while the lybr requirements document
specifies a requirement that a client SHOULD be able to cancel
location references, the protocol specified in this document does not
provide that functionality. The mechanism to provide this support in
the protocol requires explicit management of Target state on the LIS.
It is anticipated that extensions to HELD may support that
requirement.
5. Protocol Description 5. Protocol Description
As discussed in Section 4, this protocol provides for the retrieval As discussed in Section 4, this protocol provides for the retrieval
of the device's location in the form of a PIDF-LO document and/or of the device's location in the form of a PIDF-LO document and/or
Location URI(s) from a LIS. Three messages are defined to support Location URI(s) from a LIS. Three messages are defined to support
the location retrieval: locationRequest, locationResponse and error. the location retrieval: locationRequest, locationResponse and error.
Messages are defined as XML documents. Messages are defined as XML documents.
The Location Request (locationRequest) message is described in The Location Request (locationRequest) message is described in
Section 5.2. A Location Request message from a Device indicates Section 5.2. A Location Request message from a Device indicates
skipping to change at page 9, line 43 skipping to change at page 10, line 16
The HELD protocol is an application-layer protocol specified by an The HELD protocol is an application-layer protocol specified by an
XML document. The HELD protocol is defined independently of any XML document. The HELD protocol is defined independently of any
lower layers used to transport messages from one host to another. lower layers used to transport messages from one host to another.
This means that any protocol can be used to transport this protocol This means that any protocol can be used to transport this protocol
providing that it can provide a few basic features: providing that it can provide a few basic features:
o The HELD protocol doesn't provide any mechanisms that enable o The HELD protocol doesn't provide any mechanisms that enable
detection of missing messages and retransmission, thus the detection of missing messages and retransmission, thus the
protocol must have acknowledged delivery. protocol must have acknowledged delivery.
o The HELD protocol is a request, response protocol, thus the o The HELD protocol is a request/response protocol, thus the
protocol must be able to correlate a response with a request. protocol must be able to correlate a response with a request.
o The HELD protocol must provide authentication, confidentiality and o The HELD protocol REQUIRES that the underlying transport provide
protection against modification per Section 10.3. authentication, confidentiality, and protection against
modification per Section 10.3.
This document describes the use of a combination of HTTP [RFC2616], This document describes the use of a combination of HTTP [RFC2616],
TLS [RFC4346] and TCP [RFC0793] in Section 9. TLS [RFC4346] and TCP [RFC0793] in Section 9.
5.2. Location Request 5.2. Location Request
A location request message is sent from the Device to the LIS when A location request message is sent from the Device to the LIS when
the Device requires its own LI. The type of LI that a Device the Device requires its own LI. The type of LI that a Device
requests is determined by the type of LI that is included in the requests is determined by the type of LI that is included in the
"locationType" element. "locationType" element.
The location request is made by sending a document formed of a The location request is made by sending a document formed of a
"locationRequest" element. The LIS uses the source IP address of the "locationRequest" element. The LIS uses the source IP address of the
location request message as the primary source of identity for the location request message as the primary source of identity for the
requesting device or target. It is anticipated that other Device requesting device or target. It is anticipated that other Device
identities may be provided through schema extensions. identities may be provided through schema extensions.
The LIS MUST ignore any part of a location request message that it The LIS MUST ignore any part of a location request message that it
does not understand. does not understand, except the document element.
5.3. Location Response 5.3. Location Response
A successful response to a location request MUST contain a PIDF-LO A successful response to a location request MUST contain a PIDF-LO
and/or location URI(s). The response SHOULD contain location and/or location URI(s). The response SHOULD contain location
information of the requested "locationType". The cases whereby a information of the requested "locationType". The cases whereby a
different type of location information MAY be returned are described different type of location information MAY be returned are described
in Section 6.2. in Section 6.2.
5.4. Indicating Errors 5.4. Indicating Errors
skipping to change at page 12, line 13 skipping to change at page 12, line 34
of determining, with the time interval being implementation of determining, with the time interval being implementation
dependent. dependent.
6.2. "locationType" Parameter 6.2. "locationType" Parameter
The "locationType" element MAY be included in a location request The "locationType" element MAY be included in a location request
message. It contains a list of LI types that are requested by the message. It contains a list of LI types that are requested by the
Device. The following list describes the possible values: Device. The following list describes the possible values:
any: The LIS SHOULD attempt to provide LI in all forms available to any: The LIS SHOULD attempt to provide LI in all forms available to
it. The LIS SHOULD return location information in a form that is it.
suited for routing and responding to an emergency call in its
jurisdiction, specifically by value. The LIS MAY alternatively or
additionally return a location URI. If the LIS believes that the
Device is mobile, that is, its location may change over relatively
short periods of time (i.e., several minutes), it SHOULD return a
location URI. If the "locationType" element is absent, this value
MUST be assumed as the default.
geodetic: The LIS SHOULD return a geodetic location for the Target. geodetic: The LIS SHOULD return a geodetic location for the Target.
civic: The LIS SHOULD return a civic address for the Target. civic: The LIS SHOULD return a civic address for the Target.
locationURI: The LIS SHOULD return a set of location URIs for the locationURI: The LIS SHOULD return a set of location URIs for the
Target. Target.
The LIS SHOULD return the requested location type or types. The LIS The LIS SHOULD return the requested location type or types. The
MAY provide additional location types, or it MAY provide alternative location types the LIS returns also depend on the setting of the
types if the request cannot be satisfied for a requested location optional "exact" attribute. If the "exact" attribute is set to
type. A location URI provided by the LIS is a reference to the most "true" then the LIS MUST return either the requested location type or
current available LI and is not a stable reference to a specific provide an error response. The "exact" attribute does not apply (is
location. The location types the LIS returns also depend on the ignored) for a request for a location type of "any". Further detail
setting of the optional "exact" attribute, as described in the of the "exact" attribute processing is provided in the following
following section. The LIS SHOULD provide the locations in the section Section 6.2.1.
response in the same order in which they were included in the
"locationType" element in the request.
The "SHOULD"-strength requirements on this parameter are included to In the case of a request for specific locationType(s) and the "exact"
allow for soft-failover. This enables a fixed client configuration attribute is false, the LIS MAY provide additional location types, or
that prefers a specific location type without causing location it MAY provide alternative types if the request cannot be satisfied
requests to fail when that location type is unavailable. For for a requested location type. The "SHOULD"-strength requirements on
example, a notebook computer could be configured to retrieve civic this parameter for specific location types are included to allow for
addresses, which is usually available from typical home or work soft-failover. This enables a fixed client configuration that
situations. However, when using a wireless modem, the LIS might be prefers a specific location type without causing location requests to
unable to provide a civic address and thus provides a geodetic fail when that location type is unavailable. For example, a notebook
address. computer could be configured to retrieve civic addresses, which is
usually available from typical home or work situations. However,
when using a wireless modem, the LIS might be unable to provide a
civic address and thus provides a geodetic address.
The LIS SHOULD return location information in a form that is suited
for routing and responding to an emergency call in its jurisdiction,
specifically by value. The LIS MAY alternatively or additionally
return a location URI. If the LIS believes that the Device is
mobile, that is, its location may change over relatively short
periods of time (i.e., several minutes), it SHOULD return a location
URI. If the "locationType" element is absent, a location URI MUST be
assumed as the default. A location URI provided by the LIS is a
reference to the most current available LI and is not a stable
reference to a specific location.
It should be noted that the protocol does not support a request to
just receive one of a subset of location types. For example, in the
case where a Device has a preference for just "geodetic" or "civic",
it is necessary to make the request without an "exact" attribute,
including both location types. In this case, if neither is available
a LIS SHOULD return a locationURI if available.
The LIS SHOULD provide the locations in the response in the same
order in which they were included in the "locationType" element in
the request. Indeed, the primary advantage of including specific
location types in a request when the "exact" attribute is set to
"false" is to ensure that one receives the available locations in a
specific order. For example, a locationRequest for "civic" could
yield any of the following location types in the response:
o civic
o civic, geodetic
o civic, locationURI
o civic, geodetic, locationURI
o civic, locationURI, geodetic
o geodetic, locationURI (only if civic is not available)
o locationURI, geodetic (only if civic is not available)
o geodetic (only if civic is not available)
o locationURI (only if civic is not available)
For the example above, if the "exact" attribute was "true", then the
only possible response is either a "civic" location or an error
message.
6.2.1. "exact" Attribute 6.2.1. "exact" Attribute
The "exact" attribute MAY be included in a location request message The "exact" attribute MAY be included in a location request message
when the "locationType" element is included. When the "exact" when the "locationType" element is included. When the "exact"
attribute is set to "true", it indicates to the LIS that the contents attribute is set to "true", it indicates to the LIS that the contents
of the "locationType" parameter MUST be strictly followed. The of the "locationType" parameter MUST be strictly followed. The
default value of "false" allows the LIS the option of returning default value of "false" allows the LIS the option of returning
something beyond what is specified, such as a set of location URIs something beyond what is specified, such as a set of location URIs
when only a civic location was requested. when only a civic location was requested.
skipping to change at page 13, line 19 skipping to change at page 14, line 25
A value of "true" indicates that the LIS MUST provide a location of A value of "true" indicates that the LIS MUST provide a location of
the requested type or types or MUST provide an error. The LIS MUST the requested type or types or MUST provide an error. The LIS MUST
provide the requested types only. The LIS MUST handle an exact provide the requested types only. The LIS MUST handle an exact
request that includes a "locationType" element set to "any" as if the request that includes a "locationType" element set to "any" as if the
"exact" attribute were set to "false". "exact" attribute were set to "false".
6.3. "code" Parameter 6.3. "code" Parameter
All "error" responses MUST contain a response code. All errors are All "error" responses MUST contain a response code. All errors are
application-level errors, and MUST only be provided in successfully application-level errors, and MUST only be provided in successfully
processed transport-level responses. For example where HTTP is used processed transport-level responses. For example where HTTP/HTTPS is
as the transport, HELD error messages MUST be accompanied by a 200 OK used as the transport, HELD error messages MUST be accompanied by a
HTTP response. 200 OK HTTP/HTTPS response.
The value of the response code MUST be one of the following tokens: The value of the response code MUST be one of the following tokens:
requestError: This code indicates that the request was badly formed requestError: This code indicates that the request was badly formed
in some fashion (other than the XML content). in some fashion (other than the XML content).
xmlError: This code indicates that the XML content of the request xmlError: This code indicates that the XML content of the request
was either badly formed or invalid. was either badly formed or invalid.
generalLisError: This code indicates that an unspecified error generalLisError: This code indicates that an unspecified error
occurred at the LIS. occurred at the LIS.
locationUnknown: This code indicates that the LIS could not locationUnknown: This code indicates that the LIS could not
determine the location of the Device. determine the location of the Device.
unsupportedMessage: This code indicates that an element in the XML unsupportedMessage: This code indicates that an element in the XML
document for the request, was not supported or understood by the document for the request, was not supported or understood by the
LIS. LIS. This error code is used when a HELD request contains a
document element that is not supported by the receiver.
timeout: This code indicates that the LIS could not satisfy the timeout: This code indicates that the LIS could not satisfy the
request within the time specified in the "responseTime" parameter. request within the time specified in the "responseTime" parameter.
cannotProvideLiType: This code indicates that the LIS was unable to cannotProvideLiType: This code indicates that the LIS was unable to
provide LI of the type or types requested. This code is used when provide LI of the type or types requested. This code is used when
the "exact" attribute on the "locationType" parameter is set to the "exact" attribute on the "locationType" parameter is set to
"true". "true".
notLocatable: This code indicates that the LIS is unable to locate
the Device, and that the Device MUST NOT make further attempts to
retrieve LI from this LIS. This error code is used to indicate
that the Device is outside the access network served by the LIS;
for instance, the VPN and NAT scenarios discussed in
Section 4.1.2.
6.4. "message" Parameter 6.4. "message" Parameter
The "error" message MAY include a "message" attribute to convey some The "error" message MAY include a "message" attribute to convey some
additional, human-readable information about the result of the additional, human-readable information about the result of the
request. This message MAY be included in any language, which SHOULD request. This message MAY be included in any language, which SHOULD
be indicated by the "xml:lang", attribute. The default language is be indicated by the "xml:lang", attribute. The default language is
assumed to be English. assumed to be English.
6.5. "locationUriSet" Parameter 6.5. "locationUriSet" Parameter
skipping to change at page 14, line 25 skipping to change at page 15, line 40
If a "locationUriSet" element is received in a "locationResponse" If a "locationUriSet" element is received in a "locationResponse"
message, it MUST contain an "expires" attribute, which defines the message, it MUST contain an "expires" attribute, which defines the
length of time for which the set of "locationURI" elements are valid. length of time for which the set of "locationURI" elements are valid.
6.5.1. "locationURI" Parameter 6.5.1. "locationURI" Parameter
The "locationURI" element includes a single Location URI. Each The "locationURI" element includes a single Location URI. Each
Location URI that is allocated by the LIS is unique to the device Location URI that is allocated by the LIS is unique to the device
that is requesting it. that is requesting it.
At the time the location URI is provided in the response, there is
not necessarily a binding to a specific location type. The specific
location type is determined at the time of dereference. The
dereference protocol [I-D.winterbottom-geopriv-deref-protocol] allows
the dereferencer to specify the type of location they prefer. The
use of the location URI as defined in this base HELD document is
totally independent of the specific type of location it might
reference.
A "locationURI" SHOULD NOT contain any information that could be used A "locationURI" SHOULD NOT contain any information that could be used
to identify the Device or Target. Thus, it is RECOMMENDED that the to identify the Device or Target. Thus, it is RECOMMENDED that the
"locationURI" element contain a public address for the LIS and an "locationURI" element contain a public address for the LIS and an
anonymous identifier, such as a local identifier or unlinked anonymous identifier, such as a local identifier or unlinked
pseudonym. Further guidelines to ensure the the privacy and pseudonym. Further guidelines to ensure the the privacy and
confidentiality of the information contained in the confidentiality of the information contained in the
"locationResponse" message, including the "locationURI", are included "locationResponse" message, including the "locationURI", are included
in Section 10.3. in Section 10.3.
6.5.2. "expires" Parameter 6.5.2. "expires" Parameter
The "expires" attribute is only included in a "locationResponse" The "expires" attribute is only included in a "locationResponse"
message when a "locationUriSet" element is included. The "expires" message when a "locationUriSet" element is included. The "expires"
attribute indicates the date/time at which the Location URIs provided attribute indicates the date/time at which the Location URIs provided
by the LIS will expire. The "expires" attribute does not define the by the LIS will expire. The "expires" attribute does not define the
length of time a location received by dereferencing the location URI length of time a location received by dereferencing the location URI
will be valid. will be valid. The "expires" attribute is RECOMMENDED not to exceed
24 hours and SHOULD be a minimum of several minutes.
Location responses that contain a "locationUriSet" element MUST Location responses that contain a "locationUriSet" element MUST
include the expiry time in the "expires" attribute. If a Device include the expiry time in the "expires" attribute. If a Device
dereferences a location URI after the expiry time, the dereference dereferences a location URI after the expiry time, the dereference
SHOULD fail. SHOULD fail.
6.6. "Presence" Parameter (PIDF-LO) 6.6. "Presence" Parameter (PIDF-LO)
A "presence" parameter may be included in the "locationResponse" A "presence" parameter may be included in the "locationResponse"
message when specific locationTypes (e.g., "geodetic" or "civic") are message when specific locationTypes (e.g., "geodetic" or "civic") are
requested or a "locationType" of "any" is requested. The LIS MUST requested or a "locationType" of "any" is requested. The LIS MUST
follow the subset of the rules relating to the construction of the follow the subset of the rules relating to the construction of the
"location-info" element in the PIDF-LO Usage Clarification, "location-info" element in the PIDF-LO Usage Clarification,
Considerations and Recommendations document Considerations and Recommendations document
[I-D.ietf-geopriv-pdif-lo-profile] in generating the PIDF-LO for the [I-D.ietf-geopriv-pdif-lo-profile] in generating the PIDF-LO for the
presence parameter. presence parameter.
Note that the presence parameter is not explicitly shown in the XML Note that the presence parameter is not explicitly shown in the XML
schema Section 7 for a location response message due to XML schema schema in Section 7 for a location response message, due to XML
constraints. schema constraints, since PIDF is already defined and registered
separately. Thus, the "##other" namespace serves as a placeholder
for the presence parameter in the schema.
7. XML Schema 7. XML Schema
This section gives the XML Schema Definition This section gives the XML Schema Definition
[W3C.REC-xmlschema-1-20041028], [W3C.REC-xmlschema-2-20041028] of the [W3C.REC-xmlschema-1-20041028], [W3C.REC-xmlschema-2-20041028] of the
"application/held+xml" format. This is presented as a formal "application/held+xml" format. This is presented as a formal
definition of the "application/held+xml" format. Note that the XML definition of the "application/held+xml" format. Note that the XML
Schema definition is not intended to be used with on-the-fly Schema definition is not intended to be used with on-the-fly
validation of the presence XML document. validation of the presence XML document.
skipping to change at page 18, line 32 skipping to change at page 20, line 11
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:element name="locationRequest" <xs:element name="locationRequest"
type="held:locationRequestType"/> type="held:locationRequestType"/>
</xs:schema> </xs:schema>
8. HELDS: URI Definition 8. HELD URI Definitions
This section defines the schema for a helds: URI. This URI schema is This section defines the schemas for heldref: and heldrefs: URIs.
one possible URI scheme for the "locationURI" element, described in The heldrefs: URI is used in the case where TLS provides secure
Section 6.5.1, in a HELD "locationResponse " message. In this case, transport for HELD messages transported by HTTPS as defined in
the helds: URI indicates to the Device where to obtain the actual Section 9. These URI schemas are just two possible URI schemas for
location information for a Target. In addition, the helds: URI can the "locationURI" element, described in Section 6.5.1, in a HELD
be the result of the LIS discovery process "locationResponse " message. The "locationURI" indicates to the
[I-D.ietf-geopriv-lis-discovery] and indicates to the Device the LIS Device where to obtain the actual location information for a Target.
from which LI should be requested.
The helds: URI is defined using a subset of the URI schema specified There are other uses of the heldref:/heldrefs: URIs, such as the use
in Appendix A. of RFC3986 [RFC3986] and the associated URI for dereferencing as described in
[I-D.winterbottom-geopriv-deref-protocol]. Thus, the usages of the
heldref:/heldrefs: URIs described in this document are not intended
to limit the applicability of the heldref:/heldrefs: URIs to other
relevant interfaces, but are necessarily restricted in scope in this
document to the use for the base HELD protocol.
8.1. heldref: URI Definition
The heldref: URI is defined using a subset of the URI schema
specified in Appendix A. of RFC3986 [RFC3986] and the associated URI
Guidelines [RFC4395] per the following ABNF syntax: Guidelines [RFC4395] per the following ABNF syntax:
HELD-URI = "helds://" host [ ":" port ] [ path-absolute ] [ "?" query ] HELDREF-URI="helds://" host[ ":" port ][ path-absolute ][ "?" query ]
The following summarizes the primary elements comprising the HELD-
The following summarizes the primary elements comprising the HELDREF-
URI: URI:
host: As defined in RFC3986 [RFC3986] host: As defined in RFC3986 [RFC3986]
port: As defined in RFC3986 [RFC3986]. There is no unique port port: As defined in RFC3986 [RFC3986]. There is no unique port
associated with location URIs. associated with location URIs.
path-absolute As defined in RFC3986 [RFC3986]. path-absolute As defined in RFC3986 [RFC3986].
query: As defined in RFC3986 [RFC3986]. This allows for additional query: As defined in RFC3986 [RFC3986]. This allows for additional
information associated with the URIs such as a unique anonymous information associated with the URIs such as a unique anonymous
identifier for the Device associated with the target location. identifier for the Device associated with the target location.
The helds: URI is not intended to be human-readable text, therefore The heldref: URI is not intended to be human-readable text, therefore
it is encoded entirely in US-ASCII. The following are examples of it is encoded entirely in US-ASCII. The following are examples of
helds: URIs: heldrefs: URIs:
helds://ls.example.com:49152/thisLocation?token=xyz987 heldref://ls.example.com:49152/thisLocation?token=xyz987
helds://ls.example.com:5432/THISLOCATION?foobar=abc123 heldref://ls.example.com:5432/THISLOCATION?foobar=abc123
helds://ls.example.com:5432/THISlocation?foobar=ABC123 heldref://ls.example.com:5432/THISlocation?foobar=ABC123
helds://ls.example.com:9876/civic heldref://ls.example.com:9876/civic
Other than the "host" portion, URIs are case sensitive and exact Other than the "host" portion, URIs are case sensitive and exact
equivalency is required for HELD-URI comparisons. For example, in equivalency is required for HELDREF-URI comparisons. For example, in
the above examples, although similar in information, the 2nd and 3rd the above examples, although similar in information, the 2nd and 3rd
URIs are not considered equivalent. URIs are not considered equivalent.
In the case where the helds: URI is contained in a "locationURI" It is important to note that the heldref:URI, contained in a
element in a HELD locationResponse message, it is important to note "locationURI" element in a HELD locationResponse message, is only
that the URI is only valid for the length of time indicated by the valid for the length of time indicated by the "expires" attribute.
"expires" attribute.
9. HTTP Binding 8.2. heldrefs: URI Definition
This section describes the use of HTTP [RFC2616] as a transport The heldrefs: URI is defined using a subset of the URI schema
mechanism for this protocol, which all conforming implementations specified in Appendix A. of RFC3986 [RFC3986] and the associated URI
MUST support. Guidelines [RFC4395] per the following ABNF syntax:
The request is carried in the body of an HTTP POST request. The MIME HELDREFS-URI="heldrefs://"host[ ":" port ][ path-absolute ][ "?" query ]
type of both request and response bodies should be
The following summarizes the primary elements comprising the
HELDREFS-URI:
host: As defined in RFC3986 [RFC3986]
port: As defined in RFC3986 [RFC3986]. There is no unique port
associated with location URIs.
path-absolute As defined in RFC3986 [RFC3986].
query: As defined in RFC3986 [RFC3986]. This allows for additional
information associated with the URIs such as a unique anonymous
identifier for the Device associated with the target location.
The heldrefs: URI is not intended to be human-readable text,
therefore it is encoded entirely in US-ASCII. The following are
examples of heldrefs: URIs:
heldrefs://ls.example.com:49152/thisLocation?token=xyz987
heldrefs://ls.example.com:5432/THISLOCATION?foobar=abc123
heldrefs://ls.example.com:5432/THISlocation?foobar=ABC123
heldrefs://ls.example.com:9876/civic
Other than the "host" portion, URIs are case sensitive and exact
equivalency is required for HELDREFS-URI comparisons. For example,
in the above examples, although similar in information, the 2nd and
3rd URIs are not considered equivalent.
It is important to note that the heldrefs: URI, contained in a
"locationURI" element in a HELD locationResponse message, is only
valid for the length of time indicated by the "expires" attribute.
9. HTTP/HTTPS Binding
This section describes the use of HTTP [RFC2616] and HTTPS [RFC2818]
as transport mechanisms for the HELD protocol, which all conforming
implementations MUST support.
The request is carried in the body of an HTTP/HTTPS POST request.
The MIME type of both request and response bodies should be
"application/held+xml". This should be reflected in the HTTP "application/held+xml". This should be reflected in the HTTP
Content-Type and Accept header fields. Content-Type and Accept header fields.
The LIS populates the HTTP headers so that they are consistent with The LIS populates the HTTP/HTTPS headers so that they are consistent
the contents of the message. In particular, the cache control header with the contents of the message. In particular, the cache control
SHOULD be set to disable the HTTP caching of any PIDF-LO document or header SHOULD be set to disable the HTTP/HTTPS caching of any PIDF-LO
Location URIs. Otherwise, there is the risk of stale locations document or Location URIs. Otherwise, there is the risk of stale
and/or the unauthorized disclosure of the LI. This also allows the locations and/or the unauthorized disclosure of the LI. This also
LIS to control any caching with the "expires" parameter. The HTTP allows the LIS to control any caching with the "expires" parameter.
status code MUST indicate a 2xx series response for all HELD The HTTP/HTTPS status code MUST indicate a 2xx series response for
locationResponse and error messages. all HELD locationResponse and error messages.
The use of HTTP also includes a default behaviour, which is triggered The use of HTTP/HTTPS also includes a default behaviour, which is
by a GET request, or a POST with no request body. If either of these triggered by a GET request, or a POST with no request body. If
queries are received, the LIS MUST attempt to provide either a either of these queries are received, the LIS MUST attempt to provide
PIDF-LO document or a Location URI, as if the request was a location either a PIDF-LO document or a Location URI, as if the request was a
request. location request.
The implementation of HTTP as a transport mechanism MUST implement The implementation of HTTPS as a transport mechanism MUST implement
TLS as described in [RFC2818]. TLS provides message integrity and TLS as described in [RFC2818]. TLS provides message integrity and
privacy between Device and LIS. The LIS MUST use the server confidentiality between Device and LIS. The LIS MUST implement the
authentication method described in [RFC2818]; the Device MUST fail a server authentication method described in [RFC2818]. The device uses
request if server authentication fails, except in the event of an the URI obtained during LIS discovery to authenticate the server.
emergency. When TLS is used, the Device SHOULD fail a request if server
authentication fails, except in the event of an emergency.
10. Security Considerations 10. Security Considerations
HELD is a location acquisition protocol whereby the a client requests HELD is a location acquisition protocol whereby the a client requests
its location from a LIS. Specific requirements and security its location from a LIS. Specific requirements and security
considerations for location acquisition protocols are provided in considerations for location acquisition protocols are provided in
[I-D.ietf-geopriv-l7-lcp-ps]. An in-depth discussion of the security [I-D.ietf-geopriv-l7-lcp-ps]. An in-depth discussion of the security
considerations applicable to the use of Location URIs and by considerations applicable to the use of Location URIs and by
reference provision of LI is included in reference provision of LI is included in
[I-D.ietf-geopriv-lbyr-requirements]. [I-D.ietf-geopriv-lbyr-requirements].
skipping to change at page 22, line 28 skipping to change at page 25, line 25
MUST support a mode of operation in which this is the only client MUST support a mode of operation in which this is the only client
authentication. authentication.
Using IP return routability as an authenticator means that location Using IP return routability as an authenticator means that location
information is vulnerable to exposure through IP address spoofing information is vulnerable to exposure through IP address spoofing
attacks. A temporary spoofing of IP address could mean that a device attacks. A temporary spoofing of IP address could mean that a device
could request a Location Object or Location URI that would result in could request a Location Object or Location URI that would result in
another Device's location. In addition, in cases where a Device another Device's location. In addition, in cases where a Device
drops off the network for various reasons, the re-use of the Device's drops off the network for various reasons, the re-use of the Device's
IP address could result in another Device receiving the original IP address could result in another Device receiving the original
Device's location rather than its own location. One or more of the Device's location rather than its own location. These exposures are
following approaches are RECOMMENDED to limit these exposures: limited by the following:
o Location URIs SHOULD have a limited lifetime, as reflected by the o Location URIs MUST have a limited lifetime, as reflected by the
value for the expires element in Section 6.5.2. value for the expires element in Section Section 6.5.2. The
lifetime of location URIs necessarily depends on the nature of the
access.
o The network SHOULD have mechanisms that protect against IP address o The network SHOULD have mechanisms that protect against IP address
spoofing, such as those defined in [RFC3704]. spoofing, such as those defined in [RFC3704].
o The LIS and network SHOULD be configured so that the LIS is made o The LIS and network SHOULD be configured so that the LIS is made
aware of Device movement within the network and addressing aware of Device movement within the network and addressing
changes. If the LIS detects a change in the network that results changes. If the LIS detects a change in the network that results
in it no longer being able to determine the location of the in it no longer being able to determine the location of the
Device, then all location URIs for that Device SHOULD be Device, then all location URIs for that Device SHOULD be
invalidated. invalidated.
The above measures are dependent on network configuration, which The above measures are dependent on network configuration, which
SHOULD be considered. For instance, in a fixed internet access, SHOULD be considered. For instance, in a fixed internet access,
providers may be able to restrict the allocation of IP addresses to a providers may be able to restrict the allocation of IP addresses to a
single physical line, ensuring that spoofing is not possible; in such single physical line, ensuring that spoofing is not possible; in such
an environment, other measures may not be necessary. an environment, additional measures may not be necessary.
When there are further mechanisms available to authenticate ownership
of the IP address, the LIS SHOULD use them to authenticate that the
client is the owner of the target IP address. For example, in a TLS
transaction, the client could present a certificate with a public key
bound to an IPv6 Cryptographically Generated Address, and the LIS
could verify this binding.
11. Examples 11. Examples
The following sections provide basic HTTP examples, a simple location The following sections provide basic HTTP/HTTPS examples, a simple
request example and a location request for multiple location types location request example and a location request for multiple location
example along with the relevant location responses. To focus on types example along with the relevant location responses. To focus
important portions of messages, the examples in Section 11.2 and on important portions of messages, the examples in Section 11.2 and
Section 11.3 do not show HTTP headers or the XML prologue. In Section 11.3 do not show HTTP/HTTPS headers or the XML prologue. In
addition, sections of XML not relevant to the example are replaced addition, sections of XML not relevant to the example are replaced
with comments. with comments.
11.1. HTTP Example Messages 11.1. HTTPS Example Messages
The examples in this section show a complete HTTP message that The examples in this section show a complete HTTPS message that
includes the HELD request or response document. includes the HELD request or response document.
This example shows the most basic request for a LO. This uses the This example shows the most basic request for a LO. This uses the
GET feature described by the HTTP binding. This example assumes that GET feature described by the HTTP binding. This example assumes that
the LIS service exists at the URL "https://lis.example.com/location". the LIS service exists at the URL "https://lis.example.com/location".
GET /location HTTP/1.1 GET heldrefs://lis.example.com:49152/location HTTP/1.1
Host: lis.example.com
Accept:application/held+xml, Accept:application/held+xml,
application/xml;q=0.8, application/xml;q=0.8,
text/xml;q=0.7 text/xml;q=0.7
Accept-Charset: UTF-8,* Accept-Charset: UTF-8,*
The GET request is exactly identical to a minimal POST request that The GET request is exactly identical to a minimal POST request that
includes an empty "locationRequest" element. includes an empty "locationRequest" element.
POST /location HTTP/1.1 POST heldrefs://lis.example.com:49152/location HTTP/1.1
Host: lis.example.com
Accept: application/held+xml, Accept: application/held+xml,
application/xml;q=0.8, application/xml;q=0.8,
text/xml;q=0.7 text/xml;q=0.7
Accept-Charset: UTF-8,* Accept-Charset: UTF-8,*
Content-Type: application/held+xml Content-Type: application/held+xml
Content-Length: 87 Content-Length: 87
<?xml version="1.0"?> <?xml version="1.0"?>
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
Since neither of these requests includes a "locationType" element, Since neither of these requests includes a "locationType" element,
skipping to change at page 25, line 31 skipping to change at page 28, line 31
The location request shown below doesn't specify any location types The location request shown below doesn't specify any location types
or response time. or response time.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
The example response to this location request contains a list of The example response to this location request contains a list of
Location URIs. Location URIs.
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"> <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2006-01-01T13:00:00"> <locationUriSet expires="2006-01-01T13:00:00">
<locationURI>helds://ls.example.com:9768/357yc6s64ceyoiuy5ax3o <locationURI>heldrefs://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI> </locationURI>
<locationURI>sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com <locationURI>sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
</locationURI> </locationURI>
</locationUriSet> </locationUriSet>
</locationResponse> </locationResponse>
An error response to this location request is shown below: An error response to this location request is shown below:
<error xmlns="urn:ietf:params:xml:ns:geopriv:held" <error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="locationUnknown" code="locationUnknown"
message="Location not available"/> message="Location not available"/>
skipping to change at page 29, line 44 skipping to change at page 32, line 44
error codes are included in HELD error messages as described in error codes are included in HELD error messages as described in
Section 6.3 and defined in the schema in the 'codeType' token in the Section 6.3 and defined in the schema in the 'codeType' token in the
XML schema in (Section 7) XML schema in (Section 7)
The following summarizes the requested registry: The following summarizes the requested registry:
Related Registry: Geopriv HELD Registries, Error codes for HELD Related Registry: Geopriv HELD Registries, Error codes for HELD
Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.] with the RFC number for this specification.]
Registration/Assignment Procedures: Following the policies outlined Registration/Assignment Procedures: Following the policies outlined
in [I-D.narten-iana-considerations-rfc2434bis], the IANA policy in [RFC5226], the IANA policy for assigning new values for the
for assigning new values for the Error codes for HELD shall be Error codes for HELD shall be Specification Required: values and
Specification Required: values and their meanings must be their meanings must be documented in an RFC or in some other
documented in an RFC or in some other permanent and readily permanent and readily available reference, in sufficient detail
available reference, in sufficient detail that interoperability that interoperability between independent implementations is
between independent implementations is possible. possible.
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Mary Barnes (mary.barnes@nortel.com). Mary Barnes (mary.barnes@nortel.com).
This section pre-registers the following seven initial error codes as This section pre-registers the following seven initial error codes as
described above in Section 6.3: described above in Section 6.3:
requestError: This code indicates that the request was badly formed requestError: This code indicates that the request was badly formed
in some fashion. in some fashion.
xmlError: This code indicates that the XML content of the request xmlError: This code indicates that the XML content of the request
was either badly formed or invalid. was either badly formed or invalid.
generalLisError: This code indicates that an unspecified error generalLisError: This code indicates that an unspecified error
occurred at the LIS. occurred at the LIS.
locationUnknown: This code indicates that the LIS could not locationUnknown: This code indicates that the LIS could not
determine the location of the Device. determine the location of the Device.
unsupportedMessage: This code indicates that the request was not unsupportedMessage: This code indicates that the request was not
supported or understood by the LIS. supported or understood by the LIS. This error code is used when
a HELD request contains a document element that is not supported
by the receiver.
timeout: This code indicates that the LIS could not satisfy the timeout: This code indicates that the LIS could not satisfy the
request within the time specified in the "responseTime" parameter. request within the time specified in the "responseTime" parameter.
cannotProvideLiType: This code indicates that the LIS was unable to cannotProvideLiType: This code indicates that the LIS was unable to
provide LI of the type or types requested. This code is used when provide LI of the type or types requested. This code is used when
the "exact" attribute on the "locationType" parameter is set to the "exact" attribute on the "locationType" parameter is set to
"true". "true".
notLocatable: This code indicates that the LIS is unable to locate
the Device, and that the Device MUST NOT make further attempts to
retrieve LI from this LIS. This error code is used to indicate
that the Device is outside the access network served by the LIS;
for instance, the VPN and NAT scenarios discussed in
Section 4.1.2.
12.5. URI Registration 12.5. URI Registrations
The following summarizes the information necessary to register the The following summarizes the information necessary to register the
helds: URI. [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the heldref: and heldrefs: URIs. [NOTE TO IANA/RFC-EDITOR: Please
RFC number for this specification in the following list.] replace XXXX with the RFC number for this specification in the
following list.]
URI Scheme Name: helds 12.5.1. heldref: URI Registration
URI Scheme Name: heldref
Status: permanent Status: permanent
URI Scheme syntax: See section URI Scheme syntax: See section Section 8.1.
URI Scheme Semantics: The helds: URI is intended to be used as a URI Scheme Semantics: The heldref: URI is intended to be used as a
reference to a location object or a location information server.
Further detail is provided in Section 8 of RFC XXXX.
Encoding Considerations: The heldref: URI is not intended to be
human-readable text, therefore they are encoded entirely in US-
ASCII.
Applications/protocols that use this URI scheme: The HELD protocol
described in RFC XXXX and the GEOPRIV Location De-reference
Protocol [I-D.winterbottom-geopriv-deref-protocol].
Interoperability considerations: This URI may be used as a parameter
for the HELD protocol in the locationResponse message. This URI
is also used as an input parameter for the GEOPRIV Location De-
reference Protocol [I-D.winterbottom-geopriv-deref-protocol].
Refer to Section 8 in RFC XXXX for further detail and a particular
example on the lack of permanence of a specific heldref: URI and
thus the importance of using these URIs only within the specific
contexts outlined in the references.
Security considerations: Section 10 in RFC XXXX addresses the
necessary security associated with the transport of location
information between a Device and the LIS to ensure the privacy and
integrity of the heldref: URI. Section 6.5.1 in RFC XXXX also
recommends that the URI be allocated such that it does not reveal
any detail at all about the content of the PIDF-LO that it may
indirectly reference.
Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary
Barnes (mary.barnes@nortel.com).
Author/Change controller: This scheme is registered under the IETF
tree. As such, IETF maintains change control.
References: RFC XXXX, GEOPRIV Location De-reference Protocol
[I-D.winterbottom-geopriv-deref-protocol]
12.5.2. heldrefs: URI Registration
URI Scheme Name: heldrefs
Status: permanent
URI Scheme syntax: See section Section 8.2.
URI Scheme Semantics: The heldrefs: URI is intended to be used as a
reference to a location object or a location information server. reference to a location object or a location information server.
Further detail is provided in Section 8 of RFC XXXX. Further detail is provided in Section 8 of RFC XXXX.
Encoding Considerations: The HELDS: URI is not intended to be human- Encoding Considerations: The HELDS: URI is not intended to be human-
readable text, therefore they are encoded entirely in US-ASCII. readable text, therefore they are encoded entirely in US-ASCII.
Applications/protocols that use this URI scheme: The HELD protocol Applications/protocols that use this URI scheme: The HELD protocol
described in RFC XXXX, the GEOPRIV Location De-reference Protocol described in RFC XXXX and the GEOPRIV Location De-reference
[I-D.winterbottom-geopriv-deref-protocol] and GEOPRIV Location Protocol [I-D.winterbottom-geopriv-deref-protocol].
Information Server Discovery [I-D.ietf-geopriv-lis-discovery].
Interoperability considerations: This URI may be used as a parameter Interoperability considerations: This URI may be used as a parameter
for the HELD protocol in the locationResponse message. This URI for the HELD protocol in the locationResponse message. This URI
is also used as an input parameter for the GEOPRIV Location De- is also used as an input parameter for the GEOPRIV Location De-
reference Protocol [I-D.winterbottom-geopriv-deref-protocol]. reference Protocol [I-D.winterbottom-geopriv-deref-protocol].
This URI may also be a result of the GEOPRIV Location Information Refer to Section 8 in RFC XXXX for further detail and a particular
Server Discovery [I-D.ietf-geopriv-lis-discovery] and thus used as example on the lack of permanence of a specific heldrefs: URI and
the target for the HELD protocol request messages. Refer to thus the importance of using these URIs only within the specific
Section 8 in RFC XXXX for further detail and a particular example contexts outlined in the references.
on the lack of permanence of a specific HELDS: URI and thus the
importance of using these URIs only within the specific contexts
outlined in the references.
Security considerations: Section 10 in RFC XXXX addresses the Security considerations: Section 10 in RFC XXXX addresses the
necessary security associated with the transport of location necessary security associated with the transport of location
information between a Device and the LIS to ensure the privacy and information between a Device and the LIS to ensure the privacy and
integrity of the helds: URI. Section 6.5.1 in RFC XXXX also integrity of the heldrefs: URI. Section 6.5.1 in RFC XXXX also
recommends that the URI be allocated such that it does not reveal recommends that the URI be allocated such that it does not reveal
any detail at all about the content of the PIDF-LO that it may any detail at all about the content of the PIDF-LO that it may
indirectly reference. indirectly reference.
Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary
Barnes (mary.barnes@nortel.com). Barnes (mary.barnes@nortel.com).
Author/Change controller: This scheme is registered under the IETF Author/Change controller: This scheme is registered under the IETF
tree. As such, IETF maintains change control. tree. As such, IETF maintains change control.
References: RFC XXXX, GEOPRIV Location De-reference Protocol References: RFC XXXX, GEOPRIV Location De-reference Protocol
[I-D.winterbottom-geopriv-deref-protocol], GEOPRIV Location [I-D.winterbottom-geopriv-deref-protocol]
Information Server Discovery [I-D.ietf-geopriv-lis-discovery]
13. Contributors 13. Contributors
James Winterbottom, Martin Thomson and Barbara Stark are the authors James Winterbottom, Martin Thomson and Barbara Stark are the authors
of the original document, from which this WG document was derived. of the original document, from which this WG document was derived.
Their contact information is included in the Author's address Their contact information is included in the Author's address
section. In addition, they also contributed to the WG document, section. In addition, they also contributed to the WG document,
including the XML schema. including the XML schema.
14. Acknowledgements 14. Acknowledgements
The author/contributors would like to thank the participants in the The author/contributors would like to thank the participants in the
GEOPRIV WG and the following people for their constructive input and GEOPRIV WG and the following people for their constructive input and
feedback on this document (in alphabetical order): Nadine Abbott, feedback on this document (in alphabetical order): Nadine Abbott,
Eric Arolick, Richard Barnes (in particular the security section), Eric Arolick, Richard Barnes (in particular the security section),
Peter Blatherwick, Guy Caron, Martin Dawson, Lisa Dusseault, Jerome Peter Blatherwick, Ben Campbell, Guy Caron, Martin Dawson, Lisa
Grenier, Ted Hardie, Cullen Jennings, Neil Justusson, Tat Lam, Marc Dusseault, Jerome Grenier, Ted Hardie, Cullen Jennings, Neil
Linsner, Patti McCalmont, Roger Marshall, Perry Prozeniuk, Carl Reed, Justusson, Tat Lam, Marc Linsner, Patti McCalmont, Roger Marshall,
Brian Rosen, John Schnizlein, Shida Schubert, Henning Schulzrinne, Ed Perry Prozeniuk, Carl Reed, Eric Rescorla, Brian Rosen, John
Shrum, Doug Stuard, Hannes Tschofenig and Karl Heinz Wolf. Schnizlein, Shida Schubert, Henning Schulzrinne, Ed Shrum, Doug
Stuard, Hannes Tschofenig and Karl Heinz Wolf.
15. Changes since last Version 15. Changes since last Version
NOTE TO THE RFC-Editor: Please remove this section prior to NOTE TO THE RFC-Editor: Please remove this section prior to
publication as an RFC. publication as an RFC.
Changes from WG 07 to 08 (IETF LC: sec-dir and gen-art review
comments):
1) Fix editorial nits: rearranging sections in 4.1 for readibility,
etc.
2) Added back text in Device and VPN section referencing DHCP and
LLDP-MED when a VPN device serves as a LIS.
3) Clarified the use of both HTTP and HTTPS.
4) Defined two URIs related to 3 respectively - divided IANA
registrations into sub-sections to accomodate this change. (Note:
LIS Discovery will now define that URI, thus this document defines
the one associatied with a Location reference).
5) Clarified the description of the location URI in Protocol Overview
and Protocol parameter sections. Note that these sections again
reference location dereference protocol for completeness and
clarification of issues that are out of scope for this base document.
6) Defined new error code: notLocatable.
7) Clarifications and corrections in security section.
8) Clarified text for locationType, specifically removing extra text
from "any" description and putting that in a separate paragraph.
Also, provided an example.
9) Added boundaries for "expires" parameter.
10) Clarified that the HELD protocol as defined by this document does
not allow for canceling location references.
Changes from WG 06 to 07 (PROTO review comments): Changes from WG 06 to 07 (PROTO review comments):
1) Fix nits: remove unused references, move requirements to 1) Fix nits: remove unused references, move requirements to
Informational References section, fix long line in ABNF, fix ABNF Informational References section, fix long line in ABNF, fix ABNF
(quotes around '?'), add schemaLocation to import namespace in XML (quotes around '?'), add schemaLocation to import namespace in XML
schema. schema.
2) Remove text in Device and VPN section referencing DHCP and LLDP- 2) Remove text in Device and VPN section referencing DHCP and LLDP-
MED when a VPN device serves as a LIS, per Issue 1 resolution at MED when a VPN device serves as a LIS, per Issue 1 resolution at
IETF-71. (Editorial oversight in producing version 06). IETF-71. (Editorial oversight in producing version 06).
skipping to change at page 36, line 25 skipping to change at page 41, line 8
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[I-D.ietf-geopriv-pdif-lo-profile] [I-D.ietf-geopriv-pdif-lo-profile]
Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations and PIDF-LO Usage Clarification, Considerations and
Recommendations", draft-ietf-geopriv-pdif-lo-profile-11 Recommendations", draft-ietf-geopriv-pdif-lo-profile-11
(work in progress), February 2008. (work in progress), February 2008.
[W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-1-20041028]
Mendelsohn, N., Thompson, H., Beech, D., and M. Maloney, Thompson, H., Maloney, M., Beech, D., and N. Mendelsohn,
"XML Schema Part 1: Structures Second Edition", World Wide "XML Schema Part 1: Structures Second Edition", World Wide
Web Consortium Recommendation REC-xmlschema-1-20041028, Web Consortium Recommendation REC-xmlschema-1-20041028,
October 2004, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[W3C.REC-xmlschema-2-20041028] [W3C.REC-xmlschema-2-20041028]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium Second Edition", World Wide Web Consortium
Recommendation REC-xmlschema-2-20041028, October 2004, Recommendation REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[I-D.ietf-geopriv-lis-discovery] [I-D.ietf-geopriv-lis-discovery]
Thomson, M. and J. Winterbottom, "Discovering the Local Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", Location Information Server (LIS)",
draft-ietf-geopriv-lis-discovery-00 (work in progress), draft-ietf-geopriv-lis-discovery-01 (work in progress),
December 2007. June 2008.
16.2. Informative References 16.2. Informative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based
Location Configuration Information", RFC 3825, July 2004.
[LLDP-MED]
TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
Endpoint Discovery".
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 115, Registration Procedures for New URI Schemes", BCP 115,
RFC 4395, February 2006. RFC 4395, February 2006.
[I-D.narten-iana-considerations-rfc2434bis] [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226,
IANA Considerations Section in RFCs", May 2008.
draft-narten-iana-considerations-rfc2434bis-09 (work in
progress), March 2008.
[I-D.ietf-geopriv-l7-lcp-ps] [I-D.ietf-geopriv-l7-lcp-ps]
Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol; Problem Statement and Location Configuration Protocol; Problem Statement and
Requirements", draft-ietf-geopriv-l7-lcp-ps-07 (work in Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in
progress), March 2008. progress), June 2008.
[I-D.ietf-geopriv-lbyr-requirements] [I-D.ietf-geopriv-lbyr-requirements]
Marshall, R., "Requirements for a Location-by-Reference Marshall, R., "Requirements for a Location-by-Reference
Mechanism", draft-ietf-geopriv-lbyr-requirements-02 (work Mechanism", draft-ietf-geopriv-lbyr-requirements-03 (work
in progress), February 2008. in progress), July 2008.
[I-D.ietf-sip-location-conveyance] [I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol", Session Initiation Protocol",
draft-ietf-sip-location-conveyance-10 (work in progress), draft-ietf-sip-location-conveyance-10 (work in progress),
February 2008. February 2008.
[I-D.winterbottom-geopriv-deref-protocol] [I-D.winterbottom-geopriv-deref-protocol]
Winterbottom, J., Tschofenig, H., Schulzrinne, H., Winterbottom, J., Tschofenig, H., Schulzrinne, H.,
Thomson, M., and M. Dawson, "An HTTPS Location Thomson, M., and M. Dawson, "An HTTPS Location
Dereferencing Protocol Using HELD", Dereferencing Protocol Using HELD",
draft-winterbottom-geopriv-deref-protocol-00 (work in draft-winterbottom-geopriv-deref-protocol-01 (work in
progress), November 2007. progress), July 2008.
Appendix A. HELD Compliance to IETF LCP requirements Appendix A. HELD Compliance to IETF LCP requirements
This appendix describes HELD's compliance to the requirements This appendix describes HELD's compliance to the requirements
specified in the [I-D.ietf-geopriv-l7-lcp-ps]. specified in the [I-D.ietf-geopriv-l7-lcp-ps].
A.1. L7-1: Identifier Choice A.1. L7-1: Identifier Choice
"The L7 LCP MUST be able to carry different identifiers or MUST "The L7 LCP MUST be able to carry different identifiers or MUST
define an identifier that is mandatory to implement. Regarding the define an identifier that is mandatory to implement. Regarding the
skipping to change at page 39, line 8 skipping to change at page 43, line 42
A.3. L7-3: ASP and Access Network Provider Relationship A.3. L7-3: ASP and Access Network Provider Relationship
"The design of the L7 LCP MUST NOT assume a business or trust "The design of the L7 LCP MUST NOT assume a business or trust
relationship between the Application Service Provider (ASP) and the relationship between the Application Service Provider (ASP) and the
Access Network Provider. Requirements for resolving a reference to Access Network Provider. Requirements for resolving a reference to
location information are not discussed in this document." location information are not discussed in this document."
COMPLY COMPLY
HELD describes a location acquisition protocol and has no HELD describes a location acquisition protocol between a Device and a
dependencies on the business or trust relationship between the ASP LIS. In the context of HELD, the LIS is within the Access Network.
and the Access Network Provider. Location acquisition using HELD is Thus, HELD is independent of the business or trust relationship
subject to the restrictions described in Section 10. between the Application Service Provider (ASP) and the Access Network
Provider. Location acquisition using HELD is subject to the
restrictions described in Section 10.
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship A.4. L7-4: Layer 2 and Layer 3 Provider Relationship
"The design of the GEOPRIV Layer 7 Location Configuration Protocol "The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST assume that there is a trust and business relationship between MUST assume that there is a trust and business relationship between
the L2 and the L3 provider. The L3 provider operates the LIS and the L2 and the L3 provider. The L3 provider operates the LIS and
needs to obtain location information from the L2 provider since this needs to obtain location information from the L2 provider since this
one is closest to the end host. If the L2 and L3 provider for the one is closest to the end host. If the L2 and L3 provider for the
same host are different entities, they cooperate for the purposes same host are different entities, they cooperate for the purposes
needed to determine end system locations." needed to determine end system locations."
skipping to change at page 42, line 4 skipping to change at page 46, line 28
James Winterbottom James Winterbottom
Andrew Andrew
PO Box U40 PO Box U40
Wollongong University Campus, NSW 2500 Wollongong University Campus, NSW 2500
AU AU
Phone: +61 2 4221 2938 Phone: +61 2 4221 2938
Email: james.winterbottom@andrew.com Email: james.winterbottom@andrew.com
URI: http://www.andrew.com/ URI: http://www.andrew.com/
Martin Thomson Martin Thomson
Andrew Andrew
PO Box U40 PO Box U40
Wollongong University Campus, NSW 2500 Wollongong University Campus, NSW 2500
AU AU
Phone: +61 2 4221 2915 Phone: +61 2 4221 2915
Email: martin.thomson@andrew.com Email: martin.thomson@andrew.com
URI: http://www.andrew.com/ URI: http://www.andrew.com/
Barbara Stark Barbara Stark
BellSouth BellSouth
Room 7A41 Room 7A43
725 W Peachtree St. 725 W Peachtree St.
Atlanta, GA 30308 Atlanta, GA 30308
US US
Email: barbara.stark@bellsouth.com Email: barbara.stark@att.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 83 change blocks. 
259 lines changed or deleted 468 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/