draft-ietf-geopriv-http-location-delivery-05.txt   draft-ietf-geopriv-http-location-delivery-06.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: August 25, 2008 Expires: October 11, 2008
February 22, 2008 April 9, 2008
HTTP Enabled Location Delivery (HELD) HTTP Enabled Location Delivery (HELD)
draft-ietf-geopriv-http-location-delivery-05.txt draft-ietf-geopriv-http-location-delivery-06.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 August 25, 2008. This Internet-Draft will expire on October 11, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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) as a transport for the protocol.
skipping to change at page 2, line 22 skipping to change at page 2, line 21
4.1. Location by Value . . . . . . . . . . . . . . . . . . . . 7 4.1. Location by Value . . . . . . . . . . . . . . . . . . . . 7
4.2. Location by Reference . . . . . . . . . . . . . . . . . . 7 4.2. Location by Reference . . . . . . . . . . . . . . . . . . 7
4.3. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 7 4.3. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 7
4.3.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 8 4.3.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 8
4.3.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 8 4.3.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 8
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9
5.1. Delivery Protocol . . . . . . . . . . . . . . . . . . . . 9 5.1. Delivery Protocol . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . 13
6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 13 6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 13
6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 13 6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 14
6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 13 6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 14
6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 14 6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 14
6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 14 6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 14
6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 14 6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 15
7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. HELD: URI Definition . . . . . . . . . . . . . . . . . . . . . 18 8. HELDS: URI Definition . . . . . . . . . . . . . . . . . . . . 18
9. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10.1. Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . 20 10.1. Assuring that the proper LIS has been contacted . . . . . 21
10.1.1. Assuring that the proper LIS has been contacted . . . 21 10.2. Protecting responses from modification . . . . . . . . . . 21
10.1.2. Protecting responses from modification . . . . . . . . 21 10.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 22
10.2. Privacy and Confidentiality . . . . . . . . . . . . . . . 22
10.3. Summary of Security Considerations . . . . . . . . . . . . 23
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. HTTP Example Messages . . . . . . . . . . . . . . . . . . 23 11.1. HTTP Example Messages . . . . . . . . . . . . . . . . . . 23
11.2. Simple Location Request Example . . . . . . . . . . . . . 26 11.2. Simple Location Request Example . . . . . . . . . . . . . 26
11.3. Location Request Example for Multiple Location Types . . . 27 11.3. Location Request Example for Multiple Location Types . . . 27
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
12.1. URN Sub-Namespace Registration for 12.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 28 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 28
12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 29 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 29
12.3. MIME Media Type Registration for 'application/held+xml' . 29 12.3. MIME Media Type Registration for 'application/held+xml' . 29
12.4. Error code Registry . . . . . . . . . . . . . . . . . . . 30 12.4. Error code Registry . . . . . . . . . . . . . . . . . . . 30
12.5. URI Registration . . . . . . . . . . . . . . . . . . . . . 31 12.5. URI Registration . . . . . . . . . . . . . . . . . . . . . 31
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
15. Changes since last Version . . . . . . . . . . . . . . . . . . 32 15. Changes since last Version . . . . . . . . . . . . . . . . . . 32
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
16.1. Normative References . . . . . . . . . . . . . . . . . . . 36 16.1. Normative References . . . . . . . . . . . . . . . . . . . 36
16.2. Informative References . . . . . . . . . . . . . . . . . . 37 16.2. Informative References . . . . . . . . . . . . . . . . . . 37
Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 38 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 38
A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 38 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 39
A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 38 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 39
A.3. L7-3: ASP and Access Network Provider Relationship . . . . 39 A.3. L7-3: ASP and Access Network Provider Relationship . . . . 39
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 39 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 40
A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 40 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 40
A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 40 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 41
A.7. L7-7: Network Access Authentication . . . . . . . . . . . 40 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 41
A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 41 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 41
A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 41 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 41
A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 41 A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . . . . . 43 Intellectual Property and Copyright Statements . . . . . . . . . . 44
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 [13] provides some problem statement and requirements document
scenarios in which the Device might rely on its access network to [I-D.ietf-geopriv-l7-lcp-ps] provides some scenarios in which the
provide location information. The LIS service applies to access Device might rely on its access network to provide location
networks employing both wired technology (e.g. DSL, Cable) and information. The LIS service applies to access networks employing
wireless technology (e.g. WiMAX) with varying degrees of Device both wired technology (e.g. DSL, Cable) and wireless technology
mobility. This document describes a protocol that can be used to (e.g. WiMAX) with varying degrees of Device mobility. This document
acquire Location Information (LI) from a Location Information Server describes a protocol that can be used to acquire Location Information
(LIS) within an access network. (LI) from a Location Information Server (LIS) within an access
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.
skipping to change at page 4, line 38 skipping to change at page 4, line 39
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) as a transport 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 [1]. 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),
Rule Maker (RM) and Rule Holder (RH) as defined in RFC 3693, GEOPRIV Rule Maker (RM) and Rule Holder (RH) as defined in RFC 3693, GEOPRIV
Requirements [8] . The terms Location Information Server (LIS), Requirements [RFC3693] . The terms Location Information Server
Access Network, Access Provider (AP) and Access Network Provider are (LIS), Access Network, Access Provider (AP) and Access Network
used in the same context as defined in the L7 LCP Problem statement Provider are used in the same context as defined in the L7 LCP
and Requirements document [13]. The usage of the terms, Civic Problem statement and Requirements document
[I-D.ietf-geopriv-l7-lcp-ps]. The usage of the terms, Civic
Location/Address and Geodetic Location follows the usage in many of Location/Address and Geodetic Location follows the usage in many of
the referenced documents. the referenced documents.
In describing the protocol, the terms "attribute" and "element" are In describing the protocol, the terms "attribute" and "element" are
used according to their context in XML. The term "parameter" is used used according to their context in XML. The term "parameter" is used
in a more general protocol context and can refer to either an XML in a more general protocol context and can refer to either an XML
"attribute" or "element". "attribute" or "element".
3. Overview and Scope 3. Overview and Scope
skipping to change at page 6, line 6 skipping to change at page 6, line 6
for the end user's LI. Since revealing the location of the device for the end user's LI. Since revealing the location of the device
almost invariably reveals some information about the location of the almost invariably reveals some information about the location of the
user of the device, the same level of privacy protection demanded by user of the device, the same level of privacy protection demanded by
a user is required for the device. This approach may require either a user is required for the device. This approach may require either
some additional assurances about the link between device and target, some additional assurances about the link between device and target,
or an acceptance of the limitation that unless the device requires or an acceptance of the limitation that unless the device requires
active user authentication, there is no guarantee that any particular active user authentication, there is no guarantee that any particular
individual is using the device at that instant. individual is using the device at that instant.
The following diagram shows the logical configuration of some of the The following diagram shows the logical configuration of some of the
functional elements identified in [8] and the LIS defined in [13] and functional elements identified in [RFC3693] and the LIS defined in
where this protocol applies, with the Rule Maker and Target [I-D.ietf-geopriv-l7-lcp-ps] and where this protocol applies, with
represented by the role of the Device. the Rule Maker and Target represented by the role of the Device.
Note that only the interfaces relevant to the Device are identified
in the diagram.
+---------------------------------------------+ +---------------------------------------------+
| Access Network Provider | | Access Network Provider |
| | | |
| +--------------------------------------+ | | +--------------------------------------+ |
| | Location Information Server | | | | Location Information Server | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| +------|---------------------'---------+ | | +------|-------------------------------+ |
+----------|---------------------'------------+ +----------|----------------------------------+
| ' |
| ' |
HELD APP HELD
| ' |
Rule Maker - _ +-----------+ +-----------+ Rule Maker - _ +-----------+ +-----------+
o - - | Device | | Location | o - - | Device | | Location |
<U\ | | - - - - | Recipient | <U\ | | - - - - | Recipient |
/ \ _ - - | | APP | | / \ _ - - | | APP | |
Target - - +-----------+ +-----------+ Target - - +-----------+ +-----------+
Figure 1: Significant Roles Figure 1: Significant Roles
The interface between the Location Recipient (LR) and the Device The interface between the Location Recipient (LR) and the Device
and/or LIS is application specific, as indicated by the APP and/or LIS is application specific, as indicated by the APP
annotation in the diagram and it is outside the scope of the annotation in the diagram and it is outside the scope of the
document. An example of an APP interface between a device and LR can document. An example of an APP interface between a device and LR can
be found in the SIP Location Conveyance document [25]. be found in the SIP Location Conveyance document
[I-D.ietf-sip-location-conveyance].
4. Protocol Overview 4. Protocol Overview
The HELD protocol facilitates retrieval of location directly in the A device uses the HELD protocol to retrieve its location either
form of a PIDF-LO document (by value) and indirectly as a Location directly in the form of a PIDF-LO document (by value) and indirectly
URI (by reference). The policy that describes to whom, and how, LI as a Location URI (by reference). The security necessary to ensure
is granted is outside the scope of this document and may be specified the accuracy, privacy and confidentiality of the device's location is
in separate specifications as required. described in the Security Considerations (Section 10).
As described in the L7 LCP problem statement and requirements [13], As described in the L7 LCP problem statement and requirements
the Device must first discover the URI for the LIS for sending the [I-D.ietf-geopriv-l7-lcp-ps], the Device must first discover the URI
HELD protocol requests. The discovery methods are specified in [16]. for the LIS for sending the HELD protocol requests. The discovery
methods are specified in [I-D.ietf-geopriv-lis-discovery].
For the HELD protocol requests, the LIS uses the source IP address of The LIS requires an identifier for the Device in order to determine
the request sent from the Device as the identifier in determining the the appropriate location to include in the location response message.
location of the device. The use of additional identifiers for the In this document, the IP address of the Device, as reflected by the
HELD protocol is outside the scope of this document. source IP address in the location request message, is used as the
identifier. Other identifiers are possible, but are beyond the scope
of this document.
4.1. Location by Value 4.1. Location by Value
Where a Device requires LI directly, it can request that the LIS Where a Device requires LI directly, it can request that the LIS
create a PIDF-LO document. This approach fits well with a create a PIDF-LO document. This approach fits well with a
configuration whereby the device directly makes use of the provided configuration whereby the device directly makes use of the provided
PIDF-LO document. The details on the information that may be PIDF-LO document. The details on the information that may be
included in the PIDF-LO MUST follow the subset of those rules included in the PIDF-LO MUST follow the subset of those rules
relating to the construction of the "location-info" element in the relating to the construction of the "location-info" element in the
PIDF-LO Usage Clarification, Considerations and Recommendations PIDF-LO Usage Clarification, Considerations and Recommendations
document [12]. Further detail is included in the detailed protocol document [I-D.ietf-geopriv-pdif-lo-profile]. Further detail is
section of this document Section 6 included in the detailed protocol section of this document Section 6
4.2. Location by Reference 4.2. Location by Reference
Requesting location directly does not always address the requirements Requesting location directly does not always address the requirements
of an application. A Device can request a location URI instead of of an application. A Device can request a location URI instead of
literal location. A Location URI is a URI [22] of any scheme, which literal location. A Location URI is a URI [RFC3986] of any scheme,
a Location Recipient (LR) can use to retrieve LI. A location URI which a Location Recipient (LR) can use to retrieve LI. A location
provided by a LIS can be assumed to be globally-addressable; that is, URI provided by a LIS can be assumed to be globally-addressable; that
anyone in possession of the URI can access the LIS. However, this is, anyone in possession of the URI can access the LIS. However,
does not in any way suggest that the LIS is bound to reveal the 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 location associated with the location URI. This issue is deemed out
of scope for this document. The merits and drawbacks of using a of scope for this document. The merits and drawbacks of using a
Location URI approach are discussed in [17]. Location URI approach are discussed in
[I-D.ietf-geopriv-lbyr-requirements].
4.3. Device Identifiers, NAT and VPNs 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.
skipping to change at page 8, line 13 skipping to change at page 8, line 20
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.3.2 provides
recommendations to address this issue. recommendations to address this issue.
4.3.1. Devices and VPNs 4.3.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 [16] and an initial query are performed before establishing discovery [I-D.ietf-geopriv-lis-discovery] and an initial query are
the VPN. If a Device performs the HELD query after establishing the performed before establishing the VPN. If a Device performs the HELD
VPN tunnel the Device may receive inaccurate location information. query after establishing the VPN tunnel the Device may receive
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.
It could also be useful for a VPN device to serve as a LIS for other It could also be useful for a VPN device to serve as a LIS for other
location configuration options such as Dynamic Host Configuration location configuration options such as Dynamic Host Configuration
Protocol (DHCP)[23] or Link Layer Discovery Protocol - Media Endpoint Protocol (DHCP)[RFC3825] or Link Layer Discovery Protocol - Media
Discovery (LLDP-MED) [27]. VPN devices that serve as a LIS may Endpoint Discovery (LLDP-MED) [LLDP-MED]. VPN devices that serve as
acquire their own location using HELD. a LIS may acquire their own location using HELD.
4.3.2. LIS Handling of NATs and VPNs 4.3.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 an accurate LI, it
should not provide location information to the requesting device. should not provide location information to the requesting device.
The LIS needs to be configured to recognize identifiers that The LIS needs to be configured to recognize identifiers that
skipping to change at page 9, line 24 skipping to change at page 9, line 29
Section 5.2. A Location Request message from a Device indicates Section 5.2. A Location Request message from a Device indicates
whether location in the form of a PIDF-LO document (with specific whether location in the form of a PIDF-LO document (with specific
type(s) of location) and/or Location URI(s) should be returned. The type(s) of location) and/or Location URI(s) should be returned. The
LIS replies with a locationResponse message, including a PIDF-LO LIS replies with a locationResponse message, including a PIDF-LO
document and/or one or more Location URIs in case of success. In the document and/or one or more Location URIs in case of success. In the
case of an error, the LIS replies with an error message. case of an error, the LIS replies with an error message.
A MIME type "application/held+xml" is registered in Section 12.3 to A MIME type "application/held+xml" is registered in Section 12.3 to
distinguish HELD messages from other XML document bodies. This distinguish HELD messages from other XML document bodies. This
specification follows the recommendations and conventions described specification follows the recommendations and conventions described
in [20], including the naming convention of the type ('+xml' suffix) in [RFC3023], including the naming convention of the type ('+xml'
and the usage of the 'charset' parameter. suffix) and the usage of the 'charset' parameter.
Section 6 contains a more thorough description of the protocol Section 6 contains a more thorough description of the protocol
parameters, valid values, and how each should be handled. Section 7 parameters, valid values, and how each should be handled. Section 7
contains a more specific definition of the structure of these contains a more specific definition of the structure of these
messages in the form of an XML Schema [14]. messages in the form of an XML Schema [W3C.REC-xmlschema-1-20041028].
5.1. Delivery Protocol 5.1. Delivery Protocol
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
skipping to change at page 9, line 45 skipping to change at page 10, line 4
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 must provide authentication, confidentiality and
protection against modification per Section 10.2. protection against modification per Section 10.3.
This document describes the use of a combination of HTTP [3], TLS [2] This document describes the use of a combination of HTTP [RFC2616],
and TCP [18] 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. The successful identities may be provided through schema extensions.
response to a location request message is a document formed of a
"locationResponse" element, unless the request fails, in which case
the LIS MUST provide an error indication document.
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.
5.3. Location Response 5.3. Location Response
The response to a location request MUST contain a PIDF-LO and/or A successful response to a location request MUST contain a PIDF-LO
location URI(s). The response SHOULD contain location information of and/or location URI(s). The response SHOULD contain location
the requested "locationType". The cases whereby a different type of information of the requested "locationType". The cases whereby a
location information MAY be returned are described in Section 6.2. different type of location information MAY be returned are described
in Section 6.2.
5.4. Indicating Errors 5.4. Indicating Errors
If the LIS is unable to provide location information based on the If the LIS is unable to provide location information based on the
received locationRequest message, it MUST return an error message. received locationRequest message, it MUST return an error message.
The LIS may return an error message in response to requests for any The LIS may return an error message in response to requests for any
"locationType". "locationType".
An error indication document consists of an "error" element. The An error indication document consists of an "error" element. The
"error" element MUST include a "code" attribute that indicates the "error" element MUST include a "code" attribute that indicates the
skipping to change at page 11, line 7 skipping to change at page 11, line 12
diagnostic purposes only, and MAY be in any language. The language diagnostic purposes only, and MAY be in any language. The language
of the message SHOULD be indicated with an "xml:lang" attribute. of the message SHOULD be indicated with an "xml:lang" attribute.
6. Protocol Parameters 6. Protocol Parameters
This section describes in detail the parameters that are used for This section describes in detail the parameters that are used for
this protocol. Table 1 lists the top-level components used within this protocol. Table 1 lists the top-level components used within
the protocol and where they are mandatory or optional for each of the the protocol and where they are mandatory or optional for each of the
messages. messages.
+--------------------------+---------------+----------------+-------+ +----------------+----------------+----------------+----------------+
| Parameter | Location | Location | Error | | Parameter | Location | Location | Error |
| | Request | Response | | | | Request | Response | |
+--------------------------+---------------+----------------+-------+ +----------------+----------------+----------------+----------------+
| responseTime | o | | | | responseTime | o | | |
| (Section 6.1) | | | | | (Section 6.1) | | | |
| locationType | o | | | | locationType | o | | |
| (Section 6.2) | | | | | (Section 6.2) | | | |
| code (Section 6.3) | | | m | | code | | | m |
| message (Section 6.4) | | | o | | (Section 6.3) | | | |
| message | | | o |
| (Section 6.4) | | | |
| locationUriSet | | o | | | locationUriSet | | o | |
| (Section 6.5) | | | | | (Section 6.5) | | | |
| Presence (PIDF-LO) | | o | | | Presence | | o | |
| (PIDF-LO) | | | |
| (Section 6.6) | | | | | (Section 6.6) | | | |
+--------------------------+---------------+----------------+-------+ +----------------+----------------+----------------+----------------+
Table 1: Message Parameter Usage Table 1: Message Parameter Usage
6.1. "responseTime" Parameter 6.1. "responseTime" Parameter
The "responseTime" attribute MAY be included in a location request The "responseTime" attribute MAY be included in a location request
message. The "responseTime" attribute includes a time value message. The "responseTime" attribute includes a time value
indicating to the LIS how long the Device is prepared to wait for a indicating to the LIS how long the Device is prepared to wait for a
response and/or a purpose for which the Device needs the location. response or a purpose for which the Device needs the location.
In the case of emergency services, the purpose of obtaining the LI In the case of emergency services, the purpose of obtaining the LI
could be either for routing a call to the appropriate PSAP or could be either for routing a call to the appropriate PSAP or
indicating the location to which responders should be dispatched. indicating the location to which responders should be dispatched.
The values defined for the purpose, emergencyRouting and The values defined for the purpose, "emergencyRouting" and
emergencyDispatch, will likely be governed by jurisdictional "emergencyDispatch", will likely be governed by jurisdictional
policies, and should be configurable on the LIS. policies, and should be configurable on the LIS.
The time value in the "responseTime" attribute is expressed as a non- The time value in the "responseTime" attribute is expressed as a non-
negative integer in units of milliseconds. The time value is negative integer in units of milliseconds. The time value is
indicative only and the LIS is under no obligation to strictly adhere indicative only and the LIS is under no obligation to strictly adhere
to the time limit implied; any enforcement of the time limit is left to the time limit implied; any enforcement of the time limit is left
to the requesting Device. The LIS should provide the most accurate to the requesting Device. The LIS should provide the most accurate
LI that can be determined within the specified interval for the LI that can be determined within the specified interval for the
specific service. specific service.
skipping to change at page 12, line 15 skipping to change at page 12, line 23
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. The LIS SHOULD return location information in a form that is
suited for routing and responding to an emergency call in its suited for routing and responding to an emergency call in its
jurisdiction, specifically by value. The LIS MAY alternatively or jurisdiction, specifically by value. The LIS MAY alternatively or
additionally return a location URI. If the "locationType" element additionally return a location URI. If the LIS believes that the
is absent, this value MUST be assumed as the default. 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. Any civic: The LIS SHOULD return a civic address for the Target.
type of civic address may be returned.
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 LIS
MAY provide additional location types, or it MAY provide alternative MAY provide additional location types, or it MAY provide alternative
types if the request cannot be satisfied for a requested location types if the request cannot be satisfied for a requested location
type. A location URI provided by the LIS is a reference to the most type. 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 current available LI and is not a stable reference to a specific
location. The location types the LIS returns also depend on the location. The location types the LIS returns also depend on the
setting of the optional "exact" attribute, as described in the setting of the optional "exact" attribute, as described in the
following section. following section. 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.
The "SHOULD"-strength requirements on this parameter are included to The "SHOULD"-strength requirements on this parameter are included to
allow for soft-failover. This enables a fixed client configuration allow for soft-failover. This enables a fixed client configuration
that prefers a specific location type without causing location that prefers a specific location type without causing location
requests to fail when that location type is unavailable. For requests to fail when that location type is unavailable. For
example, a notebook computer could be configured to retrieve civic example, a notebook computer could be configured to retrieve civic
addresses, which is usually available from typical home or work addresses, which is usually available from typical home or work
situations. However, when using a wireless modem, the LIS might be situations. However, when using a wireless modem, the LIS might be
unable to provide a civic address and thus provides a geodetic unable to provide a civic address and thus provides a geodetic
address. address.
skipping to change at page 13, line 50 skipping to change at page 14, line 18
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
The "locationUriSet" element, received in a "locationResponse" The "locationUriSet" element, received in a "locationResponse"
message MAY contain any number of "locationURI" elements. It is message MAY contain any number of "locationURI" elements. It is
RECOMMENDED that the LIS allocate a Location URI for each scheme that RECOMMENDED that the LIS allocate a Location URI for each scheme that
it supports and that each scheme is present only once. The held: URI it supports and that each scheme is present only once. The helds:
scheme as defined in Section 8 is one possible scheme for the URI scheme as defined in Section 8 is one possible scheme for the
"locationURI" element. URI schemes and their secure variants, such "locationURI" element. URI schemes and their secure variants, such
as http and https, MUST be regarded as two separate schemes. as http and https, MUST be regarded as two separate schemes.
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.
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.2. 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. by the LIS will expire. The "expires" attribute does not define the
length of time a location received by dereferencing the location URI
will be valid.
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 details on requested or a "locationType" of "any" is requested. The LIS MUST
the information that may be included in the presence parameter (in follow the subset of the rules relating to the construction of the
the form of a PIDF-LO) MUST follow the subset of those rules relating "location-info" element in the PIDF-LO Usage Clarification,
to the construction of the "location-info" element in the PIDF-LO Considerations and Recommendations document
Usage Clarification, Considerations and Recommendations document [I-D.ietf-geopriv-pdif-lo-profile] in generating the PIDF-LO for the
[12]. The LIS MUST follow those rules in generating the PIDF-LO for presence parameter.
the presence parameter in this case. Per the GEOPRIV Location Object
format specified in [10], the "entity" element MUST reflect the
Target of the Location Information. In addition, the default values
for <retransmission-allowed> and <retention-expiry> as specified in
[10] MUST be applied. A default value of "no" SHALL be used for the
<retransmission-allowed> element. A default value of 24 hours SHALL
be used for <retention-expiry> value of any generated PIDF-LO
documents. A LIS MAY provide a shorter value for <retention-expiry>
but MUST NOT provide a value longer than 24 hours.
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 Section 7 for a location response message due to XML schema
constraints. constraints.
7. XML Schema 7. XML Schema
This section gives the XML Schema Definition [14] of the This section gives the XML Schema Definition
[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.
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held" targetNamespace="urn:ietf:params:xml:ns:geopriv:held"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:held="urn:ietf:params:xml:ns:geopriv:held" xmlns:held="urn:ietf:params:xml:ns:geopriv:held"
xmlns:xml="http://www.w3.org/XML/1998/namespace" xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xs:annotation> <xs:annotation>
<xs:documentation source="https://www.ietf.org/rfc/rfcXXXX.txt"> <xs:documentation>
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of This document (RFC xxxx) defines HELD messages.
published RFC and remove this note.]] --> <!-- [[NOTE TO RFC-EDITOR: Please replace XXXX
This document defines HELD messages. with the RFC number for this specification.]] -->
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:import namespace="http://www.w3.org/XML/1998/namespace"/> <xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
<!-- Return Location --> <!-- Return Location -->
<xs:complexType name="returnLocationType"> <xs:complexType name="returnLocationType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence> <xs:sequence>
<xs:element name="locationURI" type="xs:anyURI" <xs:element name="locationURI" type="xs:anyURI"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="expires" type="xs:dateTime" <xs:attribute name="expires" type="xs:dateTime"
use="required"/> use="required"/>
skipping to change at page 18, line 28 skipping to change at page 18, line 38
</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. HELD: URI Definition 8. HELDS: URI Definition
This section defines the schema for a held: URI. This URI schema is This section defines the schema for a helds: URI. This URI schema is
one possible URI scheme for the "locationURI" element, described in one possible URI scheme for the "locationURI" element, described in
Section 6.5.1, in a HELD "locationResponse " message. In this case, Section 6.5.1, in a HELD "locationResponse " message. In this case,
the held: URI indicates to the Device where to obtain the actual the helds: URI indicates to the Device where to obtain the actual
location information for a Target. In addition, the held: URI can be location information for a Target. In addition, the helds: URI can
the result of the LIS discovery process [16] and indicates to the be the result of the LIS discovery process
Device the LIS from which LI should be requested. [I-D.ietf-geopriv-lis-discovery] and indicates to the Device the LIS
from which LI should be requested.
The held: URI is defined using a subset of the URI schema specified The helds: URI is defined using a subset of the URI schema specified
in Appendix A. of RFC3986 [22] and the associated URI Guidelines in Appendix A. of RFC3986 [RFC3986] and the associated URI
[24] per the following ABNF syntax: Guidelines [RFC4395] per the following ABNF syntax:
HELD-URI = "held" ":" "//" host [":" port] [ path-absolute ] [? query] HELD-URI = "helds" ":" "//" host [":" port] [ path-absolute ] [? query]
The following summarizes the primary elements comprising the HELD- The following summarizes the primary elements comprising the HELD-
URI: URI:
host: As defined in RFC3986 [22] host: As defined in RFC3986 [RFC3986]
port: As defined in RFC3986 [22]. 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 [22]. path-absolute As defined in RFC3986 [RFC3986].
query: As defined in RFC3986 [22]. 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 held: URI is not intended to be human-readable text, therefore it The helds: URI is not intended to be human-readable text, therefore
is encoded entirely in US-ASCII. The following are examples of held: it is encoded entirely in US-ASCII. The following are examples of
URIs: helds: URIs:
held://ls.example.com:49152/thisLocation?token=xyz987 helds://ls.example.com:49152/thisLocation?token=xyz987
held://ls.example.com/THISLOCATION helds://ls.example.com:5432/THISLOCATION?foobar=abc123
held://ls.example.com/THISlocation helds://ls.example.com:5432/THISlocation?foobar=ABC123
held://ls.example.com/civic helds://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 HELD-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 held: URI is contained in a "locationURI" In the case where the helds: URI is contained in a "locationURI"
element in a HELD locationResponse message, it is important to note element in a HELD locationResponse message, it is important to note
that the URI is only valid for the length of time indicated by the that the URI is only valid for the length of time indicated by the
"expires" attribute. "expires" attribute.
9. HTTP Binding 9. HTTP Binding
This section describes the use of HTTP [3] as a transport mechanism This section describes the use of HTTP [RFC2616] as a transport
for this protocol, which all conforming implementations MUST support. mechanism for this protocol, which all conforming implementations
MUST support.
The request is carried in the body of an HTTP POST request. The MIME The request is carried in the body of an HTTP POST request. The MIME
type of both request and response bodies should be 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 headers so that they are consistent with
the contents of the message. In particular, the cache control header the contents of the message. In particular, the cache control header
SHOULD be set to disable the HTTP caching of any PIDF-LO document or SHOULD be set to disable the HTTP caching of any PIDF-LO document or
Location URIs. Otherwise, there is the risk of stale locations Location URIs. Otherwise, there is the risk of stale locations
and/or the unauthorized disclosure of the LI. This also allows the and/or the unauthorized disclosure of the LI. This also allows the
LIS to control any caching with the "expires" parameter. The HTTP LIS to control any caching with the "expires" parameter. The HTTP
status code MUST indicate a 2xx series response for all HELD status code MUST indicate a 2xx series response for all HELD
locationResponse messages. locationResponse and error messages.
The use of HTTP also includes a default behaviour, which is triggered The use of HTTP also includes a default behaviour, which is triggered
by a GET request, or a POST with no request body. If either of these by a GET request, or a POST with no request body. If either of these
queries are received, the LIS MUST attempt to provide either a queries are received, the LIS MUST attempt to provide either a
PIDF-LO document or a Location URI, as if the request was a location PIDF-LO document or a Location URI, as if the request was a location
request. request.
The implementation of HTTP as a transport mechanism MUST implement The implementation of HTTP as a transport mechanism MUST implement
TLS as described in [4]. TLS provides message integrity and privacy TLS as described in [RFC2818]. TLS provides message integrity and
between Device and LIS. The LIS MUST use the server authentication privacy between Device and LIS. The LIS MUST use the server
method described in [4]; the Device MUST fail a request if server authentication method described in [RFC2818]; the Device MUST fail a
authentication fails, except in the event of an emergency. 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
[13]. An in-depth discussion of the security considerations [I-D.ietf-geopriv-l7-lcp-ps]. An in-depth discussion of the security
applicable to the use of Location URIs and by reference provision of considerations applicable to the use of Location URIs and by
LI is included in [17]. reference provision of LI is included in
[I-D.ietf-geopriv-lbyr-requirements].
By using the HELD protocol, the client and the LIS expose themselves By using the HELD protocol, the client and the LIS expose themselves
to two types of risk: to two types of risk:
Accuracy: Client receives incorrect location information Accuracy: Client receives incorrect location information
Privacy: An unauthorized entity receives location information Privacy: An unauthorized entity receives location information
These two risks are addressed in the two sections below, followed by The provision of an accurate and privacy/confidentiality protected
a summary of the security considerations for implementations of the location to the requestor depends on the success of five steps:
HELD protocol.
10.1. Accuracy
The provision of an accurate location to the requestor depends on the
success of four steps:
1. The client must determine the proper LIS. 1. The client must determine the proper LIS.
2. The client must connect to the proper LIS. 2. The client must connect to the proper LIS.
3. The LIS must be able to return the desired location. 3. The LIS must be able to identify the device by its identifier
4. HELD messages must be transmitted unmodified between the LIS (IP Address).
4. The LIS must be able to return the desired location.
5. HELD messages must be transmitted unmodified between the LIS
and the client. and the client.
Of these, only the second and the fourth are within the scope of this Of these, only the second, third and the fifth are within the scope
document. The first step is based on either manual configuration or of this document. The first step is based on either manual
on the LIS discovery defined in [16], in which appropriate security configuration or on the LIS discovery defined in
considerations are already discussed. The third step is dependent on [I-D.ietf-geopriv-lis-discovery], in which appropriate security
the specific positioning capabilities of the LIS, and is thus outside considerations are already discussed. The fourth step is dependent
the scope of this document. on the specific positioning capabilities of the LIS, and is thus
outside the scope of this document.
10.1.1. Assuring that the proper LIS has been contacted
After the client has initiated a connection to a LIS, it can receive
different levels of assurance that this LIS is the proper LIS based
on whether the proper LIS is identified by a domain name or an IP
address.
When the LIS is identified by a domain name and the HELD transaction 10.1. Assuring that the proper LIS has been contacted
is conducted using TLS [2], the LIS can authenticate itself to the
client using the standard mechanism of presenting a certificate
binding that domain name to the public key used in TLS. Therefore,
any binding of HELD MUST be capable of being transacted over TLS so
that the client can request the above authentication, and a LIS
implementation for a binding MUST include this feature. Note that in
order for the presented certificate to be valid at the client, the
client must be able to validate the certificate; in particular, the
validation path of the certificate must end in one of the client's
trust anchors, even if that trust anchor is the LIS certificate
itself.
When the proper LIS is identified by an IP address, there is a risk This document assumes that the LIS to be contacted is identified
that a malicious LIS could mimic the proper LIS by spoofing that IP either by an IP address or a domain name, as is the case for a LIS
address. If the client deems this risk unacceptable, it is discovered as described in LIS Discovery
recommended that the client perform a DNS lookup on the corresponding [I-D.ietf-geopriv-lis-discovery]. When the HELD transaction is
domain name in the in-addr.arpa domain to determine a domain name for conducted using TLS [RFC4346], the LIS can authenticate its identity,
the LIS. If a domain name is available, then the standard TLS either as a domain name or as an IP address, to the client by
authentication mechanism can then be used to authenticate the presenting a certificate containing that identifier as a
identity of the LIS. If not, then the client can obtain no further subjectAltName (i.e., as an iPAddress or dNSName, respectively). In
assurance about the authenticity of the contacted LIS. In order to the case of the HTTP binding described above, this is exactly the
minimize the probability of such spoofing attacks, administrative authentication described by TLS [RFC2818]. Any binding of HELD MUST
domains that offer a LIS SHOULD take measures to prevent IP address be capable of being transacted over TLS so that the client can
spoofing as described in [5] and [9]. request the above authentication, and a LIS implementation for a
binding MUST include this feature. Note that in order for the
presented certificate to be valid at the client, the client must be
able to validate the certificate. In particular, the validation path
of the certificate must end in one of the client's trust anchors,
even if that trust anchor is the LIS certificate itself.
10.1.2. Protecting responses from modification 10.2. Protecting responses from modification
In order to prevent that response from being modified en route, In order to prevent that response from being modified en route,
messages must be transmitted over an integrity-protected channel. messages must be transmitted over an integrity-protected channel.
When the transaction is being conducted over TLS (a required feature When the transaction is being conducted over TLS (a required feature
per Section 10.1.1), the channel will be integrity protected by per Section 10.1), the channel will be integrity protected by
appropriate ciphersuites. When TLS is not used, this protection will appropriate ciphersuites. When TLS is not used, this protection will
vary depending on the binding; in most cases, without protection from vary depending on the binding; in most cases, without protection from
TLS, the response will not be protected from modification en route. TLS, the response will not be protected from modification en route.
10.2. Privacy and Confidentiality 10.3. Privacy and Confidentiality
Location information returned by the LIS must be protected from Location information returned by the LIS must be protected from
access by unauthorized parties, whether those parties request the access by unauthorized parties, whether those parties request the
location from the LIS or intercept it en route. As in section location from the LIS or intercept it en route. As in section
Section 10.1.2, transactions conducted over TLS with appropriate Section 10.2, transactions conducted over TLS with appropriate
ciphersuites are protected from access by unauthorized parties en ciphersuites are protected from access by unauthorized parties en
route. Conversely, in most cases, when not conducted over TLS, the route. Conversely, in most cases, when not conducted over TLS, the
response will be accessible while en route from the LIS to the response will be accessible while en route from the LIS to the
requestor. requestor.
Because HELD is an LCP and identifies clients and targets by IP Because HELD is an LCP and identifies clients and targets by IP
addresses, a requestor is authorized to access location for an IP addresses, a requestor is authorized to access location for an IP
address only if it is the holder of that IP address. The LIS MUST address only if it is the holder of that IP address. The LIS MUST
verify that the client is the target of the returned location, i.e., verify that the client is the target of the returned location, i.e.,
the LIS MUST NOT provide location to other entities than the target. the LIS MUST NOT provide location to other entities than the target.
Note that this is a necessary, but not sufficient criterion for Note that this is a necessary, but not sufficient criterion for
authorization. A LIS MAY deny requests according to any local authorization. A LIS MAY deny requests according to any local
policy. policy.
A prerequisite for meeting this requirement is that the LIS must have A prerequisite for meeting this requirement is that the LIS must have
some assurance of the identity of the client. Since the target of some assurance of the identity of the client. Since the target of
the returned location is identified by an IP address, simply sending the returned location is identified by an IP address, simply sending
the response to this IP address will provide sufficient assurance in the response to this IP address will provide sufficient assurance in
many cases. This is the default mechanism in HELD for assuring that many cases. This is the default mechanism in HELD for assuring that
location is given only authorized clients; LIS implementations MUST location is given only to authorized clients; LIS implementations
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 URI that would result in another Device's could request a Location Object or Location URI that would result in
location. One or more of the following approaches are RECOMMENDED to another Device's location. In addition, in cases where a Device
limit this exposure: drops off the network for various reasons, the re-use of the Device's
IP address could result in another Device receiving the original
Device's location rather than its own location. One or more of the
following approaches are RECOMMENDED to limit these exposures:
o Location URIs SHOULD have a limited lifetime, as reflected by the o Location URIs SHOULD 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 6.5.2.
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 [9]. 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, other measures may not be necessary.
When there are further mechanisms available to authenticate ownership When there are further mechanisms available to authenticate ownership
of the IP address, the LIS SHOULD use them to authenticate that the 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 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 transaction, the client could present a certificate with a public key
bound to an IPv6 Cryptographically Generated Address, and the LIS bound to an IPv6 Cryptographically Generated Address, and the LIS
could verify this binding. could verify this binding.
10.3. Summary of Security Considerations
The following summarizes the security considerations for
implementations of the HELD protocol:
o All bindings MUST provide the following security services:
* Authentication of a LIS domain name
* Integrity of messages between the client and the LIS
* Confidentiality of messages between the client and the LIS
o It is RECOMMENDED that all bindings use TLS.
o For the HTTP binding, TLS MUST be implemented. The server
authentication methods described in HTTP on TLS [4] MUST be
implemented.
o A LIS implementation for a binding MUST support the specified
security features
o A LIS MUST verify that the requestor is the target of the returned
location.
o A LIS MUST support operation when the only client authentication
available is via IP return routability.
o A LIS SHOULD set expiration times for location URIs it issues.
o Administrative domains SHOULD take measures to prevent IP address
spoofing.
11. Examples 11. Examples
The following sections provide basic HTTP examples, a simple location
request example and a location request for multiple location types
example along with the relevant location responses. To focus 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
addition, sections of XML not relevant to the example are replaced
with comments.
11.1. HTTP Example Messages 11.1. HTTP Example Messages
The examples in this section show a complete HTTP message that The examples in this section show a complete HTTP 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 /location HTTP/1.1
skipping to change at page 25, line 4 skipping to change at page 25, line 4
Host: lis.example.com 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"/>
The successful response to either of these requests is a PIDF-LO Since neither of these requests includes a "locationType" element,
document. The following response shows a minimal PIDF-LO response. the successful response to either of these requests may contain any
type of location. The following shows a response containing a
minimal PIDF-LO.
HTTP/1.x 200 OK HTTP/1.x 200 OK
Server: Example LIS Server: Example LIS
Date: Tue, 10 Jan 2006 03:42:29 GMT Date: Tue, 10 Jan 2006 03:42:29 GMT
Expires: Tue, 10 Jan 2006 03:42:29 GMT Expires: Tue, 10 Jan 2006 03:42:29 GMT
Cache-control: private Cache-control: private
Content-Type: application/held+xml Content-Type: application/held+xml
Content-Length: 594 Content-Length: 594
<?xml version="1.0"?> <?xml version="1.0"?>
skipping to change at page 25, line 32 skipping to change at page 25, line 34
<location-info> <location-info>
<Point xmlns="http://www.opengis.net/gml" <Point xmlns="http://www.opengis.net/gml"
srsName="urn:ogc:def:crs:EPSG::4326"> srsName="urn:ogc:def:crs:EPSG::4326">
<pos>-34.407 150.88001</pos> <pos>-34.407 150.88001</pos>
</Point> </Point>
</location-info> </location-info>
<usage-rules> <usage-rules>
<retention-expiry> <retention-expiry>
2006-01-11T03:42:28+00:00</retention-expiry> 2006-01-11T03:42:28+00:00</retention-expiry>
</usage-rules> </usage-rules>
<method>Wiremap</method>
</geopriv> </geopriv>
</status> </status>
<timestamp>2006-01-10T03:42:28+00:00</timestamp> <timestamp>2006-01-10T03:42:28+00:00</timestamp>
</tuple> </tuple>
</presence> </presence>
</locationResponse> </locationResponse>
The error response to either of these requests is an error document. The error response to either of these requests is an error document.
The following response shows an example error response. The following response shows an example error response.
HTTP/1.x 200 OK HTTP/1.x 200 OK
skipping to change at page 26, line 19 skipping to change at page 26, line 19
Expires: Tue, 10 Jan 2006 03:49:20 GMT Expires: Tue, 10 Jan 2006 03:49:20 GMT
Cache-control: private Cache-control: private
Content-Type: application/held+xml Content-Type: application/held+xml
Content-Length: 135 Content-Length: 135
<?xml version="1.0"?> <?xml version="1.0"?>
<error xmlns="urn:ietf:params:xml:ns:geopriv:held" <error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="locationUnknown" code="locationUnknown"
message="Unable to determine location"/> message="Unable to determine location"/>
Note: To focus on important portions of messages, all examples
following this note do not show HTTP headers or the XML prologue.
In addition, sections of XML not relevant to the example are
replaced with comments.
11.2. Simple Location Request Example 11.2. Simple Location Request Example
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 response to this location request is a list of Location URIs. The example response to this location request contains a list of
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>held://ls.example.com:9768/357yc6s64ceyoiuy5ax3o <locationURI>helds://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 27, line 28 skipping to change at page 27, line 28
civic civic
locationURI locationURI
</locationType> </locationType>
</locationRequest> </locationRequest>
The corresponding Location Response message includes the requested The corresponding Location Response message includes the requested
location information, including two location URIs. location information, including two 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>held://ls.example.com:9768/357yc6s64ceyoiuy5ax3o <locationURI>helds://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>
<presence xmlns="urn:ietf:params:xml:ns:pidf:geopriv10" <presence xmlns="urn:ietf:params:xml:ns:pidf:geopriv10"
entity="pres:ae3be8585902e2253ce2@10.102.23.9"> entity="pres:ae3be8585902e2253ce2@10.102.23.9">
<tuple id="lisLocation"> <tuple id="lisLocation">
<status> <status>
<geopriv> <geopriv>
<location-info> <location-info>
skipping to change at page 28, line 44 skipping to change at page 28, line 44
12. IANA Considerations 12. IANA Considerations
This document requires several IANA registrations detailed in the This document requires several IANA registrations detailed in the
following sections. following sections.
12.1. URN Sub-Namespace Registration for 12.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held urn:ietf:params:xml:ns:geopriv:held
This section registers a new XML namespace, This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:held", per the guidelines in [7]. "urn:ietf:params:xml:ns:geopriv:held", per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:held URI: urn:ietf:params:xml:ns:geopriv:held
Registrant Contact: IETF, GEOPRIV working group, Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com). (geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head> <head>
<title>HELD Messages</title> <title>HELD Messages</title>
</head> </head>
skipping to change at page 29, line 18 skipping to change at page 29, line 19
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head> <head>
<title>HELD Messages</title> <title>HELD Messages</title>
</head> </head>
<body> <body>
<h1>Namespace for HELD Messages</h1> <h1>Namespace for HELD Messages</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held</h2> <h2>urn:ietf:params:xml:ns:geopriv:held</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.]] with the RFC number for this specification.]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p> <p>See RFCXXXX</p>
</body> </body>
</html> </html>
END END
12.2. XML Schema Registration 12.2. XML Schema Registration
This section registers an XML schema as per the guidelines in [7]. This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:geopriv:held URI: urn:ietf:params:xml:schema:geopriv:held
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).
Schema: The XML for this schema can be found as the entirety of Schema: The XML for this schema can be found as the entirety of
Section 7 of this document. Section 7 of this document.
12.3. MIME Media Type Registration for 'application/held+xml' 12.3. MIME Media Type Registration for 'application/held+xml'
This section registers the "application/held+xml" MIME type. This section registers the "application/held+xml" MIME type.
skipping to change at page 29, line 47 skipping to change at page 30, line 4
This section registers the "application/held+xml" MIME type. This section registers the "application/held+xml" MIME type.
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type application/held+xml Subject: Registration of MIME media type application/held+xml
MIME media type name: application MIME media type name: application
MIME subtype name: held+xml MIME subtype name: held+xml
Required parameters: (none) Required parameters: (none)
Optional parameters: charset Optional parameters: charset
Indicates the character encoding of enclosed XML. Default is Indicates the character encoding of enclosed XML. Default is
UTF-8. UTF-8.
Encoding considerations: Uses XML, which can employ 8-bit Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See RFC characters, depending on the character encoding used. See RFC
3023 [20], section 3.2. 3023 [RFC3023], section 3.2.
Security considerations: This content type is designed to carry Security considerations: This content type is designed to carry
protocol data related to the location of an entity, which could protocol data related to the location of an entity, which could
include information that is considered private. Appropriate include information that is considered private. Appropriate
precautions should be taken to limit disclosure of this precautions should be taken to limit disclosure of this
information. information.
Interoperability considerations: This content type provides a basis Interoperability considerations: This content type provides a basis
for a protocol for a protocol
Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number for this specification.]] replace XXXX with the RFC number for this specification.]
Applications which use this media type: Location information Applications which use this media type: Location information
providers and consumers. providers and consumers.
Additional Information: Magic Number(s): (none) Additional Information: Magic Number(s): (none)
File extension(s): .xml File extension(s): .xml
Macintosh File Type Code(s): (none) Macintosh File Type Code(s): (none)
Person & email address to contact for further information: Mary Person & email address to contact for further information: Mary
Barnes <mary.barnes@nortel.com> Barnes <mary.barnes@nortel.com>
Intended usage: LIMITED USE Intended usage: LIMITED USE
Author/Change controller: The IETF Author/Change controller: The IETF
Other information: This media type is a specialization of Other information: This media type is a specialization of
application/xml [20], and many of the considerations described application/xml [RFC3023], and many of the considerations
there also apply to application/held+xml. described there also apply to application/held+xml.
12.4. Error code Registry 12.4. Error code Registry
This document requests that the IANA create a new registry for the This document requests that the IANA create a new registry for the
HELD protocol including an initial registry for error codes. The HELD protocol including an initial registry for error codes. The
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: New error codes are allocated on Registration/Assignment Procedures: Following the policies outlined
a first-come/first-serve basis with specification required. in [I-D.narten-iana-considerations-rfc2434bis], the IANA policy
for assigning new values for the Error codes for HELD shall be
Specification Required: values and their meanings must be
documented in an RFC or in some other permanent and readily
available reference, in sufficient detail that interoperability
between independent implementations is 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.
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.
skipping to change at page 31, line 23 skipping to change at page 31, line 31
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".
12.5. URI Registration 12.5. URI Registration
The following summarizes the information necessary to register the The following summarizes the information necessary to register the
held: URI. [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the helds: URI. [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the
RFC number for this specification in the following list.] RFC number for this specification in the following list.]
URI Scheme Name: held URI Scheme Name: helds
Status: permanent Status: permanent
URI Scheme syntax: See section URI Scheme syntax: See section
URI Scheme Semantics: The held: URI is intended to be used as a URI Scheme Semantics: The helds: 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 RFCXXXX. Further detail is provided in Section 8 of RFCXXXX.
Encoding Considerations: The HELD: 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 RFCXXXX, the GEOPRIV Location De-reference Protocol described in RFCXXXX, the GEOPRIV Location De-reference Protocol
[26] and GEOPRIV Location Information Server Discovery [16]. [I-D.winterbottom-geopriv-deref-protocol] and GEOPRIV Location
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 [26]. This URI may also be a result of the reference Protocol [I-D.winterbottom-geopriv-deref-protocol].
GEOPRIV Location Information Server Discovery [16] and thus used This URI may also be a result of the GEOPRIV Location Information
as the target for the HELD protocol request messages. Refer to Server Discovery [I-D.ietf-geopriv-lis-discovery] and thus used as
Section 8 in RFXXXX for further detail and a particular example on the target for the HELD protocol request messages. Refer to
the lack of permanence of a specific HELD: URI and thus the Section 8 in RFC XXXX for further detail and a particular example
on the lack of permanence of a specific HELDS: URI and thus the
importance of using these URIs only within the specific contexts importance of using these URIs only within the specific contexts
outlined in the references. outlined in the references.
Security considerations: Section 10 in RFXXXX 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 held: URI. Section 6.5.1 in RFCXXXX also integrity of the helds: 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 [26], References: RFC XXXX, GEOPRIV Location De-reference Protocol
GEOPRIV Location Information Server Discovery [16] [I-D.winterbottom-geopriv-deref-protocol], GEOPRIV Location
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, Guy Caron, Martin Dawson, Lisa Dusseault, Jerome
Grenier, Ted Hardie, Neil Justusson, Tat Lam, Marc Linsner, Patti Grenier, Ted Hardie, Cullen Jennings, Neil Justusson, Tat Lam, Marc
McCalmont, Roger Marshall, Perry Prozeniuk, Carl Reed, Brian Rosen, Linsner, Patti McCalmont, Roger Marshall, Perry Prozeniuk, Carl Reed,
John Schnizlein, Shida Schubert, Henning Schulzrinne, Ed Shrum, Doug Brian Rosen, John Schnizlein, Shida Schubert, Henning Schulzrinne, Ed
Stuard and Hannes Tschofenig. 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 05 to 06 (2nd WGLC comments):
1) Updated security section based on WG feedback, including
condensing section 10.1.1 (Assuring the proper LIS has been
contacted), restructuring sections by flattening, adding an
additional step to the list that had been in the Accuracy section and
removing summary section.
2) Changed URI schema to "helds" to address concerns over referential
integrity and for consistency with mandate of TLS for HELD.
3) Editorial clarifications including fixing examples to match HELD
URI definition (e.g., adding port, adding randomness to URI examples,
etc.)
4) Updated references removing unused references and moving
requirements docs to Informational Reference section to avoid
downrefs.
Changes from WG 04 to 05 (WGLC comments): Changes from WG 04 to 05 (WGLC comments):
1) Totally replaced the security section with the details provided by 1) Totally replaced the security section with the details provided by
Richard Barnes so that we don't need a reference to the location Richard Barnes so that we don't need a reference to the location
security document. security document.
2) Fixed error codes in schema to allow extensibility. Change the 2) Fixed error codes in schema to allow extensibility. Change the
IANA registration to be "specification required". IANA registration to be "specification required".
3) Cleaned up the HELD: URI description, per comments from Martin and 3) Cleaned up the HELD: URI description, per comments from Martin and
skipping to change at page 36, line 9 skipping to change at page 36, line 36
9) Clarified that the source IP address in the request is used as the 9) Clarified that the source IP address in the request is used as the
identifier for the target/device for the HELD protocol as defined in identifier for the target/device for the HELD protocol as defined in
this document. this document.
10) Miscellaneous editorial clarifications. 10) Miscellaneous editorial clarifications.
16. References 16. References
16.1. Normative References 16.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
RFC 2246, January 1999. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[5] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[6] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
Language) XML-Signature Syntax and Processing", RFC 3275,
March 2002.
[7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[8] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[9] 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.
[10] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[11] Thomson, M. and J. Winterbottom, "Revised Civic Location Format [I-D.ietf-geopriv-pdif-lo-profile]
for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-07 (work in Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
progress), December 2007.
[12] 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 (work Recommendations", draft-ietf-geopriv-pdif-lo-profile-11
in progress), February 2008. (work in progress), February 2008.
[13] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location
Configuration Protocol; Problem Statement and Requirements",
draft-ietf-geopriv-l7-lcp-ps-06 (work in progress),
November 2007.
[14] Thompson, H., Maloney, M., Beech, D., and N. Mendelsohn, "XML [W3C.REC-xmlschema-1-20041028]
Schema Part 1: Structures Second Edition", World Wide Web Maloney, M., Thompson, H., Beech, D., and N. Mendelsohn,
Consortium Recommendation REC-xmlschema-1-20041028, "XML Schema Part 1: Structures Second Edition", World Wide
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>.
[15] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second [W3C.REC-xmlschema-2-20041028]
Edition", World Wide Web Consortium Recommendation REC- Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
xmlschema-2-20041028, October 2004, Second Edition", World Wide Web Consortium
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>.
[16] Thomson, M. and J. Winterbottom, "Discovering the Local [I-D.ietf-geopriv-lis-discovery]
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-00 (work in progress),
December 2007. December 2007.
[17] Marshall, R., "Requirements for a Location-by-Reference
Mechanism", draft-ietf-geopriv-lbyr-requirements-01 (work in
progress), October 2007.
16.2. Informative References 16.2. Informative References
[18] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
September 1981. RFC 793, September 1981.
[19] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
and Instant Messaging", RFC 2778, February 2000.
[20] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[21] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Types", RFC 3023, January 2001.
Session Initiation Protocol", RFC 3261, June 2002.
[22] 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, RFC 3986, Resource Identifier (URI): Generic Syntax", STD 66,
January 2005. RFC 3986, January 2005.
[23] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location Configuration Protocol Option for Coordinate-based
Configuration Information", RFC 3825, July 2004. Location Configuration Information", RFC 3825, July 2004.
[24] 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.
[25] Polk, J. and B. Rosen, "Location Conveyance for the Session [I-D.narten-iana-considerations-rfc2434bis]
Initiation Protocol", draft-ietf-sip-location-conveyance-09 Narten, T. and H. Alvestrand, "Guidelines for Writing an
(work in progress), November 2007. IANA Considerations Section in RFCs",
draft-narten-iana-considerations-rfc2434bis-09 (work in
progress), March 2008.
[26] Winterbottom, J., Tschofenig, H., Schulzrinne, H., Thomson, M., [I-D.ietf-geopriv-l7-lcp-ps]
and M. Dawson, "An HTTPS Location Dereferencing Protocol Using Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
HELD", draft-winterbottom-geopriv-deref-protocol-00 (work in Location Configuration Protocol; Problem Statement and
Requirements", draft-ietf-geopriv-l7-lcp-ps-07 (work in
progress), March 2008.
[I-D.ietf-geopriv-lbyr-requirements]
Marshall, R., "Requirements for a Location-by-Reference
Mechanism", draft-ietf-geopriv-lbyr-requirements-02 (work
in progress), February 2008.
[I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol",
draft-ietf-sip-location-conveyance-10 (work in progress),
February 2008.
[I-D.winterbottom-geopriv-deref-protocol]
Winterbottom, J., Tschofenig, H., Schulzrinne, H.,
Thomson, M., and M. Dawson, "An HTTPS Location
Dereferencing Protocol Using HELD",
draft-winterbottom-geopriv-deref-protocol-00 (work in
progress), November 2007. progress), November 2007.
[27] TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media [LLDP-MED]
TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
Endpoint Discovery". Endpoint Discovery".
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 [13]. 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
latter aspect, such an identifier is only appropriate if it is from latter aspect, such an identifier is only appropriate if it is from
the same realm as the one for which the location information service the same realm as the one for which the location information service
maintains identifier to location mapping." maintains identifier to location mapping."
COMPLY COMPLY
skipping to change at page 41, line 24 skipping to change at page 42, line 4
HELD makes no assumption about the network topology. HELD doesn't HELD makes no assumption about the network topology. HELD doesn't
require that the device know its external IP address, except where require that the device know its external IP address, except where
that is required for discovery of the LIS. that is required for discovery of the LIS.
A.9. L7-9: Discovery Mechanism A.9. L7-9: Discovery Mechanism
"The L7 LCP MUST define a single mandatory to implement discovery "The L7 LCP MUST define a single mandatory to implement discovery
mechanism." mechanism."
COMPLY COMPLY
HELD uses the discovery mechanism in
HELD uses the discovery mechanism in [16]. [I-D.ietf-geopriv-lis-discovery].
A.10. L7-10: PIDF-LO Creation A.10. L7-10: PIDF-LO Creation
"When a LIS creates a PIDF-LO per RFC 4119 then it MUST put the "When a LIS creates a PIDF-LO per RFC 4119 then it MUST put the
<geopriv> element into the <device> element of the presence document <geopriv> element into the <device> element of the presence document
(see RFC 4479). This ensures that the resulting PIDF-LO document, (see RFC 4479). This ensures that the resulting PIDF-LO document,
which is subsequently distributed to other entities, conforms to the which is subsequently distributed to other entities, conforms to the
rules outlined in ". [12] rules outlined in ". [I-D.ietf-geopriv-pdif-lo-profile]
COMPLY COMPLY
HELD protocol overview (Section 4 ) describes the requirements on the HELD protocol overview (Section 4 ) describes the requirements on the
LIS in creating the PIDF-LO and prescribes that the PIDF-LO generated LIS in creating the PIDF-LO and prescribes that the PIDF-LO generated
by the LIS MUST conform to [12]. by the LIS MUST conform to [I-D.ietf-geopriv-pdif-lo-profile].
Authors' Addresses Authors' Addresses
Mary Barnes (editor) Mary Barnes (editor)
Nortel Nortel
2201 Lakeside Blvd 2201 Lakeside Blvd
Richardson, TX Richardson, TX
Email: mary.barnes@nortel.com Email: mary.barnes@nortel.com
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/
skipping to change at page 43, line 44 skipping to change at line 1903
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 137 change blocks. 
356 lines changed or deleted 365 lines changed or added

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