draft-ietf-geopriv-http-location-delivery-16.txt   rfc5985.txt 
GEOPRIV WG M. Barnes, Ed. Internet Engineering Task Force (IETF) M. Barnes, Ed.
Internet-Draft Nortel Request for Comments: 5985 Polycom
Intended status: Standards Track Category: Standards Track September 2010
Expires: March 1, 2010 ISSN: 2070-1721
Aug 28, 2009
HTTP Enabled Location Delivery (HELD)
draft-ietf-geopriv-http-location-delivery-16.txt
Status of this Memo HTTP-Enabled Location Delivery (HELD)
This Internet-Draft is submitted to IETF in full conformance with the Abstract
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document defines a Layer 7 Location Configuration Protocol (L7
Task Force (IETF), its areas, and its working groups. Note that LCP) and describes the use of HTTP and HTTP/TLS as transports for the
other groups may also distribute working documents as Internet- L7 LCP. The L7 LCP is used for retrieving location information from
Drafts. a server within an access network. It includes options for
retrieving location information in two forms: by value and by
reference. The protocol is an extensible application-layer protocol
that is independent of the session layer.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on March 1, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5985.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
A Layer 7 Location Configuration Protocol (L7 LCP) is described that described in the Simplified BSD License.
is used for retrieving location information from a server within an
access network. The protocol includes options for retrieving
location information in two forms: by value and by reference. The
protocol is an extensible application-layer protocol that is
independent of session-layer. This document describes the use of
HyperText Transfer Protocol (HTTP) and HTTP over Transport Layer
Security (HTTP/TLS) as transports for the protocol.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 7 4.1. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 6
4.1.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 7 4.1.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 6
4.1.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 8 4.1.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 7
4.2. Location by Value . . . . . . . . . . . . . . . . . . . . 8 4.2. Location by Value . . . . . . . . . . . . . . . . . . . . 7
4.3. Location by Reference . . . . . . . . . . . . . . . . . . 9 4.3. Location by Reference . . . . . . . . . . . . . . . . . . 8
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8
5.1. Location Request . . . . . . . . . . . . . . . . . . . . . 10 5.1. Location Request . . . . . . . . . . . . . . . . . . . . . 9
5.2. Location Response . . . . . . . . . . . . . . . . . . . . 10 5.2. Location Response . . . . . . . . . . . . . . . . . . . . 9
5.3. Indicating Errors . . . . . . . . . . . . . . . . . . . . 10 5.3. Indicating Errors . . . . . . . . . . . . . . . . . . . . 9
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10
6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11 6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 10
6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12 6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 11
6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 13 6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 13
6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 14 6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 13
6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 14 6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 14
6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 15 6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 14
6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 15 6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 14
6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 16 6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 15
6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 16 6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 16
7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9.1. Assuring that the proper LIS has been contacted . . . . . 23 9.1. Assuring That the Proper LIS Has Been Contacted . . . . . 23
9.2. Protecting responses from modification . . . . . . . . . . 24 9.2. Protecting Responses from Modification . . . . . . . . . . 23
9.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 24 9.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 23
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. HTTPS Example Messages . . . . . . . . . . . . . . . . . . 25 10.1. Examples of HTTPS Messages . . . . . . . . . . . . . . . . 25
10.2. Simple Location Request Example . . . . . . . . . . . . . 27 10.2. Example of a Simple Location Request . . . . . . . . . . . 26
10.3. Location Request Example for Multiple Location Types . . . 28 10.3. An Example of a Location Request for Multiple Location
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 Types . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
11.1. URN Sub-Namespace Registration for 11.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 29 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 28
11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 30 11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 29
11.3. MIME Media Type Registration for 'application/held+xml' . 30 11.3. MIME Media Type Registration for 'application/held+xml' . 29
11.4. Error code Registry . . . . . . . . . . . . . . . . . . . 31 11.4. Error Code Registry . . . . . . . . . . . . . . . . . . . 30
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
14. Changes since last Version . . . . . . . . . . . . . . . . . . 33 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 14.1. Normative References . . . . . . . . . . . . . . . . . . . 33
15.1. Normative References . . . . . . . . . . . . . . . . . . . 41 14.2. Informative References . . . . . . . . . . . . . . . . . . 34
15.2. Informative References . . . . . . . . . . . . . . . . . . 41
Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 43 Appendix A. HELD Compliance to IETF LCP Requirements . . . . . . 36
A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 43 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 36
A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 43 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 36
A.3. L7-3: ASP and Access Network Provider Relationship . . . . 44 A.3. L7-3: ASP and Access Network Provider Relationship . . . . 37
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 44 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 37
A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 44 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 37
A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 45 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 38
A.7. L7-7: Network Access Authentication . . . . . . . . . . . 45 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 38
A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 45 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 38
A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 46 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 39
A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 46 A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
1. Introduction 1. Introduction
The location of a Device is information that is useful for a number The location of a Device is information that is useful for a number
of applications. The L7 Location Configuration Protocol (LCP) of applications. The L7 Location Configuration Protocol (LCP)
problem statement and requirements document problem statement and requirements document [RFC5687] provides some
[I-D.ietf-geopriv-l7-lcp-ps] provides some scenarios in which a scenarios in which a Device might rely on its access network to
Device might rely on its access network to provide location provide location information. The Location Information Server (LIS)
information. The Location Information Server (LIS) service applies service applies to access networks employing both wired technology
to access networks employing both wired technology (e.g. DSL, Cable) (e.g., DSL, cable) and wireless technology (e.g., WiMAX) with varying
and wireless technology (e.g. WiMAX) with varying degrees of Device degrees of Device mobility. This document describes a protocol that
mobility. This document describes a protocol that can be used to can be used to acquire Location Information (LI) from a LIS within an
acquire Location Information (LI) from a LIS within an access access network.
network.
This specification identifies two types of location information that This specification identifies two types of location information that
may be retrieved from the LIS. Location may be retrieved from the may be retrieved from the LIS. Location may be retrieved from the
LIS by value, that is, the Device may acquire a literal location LIS by value; that is, the Device may acquire a literal location
object describing the location of the Device. The Device may also object describing the location of the Device. The Device may also
request that the LIS provide a location reference in the form of a request that the LIS provide a location reference in the form of a
location URI or set of location URIs, allowing the Device to Location URI or set of Location URIs, allowing the Device to
distribute its LI by reference. Both of these methods can be distribute its LI by reference. Both of these methods can be
provided concurrently from the same LIS to accommodate application provided concurrently from the same LIS to accommodate application
requirements for different types of location information. requirements for different types of location information.
This specification defines an extensible XML-based protocol that This specification defines an extensible XML-based protocol that
enables the retrieval of LI from a LIS by a Device. This protocol enables the retrieval of LI from a LIS by a Device. This protocol
can be bound to any session-layer protocol, particularly those can be bound to any session-layer protocol, particularly those
capable of MIME transport. This document describes the use of capable of MIME transport. This document describes the use of HTTP
HyperText Transfer Protocol (HTTP) and HTTP over Transport Layer and HTTP/TLS as transports for the protocol.
Security (HTTP/TLS) as transports for the protocol.
2. Conventions & Terminology 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses the terms (and their acronym forms) Access This document uses the terms (and their acronym forms): Access
Provider (AP), Location Information (LI), Location Object (LO), Provider (AP), Location Information (LI), Location Object (LO),
Device, Target, Location Generator (LG), Location Recipient (LR), Device, Target, Location Generator (LG), Location Recipient (LR), and
Rule Maker (RM) and Rule Holder (RH) as defined in RFC 3693, GEOPRIV Rule Maker (RM) and Rule Holder (RH) as defined in GEOPRIV
Requirements [RFC3693] . The terms Location Information Server Requirements [RFC3693]. The terms Location Information Server (LIS),
(LIS), Access Network, Access Provider (AP) and Access Network Access Network, Access Provider (AP), and Access Network Provider are
Provider are used in the same context as defined in the L7 LCP used in the same context as defined in the L7 LCP Problem statement
Problem statement and Requirements document and Requirements document [RFC5687]. The usage of the terms Civic
[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
This document describes an interface between a Device and a Location This document describes an interface between a Device and a Location
Information Server (LIS). This document assumes that the LIS is Information Server (LIS). This document assumes that the LIS is
present within the same administrative domain as the Device (e.g., present within the same administrative domain as the Device (e.g.,
the access network). The LIS exists because not all Devices are the access network). The LIS exists because not all Devices are
capable of determining LI, and because, even if a device is able to capable of determining LI, and because, even if a Device is able to
determine its own LI, it may be more efficient with assistance. This determine its own LI, it may be more efficient with assistance. This
document does not specify how LI is determined. An Access Provider document does not specify how LI is determined. An Access Provider
(AP) operates the LIS so that Devices (and Targets) can retrieve (AP) operates the LIS so that Devices (and Targets) can retrieve
their LI. This document assumes that the Device and Access Provider their LI. This document assumes that the Device and Access Provider
have no prior relationship other than what is necessary for the have no prior relationship other than what is necessary for the
Device to obtain network access. Device to obtain network access.
This document is based on the attribution of the LI to a Device and This document is based on the attribution of the LI to a Device and
not specifically a person (end user) or Target, based on the premise not specifically a person (end user) or Target, based on the premise
that location determination technologies are generally designed to that location determination technologies are generally designed to
locate a device and not a person. It is expected that, for most locate a Device and not a person. It is expected that, for most
applications, LI for the device can be used as an adequate substitute applications, LI for the Device can be used as an adequate substitute
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 [RFC3693] and the LIS defined in functional elements identified in [RFC3693] and the LIS defined in
[I-D.ietf-geopriv-l7-lcp-ps] and where this protocol applies, with [RFC5687]. It also shows where this protocol applies, with the Rule
the Rule Maker and Target represented by the role of the Device. Maker and Target represented by the role of the Device. Note that
Note that only the interfaces relevant to the Device are identified only the interfaces relevant to the Device are identified in the
in the diagram. diagram.
+---------------------------------------------+ +---------------------------------------------+
| Access Network Provider | | Access Network Provider |
| | | |
| +--------------------------------------+ | | +--------------------------------------+ |
| | Location Information Server | | | | Location Information Server | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| +------|-------------------------------+ | | +------|-------------------------------+ |
+----------|----------------------------------+ +----------|----------------------------------+
| |
| |
HELD 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 be found in the SIP Location Conveyance document [LOC-CONVEY].
[I-D.ietf-sipcore-location-conveyance].
4. Protocol Overview 4. Protocol Overview
A device uses the HELD protocol to retrieve its location either A Device uses the HTTP-Enabled Location Delivery (HELD) protocol to
directly in the form of a Presence Information Data Format Location retrieve its location either directly in the form of a Presence
Object (PIDF-LO) document (by value) and indirectly as a Location URI Information Data Format Location Object (PIDF-LO) document (by value)
(by reference). The security necessary to ensure the accuracy, or indirectly as a Location URI (by reference). The security
privacy and confidentiality of the device's location is described in necessary to ensure the accuracy, privacy, and confidentiality of the
the Security Considerations (Section 9). Device's location is described in the Security Considerations
(Section 9).
As described in the L7 LCP problem statement and requirements As described in the L7 LCP problem statement and requirements
[I-D.ietf-geopriv-l7-lcp-ps], the Device MUST first discover the URI document [RFC5687], the Device MUST first discover the URI for the
for the LIS for sending the HELD protocol requests. The URI for the LIS for sending the HELD protocol requests. The URI for the LIS
LIS SHOULD be obtained from an authorized and authenticated entity. SHOULD be obtained from an authorized and authenticated entity. The
The details for ensuring that an appropriate LIS is contacted are details for ensuring that an appropriate LIS is contacted are
provided in Section 9 and in particular Section 9.1. The LIS provided in Section 9 and in particular Section 9.1. The LIS
discovery protocol details are out of scope of this document and are discovery protocol details are out of scope of this document and are
specified in [I-D.ietf-geopriv-lis-discovery]. The type of URI specified in [RFC5986]. The type of URI provided by LIS discovery is
provided by LIS discovery is RECOMMENDED to be an https: URI. RECOMMENDED to be an HTTPS URI.
The LIS requires an identifier for the Device in order to determine The LIS requires an identifier for the Device in order to determine
the appropriate location to include in the location response message. the appropriate location to include in the location response message.
In this document, the IP address of the Device, as reflected by the In this document, the IP address of the Device, as reflected by the
source IP address in the location request message, is used as the source IP address in the location request message, is used as the
identifier. Other identifiers are possible, but are beyond the scope identifier. Other identifiers are possible, but are beyond the scope
of this document. of this document.
4.1. Device Identifiers, NAT and VPNs 4.1. Device Identifiers, NAT and VPNs
Use of the HELD protocol is subject to the viability of the Use of the HELD protocol is subject to the viability of the
identifier used by the LIS to determine location. This document identifier used by the LIS to determine location. This document
describes the use of the source IP address sent from the Device as describes the use of the source IP address sent from the Device as
the identifier used by the LIS. When Network Address Translation the identifier used by the LIS. When Network Address Translation
(NAT), a Virtual Private Network (VPN) or other forms of address (NAT), a Virtual Private Network (VPN), or other forms of address
modification occur between the Device and the LIS the location modification occur between the Device and the LIS, the location
returned could be inaccurate. returned could be inaccurate.
Not all cases of NATs introduce inaccuracies in the returned Not all cases of NATs introduce inaccuracies in the returned
location. For example, a NAT used in a residential Local Area location. For example, a NAT used in a residential Local Area
Network (LAN) is typically not a problem. The external IP address Network (LAN) is typically not a problem. The external IP address
used on the Wide Area Network (WAN) side of the NAT is an acceptable used on the Wide Area Network (WAN) side of the NAT is an acceptable
identifier for all of the devices in the residence, on the LAN side identifier for all of the Devices in the residence (on the LAN side
of the NAT, since the covered geographical area is small. of the NAT), since the covered geographical area is small.
On the other hand, if there is a VPN between the Device and the LIS, On the other hand, if there is a VPN between the Device and the LIS
for example for a teleworker, then the IP address seen by a LIS (for example, for a teleworker), then the IP address seen by a LIS
inside the enterprise network might not be the right address to inside the enterprise network might not be the right address to
identify the location of the Device. Section 4.1.2 provides identify the location of the Device. Section 4.1.2 provides
recommendations to address this issue. recommendations to address this issue.
4.1.1. Devices and VPNs 4.1.1. Devices and VPNs
To minimize the impact of connections or tunnels setup for security To minimize the impact of connections or tunnels setup for security
purposes or to traverse middleboxes, Devices that connect to servers purposes or for traversing middleboxes, Devices that connect to
such as VPN servers, SOCKS servers and HTTP proxy servers should servers such as VPN servers, SOCKS servers, and HTTP proxy servers
perform their HELD query to the LIS prior to establishing a should perform their HELD query on the LIS prior to establishing a
connection to other servers. It is RECOMMENDED that discovery connection to other servers. It is RECOMMENDED that discovery
[I-D.ietf-geopriv-lis-discovery] and an initial query are performed [RFC5986] and an initial query be performed before establishing any
before establishing any connections to other servers. If a Device connections to other servers. If a Device performs the HELD query
performs the HELD query after establishing a connection to another after establishing a connection to another server, the Device may
server, the Device may receive inaccurate location information. 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. In this case, a VPN device should provide the presence of the VPN. In this case, a VPN Device should provide the
address of the LIS server it provides, in response to discovery address of the LIS server it provides, in response to discovery
queries, rather than passing such queries through the VPN tunnel. queries, rather than passing such queries through the VPN tunnel.
Otherwise, the other devices would be totally unaware that they could Otherwise, the other Devices would be totally unaware that they could
receive inaccurate location information. receive inaccurate location information.
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)[RFC3825] or Link Layer Discovery Protocol - Media Protocol (DHCP) [RFC3825] or Link Layer Discovery Protocol - Media
Endpoint Discovery (LLDP-MED) [LLDP-MED]. For this case, the VPN Endpoint Discovery [LLDP-MED]. For this case, the VPN Device that
device that serves as a LIS may first acquire its own location using serves as a LIS may first acquire its own location using HELD.
HELD.
4.1.2. LIS Handling of NATs and VPNs 4.1.2. LIS Handling of NATs and VPNs
In the cases where the Device connects to the LIS through a VPN or a In the cases where the Device connects to the LIS through a VPN or a
NAT that serves a large geographic area or multiple geographic NAT that serves a large geographic area or multiple geographic
locations (for example, a NAT used by an enterprise to connect their locations (for example, a NAT used by an enterprise to connect their
private network to the Internet), the LIS might not be able to return private network to the Internet), the LIS might not be able to return
an accurate LI. If the LIS cannot determine LI for the device, it accurate LI. If the LIS cannot determine LI for the Device, it
should provide an error response to the requesting device. The LIS should provide an error response to the requesting Device. The LIS
needs to be configured to recognize identifiers that represent these needs to be configured to recognize identifiers that represent these
conditions. conditions.
LIS operators have a large role in ensuring the best possible LIS operators have a large role in ensuring the best possible
environment for location determination. The LIS operator needs to environment for location determination. The LIS operator needs to
ensure that the LIS is properly configured with identifiers that ensure that the LIS is properly configured with identifiers that
indicate Devices on the remote side of a NAT or VPN. In order to indicate Devices on the remote side of a NAT or VPN. In order to
serve the Devices on the remote side of a NAT or VPN, a LIS needs to serve the Devices on the remote side of a NAT or VPN, a LIS needs to
have a presence on the the side of the NAT or VPN nearest the Device. have a presence on the side of the NAT or VPN nearest the Device.
4.2. Location by Value 4.2. 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 [RFC5491]. Further detail is included in the detailed document [RFC5491]. Further detail is included in "Protocol
protocol section of this document Section 6 Parameters" (Section 6).
4.3. Location by Reference 4.3. 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 [RFC3986] of any scheme, literal location. A Location URI is a URI [RFC3986] of any scheme,
which a Location Recipient (LR) can use to retrieve LI. A location which a Location Recipient (LR) can use to retrieve LI. A Location
URI provided by a LIS can be assumed to be globally-addressable; that URI provided by a LIS can be assumed to be globally addressable; that
is, anyone in possession of the URI can access the LIS. is, anyone in possession of the URI can access the LIS.
However, possession of the URI does not in any way suggest that the However, possession of the URI does not in any way suggest that the
LIS indiscriminately reveals the location associated with the LIS indiscriminately reveals the location associated with the
location URI. The specific requirements associated with the Location URI. The specific requirements associated with the
dereference of the location are specified in dereference of the location are specified in [RFC5808]. The location
[I-D.ietf-geopriv-lbyr-requirements]. The location dereference dereference protocol details are out of scope of this document. As
protocol details are out of scope of this document. As such, many of such, many of the requirements in [RFC5808] (e.g., canceling of
the requirements in [I-D.ietf-geopriv-lbyr-requirements] (e.g., location references) are not intended to be supported by this
cancelling of location references) are not intended to be supported specification. It is anticipated that future specifications may
by this specification. It is anticipated that future specifications address these requirements.
may address these requirements.
5. Protocol Description 5. Protocol Description
As discussed in Section 4 the HELD protocol provides for the As discussed in Section 4, the HELD protocol provides for the
retrieval of the device's location in the form of a PIDF-LO document retrieval of the Device's location in the form of a PIDF-LO document
and/or Location URI(s) from a LIS. Three messages are defined to and/or Location URI(s) from a LIS. Three messages are defined to
support the location retrieval: locationRequest, locationResponse and support the location retrieval: locationRequest, locationResponse,
error. Messages are defined as XML documents. and error.
The Location Request (locationRequest) message is described in The Location Request (locationRequest) message is described in
Section 5.1. A Location Request message from a Device indicates Section 5.1. A Location Request message from a Device indicates
whether location in the form of a PIDF-LO document (with specific whether location should be returned in the form of a PIDF-LO document
type(s) of location) and/or Location URI(s) should be returned. The (with specific type(s) of location) and/or Location URI(s). In case
LIS replies with a locationResponse message, including a PIDF-LO of success, the LIS replies with a locationResponse message,
document and/or one or more Location URIs in case of success. In the including a PIDF-LO document and/or one or more Location URIs. In
case of an error, the LIS replies with an error message. the case of an error, the LIS replies with an error message.
A MIME type "application/held+xml" is registered in Section 11.3 to The HELD protocol messages are defined as XML documents that MUST be
distinguish HELD messages from other XML document bodies. This encoded in UTF-8. A MIME type "application/held+xml" is registered
specification follows the recommendations and conventions described in Section 11.3 to distinguish HELD messages from other XML document
in [RFC3023], including the naming convention of the type ('+xml' bodies. This specification follows the recommendations and
suffix) and the usage of the 'charset' parameter. conventions described in [RFC3023], including the naming convention
of the type ('+xml' suffix) and the usage of the 'charset' parameter.
The 'charset' parameter MUST be included with the XML document.
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 [W3C.REC-xmlschema-1-20041028]. messages in the form of an XML Schema [W3C.REC-xmlschema-1-20041028].
This document describes the use of a combination of HTTP [RFC2616], Section 8 describes the use of a combination of HTTP [RFC2616], TLS
TLS [RFC5246] and TCP [RFC0793] in Section 8. [RFC5246], and TCP [RFC0793] for transporting the HELD messages.
5.1. Location Request 5.1. Location Request
A location request message is sent from the Device to the LIS when A location request message is sent from the Device to the LIS when
the Device requires its own LI. The type of LI that a Device the Device requires its own LI. The type of LI that a Device
requests is determined by the type of LI that is included in the requests is determined by the type of LI that is included in the
"locationType" element. "locationType" element.
The location request is made by sending a document formed of a The location request is made by sending a document formed of a
"locationRequest" element. The LIS uses the source IP address of the "locationRequest" element. The LIS uses the source IP address of the
location request message as the primary source of identity for the location request message as the primary source of identity for the
requesting device or target. It is anticipated that other Device requesting Device or target. It is anticipated that other Device
identities may be provided through schema extensions. identities may be provided through schema extensions.
The LIS MUST ignore any part of a location request message that it The LIS MUST ignore any part of a location request message that it
does not understand, except the document element. If the document does not understand, except the document element. If the document
element of a request is not supported, the LIS MUST return an error element of a request is not supported, the LIS MUST return an error
with the unsupportedMessage error code. with the unsupportedMessage error code.
5.2. Location Response 5.2. Location Response
A successful response to a location request MUST contain a PIDF-LO A successful response to a location request MUST contain a PIDF-LO
and/or location URI(s). The response SHOULD contain location and/or Location URI(s). The response SHOULD contain location
information of the requested "locationType". The cases whereby a information of the requested "locationType". The cases whereby a
different type of location information MAY be returned are described different type of location information MAY be returned are described
in Section 6.2. in Section 6.2.
5.3. Indicating Errors 5.3. 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
type of error. A set of predefined error codes are included in type of error. A set of predefined error codes are included in
Section 6.3. Section 6.3.
Error responses MAY also include a "message" attribute that can Error responses MAY also include a "message" attribute that can
include additional information. This information SHOULD be for include additional information. This information SHOULD be for
diagnostic purposes only, and MAY be in any language. The language diagnostic purposes only and MAY be in any language. The language of
of the message SHOULD be indicated with an "xml:lang" attribute. 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 (m) or optional (o) for
messages. each of the messages.
+----------------+----------------+----------------+----------------+ +----------------+-----------+------------+------------+------------+
| Parameter | Location | Location | Error | | Parameter | Section | Location | Location | Error |
| | Request | Response | | | | | Request | Response | |
+----------------+----------------+----------------+----------------+ +----------------+-----------+------------+------------+------------+
| responseTime | o | | | | responseTime | 6.1 | o | | |
| (Section 6.1) | | | | | | | | | |
| locationType | o | | | | locationType | 6.2 | o | | |
| (Section 6.2) | | | | | | | | | |
| code | | | m | | code | 6.3 | | | m |
| (Section 6.3) | | | | | | | | | |
| message | | | o | | message | 6.4 | | | o |
| (Section 6.4) | | | | | | | | | |
| locationUriSet | | o | | | locationUriSet | 6.5 | | o | |
| (Section 6.5) | | | | | | | | | |
| Presence | | o | | | Presence | 6.6 | | o | |
| (PIDF-LO) | | | | | (PIDF-LO) | | | | |
| (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 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 Public Safety could be either for routing a call to the appropriate Public Safety
Answering Point (PSAP) or indicating the location to which responders Answering Point (PSAP) or indicating the location to which responders
should be dispatched. The values defined for the purpose, should be dispatched. The values defined for the purpose,
"emergencyRouting" and "emergencyDispatch", will likely be governed "emergencyRouting" and "emergencyDispatch", will likely be governed
by jurisdictional policies, and should be configurable on the LIS. by jurisdictional 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
to the time limit implied; any enforcement of the time limit is left adhere to the time limit implied; any enforcement of the time limit
to the requesting Device. The LIS provides the most accurate LI that is left to the requesting Device. The LIS provides the most accurate
can be determined within the specified interval for the specific LI that can be determined within the specified interval for the
service. specific service.
The LIS may use the value of the time in the "responseTime" attribute The LIS may use the value of the time in the "responseTime" attribute
as input when selecting the method of location determination, where as input when selecting the method of location determination, where
multiple such methods exist. If the "responseTime" attribute is multiple such methods exist. If the "responseTime" attribute is
absent, then the LIS should return the most precise LI it is capable absent, then the LIS should return the most precise LI it is capable
of determining, with the time interval being implementation of determining, with the time interval being implementation
dependent. dependent.
6.2. "locationType" Parameter 6.2. "locationType" Parameter
skipping to change at page 12, line 21 skipping to change at page 11, line 20
dependent. dependent.
6.2. "locationType" Parameter 6.2. "locationType" Parameter
The "locationType" element MAY be included in a location request The "locationType" element MAY be included in a location request
message. It contains a list of LI types that are requested by the message. It contains a list of LI types that are requested by the
Device. The following list describes the possible values: Device. The following list describes the possible values:
any: The LIS SHOULD attempt to provide LI in all forms available to any: The LIS SHOULD attempt to provide LI in all forms available to
it. it.
geodetic: The LIS SHOULD return a location by value in the form of a geodetic: The LIS SHOULD return a location by value in the form of a
geodetic location for the Target. geodetic location for the Target.
civic: The LIS SHOULD return a location by value in the form of a civic: The LIS SHOULD return a location by value in the form of a
civic address for the Target. civic address for the Target.
locationURI: The LIS SHOULD return a set of location URIs for the
locationURI: The LIS SHOULD return a set of Location URIs for the
Target. Target.
The LIS SHOULD return the requested location type or types. The The LIS SHOULD return the requested location type or types. The
location types the LIS returns also depend on the setting of the location types the LIS returns also depend on the setting of the
optional "exact" attribute. If the "exact" attribute is set to optional "exact" attribute. If the "exact" attribute is set to
"true" then the LIS MUST return either the requested location type or "true", then the LIS MUST return either the requested location type
provide an error response. The "exact" attribute does not apply (is or provide an error response. The "exact" attribute does not apply
ignored) for a request for a location type of "any". Further detail (is ignored) for a request for a location type of "any". Further
of the "exact" attribute processing is provided in the following detail of the "exact" attribute processing is provided in the
Section 6.2.1. following Section 6.2.1.
In the case of a request for specific locationType(s) and the "exact" When there is a request for specific locationType(s) and the "exact"
attribute is false, the LIS MAY provide additional location types, or attribute is "false", the LIS MAY provide additional location types,
it MAY provide alternative types if the request cannot be satisfied or it MAY provide alternative types if the request cannot be
for a requested location type. The "SHOULD"-strength requirements on satisfied for a requested location type. The "SHOULD"-strength
this parameter for specific location types are included to allow for requirements on this parameter for specific location types are
soft-failover. This enables a fixed client configuration that included to allow for soft-failover. This enables a fixed client
prefers a specific location type without causing location requests to configuration that prefers a specific location type without causing
fail when that location type is unavailable. For example, a notebook location requests to fail when that location type is unavailable.
computer could be configured to retrieve civic addresses, which is For example, a notebook computer could be configured to retrieve
usually available from typical home or work situations. However, civic addresses, which is usually available from typical home or work
when using a wireless modem, the LIS might be unable to provide a situations. However, when using a wireless modem, the LIS might be
civic address and thus provides a geodetic address. unable to provide a civic address and thus provides a geodetic
address.
The LIS SHOULD return location information in a form that is suited The LIS SHOULD return location information in a form that is suited
for routing and responding to an emergency call in its jurisdiction, for routing and responding to an emergency call in its jurisdiction,
specifically by value. The LIS MAY alternatively or additionally specifically by value. The LIS MAY alternatively or additionally
return a location URI. If the "locationType" element is absent, a return a Location URI. If the "locationType" element is absent, a
value of "any" MUST be assumed as the default. A location URI value of "any" MUST be assumed as the default. A Location URI
provided by the LIS is a reference to the most current available LI provided by the LIS is a reference to the most current available LI
and is not a stable reference to a specific location. and is not a stable reference to a specific location.
It should be noted that the protocol does not support a request to It should be noted that the protocol does not support a request to
just receive one of a subset of location types. For example, in the just receive one of a subset of location types. For example, in the
case where a Device has a preference for just "geodetic" or "civic", case where a Device has a preference for just "geodetic" or "civic",
it is necessary to make the request without an "exact" attribute, it is necessary to make the request without an "exact" attribute,
including both location types. In this case, if neither is available including both location types. In this case, if neither is
a LIS SHOULD return a locationURI if available. available, a LIS SHOULD return a locationURI if available.
The LIS SHOULD provide the locations in the response in the same The LIS SHOULD provide the locations in the response in the same
order in which they were included in the "locationType" element in order in which they were included in the "locationType" element in
the request. Indeed, the primary advantage of including specific the request. Indeed, the primary advantage of including specific
location types in a request when the "exact" attribute is set to location types in a request when the "exact" attribute is set to
"false" is to ensure that one receives the available locations in a "false" is to ensure that one receives the available locations in a
specific order. For example, a locationRequest for "civic" could specific order. For example, a locationRequest for "civic" could
yield any of the following location types in the response: yield any of the following location types in the response:
o civic o civic
skipping to change at page 13, line 46 skipping to change at page 13, line 12
only possible response is either a "civic" location or an error only possible response is either a "civic" location or an error
message. message.
6.2.1. "exact" Attribute 6.2.1. "exact" Attribute
The "exact" attribute MAY be included in a location request message The "exact" attribute MAY be included in a location request message
when the "locationType" element is included. When the "exact" when the "locationType" element is included. When the "exact"
attribute is set to "true", it indicates to the LIS that the contents attribute is set to "true", it indicates to the LIS that the contents
of the "locationType" parameter MUST be strictly followed. The of the "locationType" parameter MUST be strictly followed. The
default value of "false" allows the LIS the option of returning default value of "false" allows the LIS the option of returning
something beyond what is specified, such as a set of location URIs something beyond what is specified, such as a set of Location URIs
when only a civic location was requested. when only a civic location was requested.
A value of "true" indicates that the LIS MUST provide a location of A value of "true" indicates that the LIS MUST provide a location of
the requested type or types or MUST provide an error. The LIS MUST the requested type or types or MUST provide an error. The LIS MUST
provide the requested types only. The LIS MUST handle an exact provide the requested types only. The LIS MUST handle an exact
request that includes a "locationType" element set to "any" as if the request that includes a "locationType" element set to "any" as if the
"exact" attribute were set to "false". "exact" attribute were set to "false".
6.3. "code" Parameter 6.3. "code" Parameter
All "error" responses MUST contain a response code. All errors are All "error" responses MUST contain a response code. All errors are
application-level errors, and MUST only be provided in successfully application-level errors and MUST only be provided in successfully
processed transport-level responses. For example where HTTP/HTTPS is processed transport-level responses. For example, where HTTP/HTTPS
used as the transport, HELD error messages MUST be carried by a 200 is used as the transport, HELD error messages MUST be carried by a
OK HTTP/HTTPS response. 200 OK HTTP/HTTPS response.
The value of the response code MUST be an IANA-registered value. The The value of the response code MUST be an IANA-registered value. The
following tokens are registered by this document: following tokens are registered by this document:
requestError: This code indicates that the request was badly formed requestError: This code indicates that the request was badly formed
in some fashion (other than the XML content). in some fashion (other than the XML content).
xmlError: This code indicates that the XML content of the request xmlError: This code indicates that the XML content of the request
was either badly formed or invalid. was either badly formed or invalid.
generalLisError: This code indicates that an unspecified error generalLisError: This code indicates that an unspecified error
occurred at the LIS. occurred at the LIS.
locationUnknown: This code indicates that the LIS could not locationUnknown: This code indicates that the LIS could not
determine the location of the Device. The same request can be determine the location of the Device. The same request can be
sent by the Device at a later time. Devices MUST limit any sent by the Device at a later time. Devices MUST limit any
attempts to retry requests. attempts to retry requests.
unsupportedMessage: This code indicates that an element in the XML unsupportedMessage: This code indicates that an element in the XML
document for the request, was not supported or understood by the document for the request was not supported or understood by the
LIS. This error code is used when a HELD request contains a LIS. This error code is used when a HELD request contains a
document element that is not supported by the receiver. document element that is not supported by the receiver.
timeout: This code indicates that the LIS could not satisfy the timeout: This code indicates that the LIS could not satisfy the
request within the time specified in the "responseTime" parameter. request within the time specified in the "responseTime" parameter.
cannotProvideLiType: This code indicates that the LIS was unable to cannotProvideLiType: This code indicates that the LIS was unable to
provide LI of the type or types requested. This code is used when provide LI of the type or types requested. This code is used when
the "exact" attribute on the "locationType" parameter is set to the "exact" attribute on the "locationType" parameter is set to
"true". "true".
notLocatable: This code indicates that the LIS is unable to locate notLocatable: This code indicates that the LIS is unable to locate
the Device, and that the Device MUST NOT make further attempts to the Device and that the Device MUST NOT make further attempts to
retrieve LI from this LIS. This error code is used to indicate retrieve LI from this LIS. This error code is used to indicate
that the Device is outside the access network served by the LIS; that the Device is outside the access network served by the LIS,
for instance, the VPN and NAT scenarios discussed in for instance, the VPN and NAT scenarios discussed in
Section 4.1.2. Section 4.1.2.
6.4. "message" Parameter 6.4. "message" Parameter
The "error" message MAY include one or more "message" attributes to The "error" message MAY include one or more "message" attributes to
convey some additional, human-readable information about the result convey some additional, human-readable information about the result
of the request. The message MAY be included in any language, which of the request. The message MAY be included in any language, which
SHOULD be indicated by the "xml:lang", attribute. The default SHOULD be indicated by the "xml:lang", attribute. The default
language is assumed to be English ("en") [I-D.ietf-ltru-4646bis]. language is assumed to be English ("en") [RFC5646].
6.5. "locationUriSet" Parameter 6.5. "locationUriSet" Parameter
The "locationUriSet" element, received in a "locationResponse" The "locationUriSet" element received in a "locationResponse" message
message MAY contain any number of "locationURI" elements. It is MAY contain any number of "locationURI" elements. It is RECOMMENDED
RECOMMENDED that the LIS allocate a Location URI for each scheme that that the LIS allocate a Location URI for each scheme that it supports
it supports and that each scheme is present only once. URI schemes and that each scheme is present only once. URI schemes and their
and their secure variants, such as http and https, MUST be regarded secure variants, such as HTTP and HTTPS, MUST be regarded as two
as two separate schemes. 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. In order The "locationURI" element includes a single Location URI. In order
for a URI of any particular scheme to be included in a response, for a URI of any particular scheme to be included in a response,
there MUST be a specification that defines how that URI can be used there MUST be a specification that defines how that URI can be used
to retrieve location information. The details of the protocol for to retrieve location information. The details of the protocol for
dereferencing must meet the location dereference protocol dereferencing must meet the location dereference protocol
requirements as specified in [I-D.ietf-geopriv-lbyr-requirements] and requirements as specified in [RFC5808] and are outside the scope of
are outside the scope of this base HELD specification. this base HELD specification.
Each Location URI that is allocated by the LIS is unique to the Each Location URI that is allocated by the LIS is unique to the
device that is requesting it. At the time the location URI is Device that is requesting it. At the time the Location URI is
provided in the response, there is no binding to a specific location provided in the response, there is no binding to a specific location
type and the location URI is totally independent of the specific type type and the Location URI is totally independent of the specific type
of location it might reference. The specific location type is of location it might reference. The specific location type is
determined at the time of dereference. determined at the time of dereference.
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. pseudonym.
When a LIS returns a "locationURI" element to a Device, the policy on When a LIS returns a "locationURI" element to a Device, the policy on
the "locationURI" is set by the LIS alone. This specification does the "locationURI" is set by the LIS alone. This specification does
not include a mechanism for the HELD client to set access control not include a mechanism for the HELD client to set access control
policies on a "locationURI". Conversely, there is no mechanism, in policies on a "locationURI". Conversely, there is no mechanism, in
this protocol as defined in this document, for the LIS to provide a this protocol as defined in this document, for the LIS to provide a
Device the access control policy to be applied to a "locationURI". Device the access control policy to be applied to a "locationURI".
Since the Device is not aware of the access controls to be applied to Since the Device is not aware of the access controls to be applied to
(subsequent) requests to dereference a "locationURI", the client (subsequent) requests to dereference a "locationURI", the client
SHOULD protect a "locationURI" as if it were a Location Object - SHOULD protect a "locationURI" as if it were a Location Object --
i.e., the Device SHOULD send a "locationURI" over encrypted channels, i.e., the Device SHOULD send a "locationURI" over encrypted channels
and only to entities that are authorized to have access to the and only to entities that are authorized to have access to the
location. location.
Further guidelines to ensure the privacy and confidentiality of the Further guidelines to ensure the privacy and confidentiality of the
information contained in the "locationResponse" message, including information contained in the "locationResponse" message, including
the "locationURI", are included in Section 9.3. the "locationURI", are included in Section 9.3.
6.5.2. "expires" Parameter 6.5.2. "expires" Parameter
The "expires" attribute is only included in a "locationResponse" The "expires" attribute is only included in a "locationResponse"
message when a "locationUriSet" element is included. The "expires" message when a "locationUriSet" element is included. The "expires"
attribute indicates the date/time at which the Location URIs provided attribute indicates the date/time at which the Location URIs provided
by the LIS will expire. The "expires" attribute does not define the by the LIS will expire. The "expires" attribute does not define the
length of time a location received by dereferencing the location URI length of time a location received by dereferencing the Location URI
will be valid. The "expires" attribute is RECOMMENDED not to exceed will be valid. The "expires" attribute is RECOMMENDED not to exceed
24 hours and SHOULD be a minimum of 30 minutes. 24 hours and SHOULD be a minimum of 30 minutes.
All date-time values used in HELD MUST be expressed in Universal All date-time values used in HELD MUST be expressed in Universal
Coordinated Time (UTC) using the Gregorian calendar. XML Schema Coordinated Time (UTC) using the Gregorian calendar. The XML schema
allows use of time zone identifiers to indicate offsets from the zero allows use of time zone identifiers to indicate offsets from the zero
meridian, but this option MUST NOT be used with HELD. The extended meridian, but this option MUST NOT be used with HELD. The extended
date-time form using upper case "T" and "Z" characters defined in date-time form using upper case "T" and "Z" characters defined in
[W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time
values. values.
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 single "presence" parameter MAY be included in the A single "presence" parameter MAY be included in the
"locationResponse" message when specific locationTypes (e.g., "locationResponse" message when specific locationTypes (e.g.,
"geodetic" or "civic") are requested or a "locationType" of "any" is "geodetic" or "civic") are requested or a "locationType" of "any" is
requested. The LIS MUST follow the subset of the rules relating to requested. The LIS MUST follow the subset of the rules relating to
the construction of the "location-info" element in the PIDF-LO Usage the construction of the "location-info" element in the PIDF-LO Usage
Clarification, Considerations and Recommendations document [RFC5491] Clarification, Considerations, and Recommendations document [RFC5491]
in generating the PIDF-LO for the presence parameter. in generating the PIDF-LO for the presence parameter.
The LIS MUST NOT include any means of identifying the Device in the The LIS MUST NOT include any means of identifying the Device in the
PIDF-LO unless it is able to verify that the identifier is correct PIDF-LO unless it is able to verify that the identifier is correct
and inclusion of identity is expressly permitted by a Rule Maker. and inclusion of identity is expressly permitted by a Rule Maker.
Therefore, PIDF parameters that contain identity are either omitted Therefore, PIDF parameters that contain identity are either omitted
or contain unlinked pseudonyms [RFC3693]. A unique, unlinked or contain unlinked pseudonyms [RFC3693]. A unique, unlinked
presentity URI SHOULD be generated by the LIS for the mandatory presentity URI SHOULD be generated by the LIS for the mandatory
presence "entity" attribute of the PIDF document. Optional presence "entity" attribute of the PIDF document. Optional
parameters such as the "contact" element and the "deviceID" element parameters such as the "contact" and "deviceID" elements [RFC4479]
[RFC4479] are not used. are not used.
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 in Section 7 for a location response message, due to XML schema in Section 7 for a location response message, due to XML
schema constraints, since PIDF is already defined and registered schema constraints, since PIDF is already defined and registered
separately. Thus, the "##other" namespace serves as a placeholder separately. Thus, the "##other" namespace serves as a placeholder
for the presence parameter in the schema. for the presence parameter in the schema.
7. XML Schema 7. XML Schema
This section gives the XML Schema Definition This section gives the XML Schema Definition
[W3C.REC-xmlschema-1-20041028], [W3C.REC-xmlschema-2-20041028] of the [W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-2-20041028] of the
"application/held+xml" format. This is presented as a formal "application/held+xml" format. This is presented as a formal
definition of the "application/held+xml" format. Note that the XML definition of the "application/held+xml" format. Note that the XML
Schema definition is not intended to be used with on-the-fly Schema Definition is not intended to be used with on-the-fly
validation of the presence XML document. Whitespaces are included in validation of the presence XML document. Whitespaces are included in
the schema to conform to the line length restrictions of the RFC the schema to conform to the line length restrictions of the RFC
format without having a negative impact on the readability of the format without having a negative impact on the readability of the
document. Any conforming processor should remove leading and document. Any conforming processor should remove leading and
trailing white spaces. trailing white spaces.
<?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> <xs:documentation>
This document (RFC xxxx) defines HELD messages. This document (RFC 5985) defines HELD messages.
<!-- [[NOTE TO RFC-EDITOR: Please replace XXXX
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>
skipping to change at page 20, line 47 skipping to change at page 20, line 23
</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. HTTP Binding 8. HTTP Binding
This section describes the use of HTTP [RFC2616] and HTTP Over TLS This section describes the use of HTTP [RFC2616] and HTTP over TLS
[RFC2818] as transport mechanisms for the HELD protocol, which a [RFC2818] as transport mechanisms for the HELD protocol, which a
conforming LIS and Device MUST support. conforming LIS and Device MUST support.
Although HELD uses HTTP as a transport, it uses a strict subset of Although HELD uses HTTP as a transport, it uses a strict subset of
HTTP features, and due to the restrictions of some features, a LIS is HTTP features, and due to the restrictions of some features, a LIS is
not a fully compliant HTTP server. It is intended that a LIS can not a fully compliant HTTP server. It is intended that a LIS can
easily be built using an HTTP server with extensibility mechanisms, easily be built using an HTTP server with extensibility mechanisms
and that a HELD Device can trivially use existing HTTP libraries. and that a HELD Device can trivially use existing HTTP libraries.
This subset of requirements helps implementors avoid ambiguity with This subset of requirements helps implementors avoid ambiguity with
the many options the full HTTP protocol offers. the many options that the full HTTP protocol offers.
A Device that conforms to this specification MAY choose not to A Device that conforms to this specification MAY choose not to
support HTTP authentication [RFC2617] or cookies [RFC2965]. Because support HTTP authentication [RFC2617] or cookies [RFC2965]. Because
the Device and the LIS may not necessarily have a prior relationship, the Device and the LIS may not necessarily have a prior relationship,
the LIS SHOULD NOT require a Device to authenticate, either using the the LIS SHOULD NOT require a Device to authenticate, either using the
above HTTP authentication methods or TLS client authentication. above HTTP authentication methods or TLS client authentication.
Unless all Devices that access a LIS can be expected to be able to Unless all Devices that access a LIS can be expected to be able to
authenticate in a certain fashion, denying access to location authenticate in a certain fashion, denying access to location
information could prevent a Device from using location-dependent information could prevent a Device from using location-dependent
services, such as emergency calling. Extensions to this protocol services, such as emergency calling. Extensions to this protocol
might result in the addition of request parameters that a LIS might might result in the addition of request parameters that a LIS might
use to decide to request Device authentication. use to decide to request Device authentication.
A HELD request is carried in the body of an HTTP POST request. The A HELD request is carried in the body of an HTTP POST request. The
Device MUST include a Host header in the request. Device MUST include a Host header in the request.
The MIME type of HELD request and response bodies is The MIME type of HELD request and response bodies is
"application/held+xml". LIS and Device MUST provide this value in "application/held+xml". LIS and Device MUST provide this value in
the HTTP Content-Type and Accept header fields.If the LIS does not the HTTP Content-Type and Accept header fields. If the LIS does not
receive the appropriate Content-Type and Accept header fields, the receive the appropriate Content-Type and Accept header fields, the
LIS SHOULD fail the request, returning a 406 (not acceptable) LIS SHOULD fail the request, returning a 406 (not acceptable)
response. HELD responses SHOULD include a Content-Length header. response. HELD responses SHOULD include a Content-Length header.
Devices MUST NOT use the "Expect" header or the "Range" header in Devices MUST NOT use the "Expect" header or the "Range" header in
HELD requests. The LIS MAY return 501 (not implemented) errors if HELD requests. The LIS MAY return 501 (not implemented) errors if
either of these HTTP features are used. In the case that the LIS either of these HTTP features are used. In the case that the LIS
receives a request from the Device containing a If-* (conditional) receives a request from the Device containing an If-* (conditional)
header, the LIS SHOULD return a 412 (precondition failed) response. header, the LIS SHOULD return a 412 (precondition failed) response.
The POST method is the only method REQUIRED for HELD. If a LIS The POST method is the only method REQUIRED for HELD. If a LIS
chooses to support GET or HEAD, it SHOULD consider the kind of chooses to support GET or HEAD, it SHOULD consider the kind of
application doing the GET. Since a HELD Device only uses a POST application doing the GET. Since a HELD Device only uses a POST
method, the GET or HEAD MUST be either an escaped URL (e.g., somebody method, the GET or HEAD MUST be either an escaped URL (e.g., somebody
found a URL in protocol traces or log files and fed it into their found a URL in protocol traces or log files and fed it into their
browser) or somebody doing testing/ debugging. The LIS could provide browser) or somebody doing testing/debugging. The LIS could provide
information in the HELD response indicating that the URL corresponds information in the HELD response indicating that the URL corresponds
to a LIS server and only responds to HELD POST requests or the LIS to a LIS server and only responds to HELD POST requests, or the LIS
could instead try to avoid any leak of information by returning a could instead try to avoid any leak of information by returning a
very generic HTTP error message such as 404 (not found). very generic HTTP error message such as 404 (not found).
The LIS populates the HTTP headers of responses so that they are The LIS populates the HTTP headers of responses so that they are
consistent with the contents of the message. In particular, the consistent with the contents of the message. In particular, the
"CacheControl" header SHOULD be set to disable caching of any PIDF-LO "CacheControl" header SHOULD be set to disable caching of any PIDF-LO
document or Location URIs by HTTP intermediaries. Otherwise, there document or Location URIs by HTTP intermediaries. Otherwise, there
is the risk of stale locations and/or the unauthorized disclosure of is the risk of stale locations and/or the unauthorized disclosure of
the LI. This also allows the LIS to control any caching with the the LI. This also allows the LIS to control any caching with the
HELD "expires" parameter. The HTTP status code MUST indicate a 2xx HELD "expires" parameter. The HTTP status code MUST indicate a 2xx
series response for all HELD locationResponse and HELD error series response for all HELD locationResponse and HELD error
messages. messages.
The LIS MAY redirect a HELD request. A Device MUST handle redirects, The LIS MAY redirect a HELD request. A Device MUST handle redirects
by using the Location header provided by the server in a 3xx by using the Location header provided by the server in a 3xx
response. When redirecting, the Device MUST observe the delay response. When redirecting, the Device MUST observe the delay
indicated by the Retry-After header. The Device MUST authenticate indicated by the Retry-After header. The Device MUST authenticate
the server that returns the redirect response before following the the server that returns the redirect response before following the
redirect, if a Device requires that the server is authenticated. A redirect, if a Device requires that the server is authenticated. A
Device SHOULD authenticate the LIS indicated in a redirect. Device SHOULD authenticate the LIS indicated in a redirect.
The LIS SHOULD support persistent connections and request pipelining. The LIS SHOULD support persistent connections and request pipelining.
If pipelining is not supported, the LIS MUST NOT allow persistent If pipelining is not supported, the LIS MUST NOT allow persistent
connections. The Device MUST support termination of a response by connections. The Device MUST support termination of a response by
the closing of a connection. the closing of a connection.
Implementations of HELD that implement HTTP transport MUST implement Implementations of HELD that implement HTTP transport MUST implement
transport over TLS [RFC2818]. TLS provides message integrity and transport over TLS [RFC2818]. TLS provides message integrity and
confidentiality between Device and LIS. The Device MUST implement confidentiality between the Device and LIS. The Device MUST
the server authentication method described in Section 3.1 of implement the server authentication method described in Section 3.1
[RFC2818], with an exception in how wildcards are handled. The of [RFC2818], with an exception in how wildcards are handled. The
leftmost label MAY contain the wildcard string "*", which matches any leftmost label MAY contain the wildcard string "*", which matches any
single domain name label. Additional characters in this leftmost single domain name label. Additional characters in this leftmost
label are invalid (that is, "f*.example.com" is not a valid name and label are invalid (that is, "f*.example.com" is not a valid name and
does not match any domain name). does not match any domain name).
The device uses the URI obtained during LIS discovery to authenticate The Device uses the URI obtained during LIS discovery to authenticate
the server. The details of this authentication method are provided the server. The details of this authentication method are provided
in section 3.1 of HTTPS [RFC2818]. When TLS is used, the Device in Section 3.1 of HTTPS [RFC2818]. When TLS is used, the Device
SHOULD fail a request if server authentication fails, except in the SHOULD fail a request if server authentication fails, except in the
event of an emergency. event of an emergency.
9. Security Considerations 9. Security Considerations
HELD is a location acquisition protocol whereby the a client requests HELD is a location acquisition protocol whereby the client requests
its location from a LIS. Specific requirements and security its location from a LIS. Specific requirements and security
considerations for location acquisition protocols are provided in considerations for location acquisition protocols are provided in
[I-D.ietf-geopriv-l7-lcp-ps]. An in-depth discussion of the security [RFC5687]. An in-depth discussion of the security considerations
considerations applicable to the use of Location URIs and by applicable to the use of Location URIs and by-reference provision of
reference provision of LI is included in LI is included in [RFC5808].
[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: The client receives incorrect location information.
Privacy: An unauthorized entity receives location information
The provision of an accurate and privacy/confidentiality protected Privacy: An unauthorized entity receives location information.
location to the requestor depends on the success of five steps:
1. The client must determine the proper LIS. The provision of an accurate and privacy- and confidentiality-
2. The client must connect to the proper LIS. protected location to the requestor depends on the success of five
3. The LIS must be able to identify the device by its identifier steps:
(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.
Of these, only the second, third and the fifth are within the scope 1. The client must determine the proper LIS.
of this document. The first step is based on either manual
configuration or on the LIS discovery defined in
[I-D.ietf-geopriv-lis-discovery], in which appropriate security
considerations are already discussed. The fourth step is dependent
on the specific positioning capabilities of the LIS, and is thus
outside the scope of this document.
9.1. Assuring that the proper LIS has been contacted 2. The client must connect to the proper LIS.
3. The LIS must be able to identify the Device by its identifier (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.
Of these, only steps 2, 3, and 5 are within the scope of this
document. Step 1 is based on either manual configuration or on the
LIS discovery defined in [RFC5986], in which appropriate security
considerations are already discussed. Step 4 is dependent on the
specific positioning capabilities of the LIS and is thus outside the
scope of this document.
9.1. Assuring That the Proper LIS Has Been Contacted
This document assumes that the LIS to be contacted is identified This document assumes that the LIS to be contacted is identified
either by an IP address or a domain name, as is the case for a LIS either by an IP address or a domain name, as is the case for a LIS
discovered as described in LIS Discovery discovered as described in LIS Discovery [RFC5986]. When the HELD
[I-D.ietf-geopriv-lis-discovery]. When the HELD transaction is transaction is conducted using TLS [RFC5246], the LIS can
conducted using TLS [RFC5246], the LIS can authenticate its identity, authenticate its identity, either as a domain name or as an IP
either as a domain name or as an IP address, to the client by address, to the client by presenting a certificate containing that
presenting a certificate containing that identifier as a identifier as a subjectAltName (i.e., as an iPAddress or dNSName,
subjectAltName (i.e., as an iPAddress or dNSName, respectively). In respectively). In the case of the HTTP binding described above, this
the case of the HTTP binding described above, this is exactly the is exactly the authentication described by TLS [RFC2818]. If the
authentication described by TLS [RFC2818]. If the client has client has external information as to the expected identity or
external information as to the expected identity or credentials of credentials of the proper LIS (e.g., a certificate fingerprint),
the proper LIS (e.g., a certificate fingerprint), these checks MAY be these checks MAY be omitted. Any binding of HELD MUST be capable of
omitted. Any binding of HELD MUST be capable of being transacted being transacted over TLS so that the client can request the above
over TLS so that the client can request the above authentication, and authentication, and a LIS implementation for a binding MUST include
a LIS implementation for a binding MUST include this feature. Note this feature. Note that in order for the presented certificate to be
that in order for the presented certificate to be valid at the valid at the client, the client must be able to validate the
client, the client must be able to validate the certificate. In certificate. In particular, the validation path of the certificate
particular, the validation path of the certificate must end in one of must end in one of the client's trust anchors, even if that trust
the client's trust anchors, even if that trust anchor is the LIS anchor is the LIS certificate itself.
certificate itself.
9.2. Protecting responses from modification 9.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 9.1), the channel will be integrity protected by per Section 9.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.
9.3. Privacy and Confidentiality 9.3. Privacy and Confidentiality
skipping to change at page 24, line 31 skipping to change at page 24, line 10
transactions conducted over TLS with appropriate ciphersuites are transactions conducted over TLS with appropriate ciphersuites are
protected from access by unauthorized parties en route. Conversely, protected from access by unauthorized parties en route. Conversely,
in most cases, when not conducted over TLS, the response will be in most cases, when not conducted over TLS, the response will be
accessible while en route from the LIS to the requestor. accessible while en route from the LIS to the 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 to authorized clients; LIS implementations location is given only to authorized clients; LIS implementations
MUST support a mode of operation in which this is the only client MUST support a mode of operation in which this is the only client
authentication. authentication.
Using IP return routability as an authenticator means that location Using IP return routability as an authenticator means that location
information is vulnerable to exposure through IP address spoofing information is vulnerable to exposure through IP address spoofing
attacks. A temporary spoofing of IP address could mean that a device attacks. A temporary spoofing of an IP address could mean that when
c ould request a Location Object or Location URI that would result in a Device requests a Location Object or Location URI, it receives
receiving another Device's location if the attacker is able to another Device's location because the attacker is able to receive
receive packets sent to the spoofed address. In addition, in cases packets sent to the spoofed address. In addition, in cases where a
where a Device drops off the network for various reasons, the re-use Device drops off the network for various reasons, the re-use of the
of the Device's IP address could result in another Device receiving Device's IP address could result in another Device receiving the
the original Device's location rather than its own location. These original Device's location rather than its own location. These
exposures are limited by the following: exposures are limited by the following:
o Location URIs MUST have a limited lifetime, as reflected by the o Location URIs MUST have a limited lifetime, as reflected by the
value for the expires element in Section 6.5.2. The lifetime of value for the "expires" element in Section 6.5.2. The lifetime of
location URIs necessarily depends on the nature of the access. Location URIs necessarily depends on the nature of the access.
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, additional measures may not be necessary. an environment, additional measures may not be necessary.
10. Examples 10. Examples
The following sections provide basic HTTP/HTTPS examples, a simple The following sections provide examples of basic HTTP/HTTPS, a simple
location request example and a location request for multiple location location request, and a location request for multiple location types,
types example along with the relevant location responses. To focus along with the relevant location responses. To focus on important
on important portions of messages, the examples in Section 10.2 and portions of messages, the examples in Sections 10.2 and 10.3 do not
Section 10.3 do not show HTTP/HTTPS headers or the XML prologue. In show HTTP/HTTPS headers or the XML prologue. In addition, sections
addition, sections of XML not relevant to the example are replaced of XML not relevant to the example are replaced with comments.
with comments.
10.1. HTTPS Example Messages 10.1. Examples of HTTPS Messages
The examples in this section show complete HTTP/HTTPS messages that The examples in this section show complete HTTP/HTTPS messages that
include the HELD request or response document. include the HELD request or response document.
This example shows the most basic request for a LO. The POST This example shows the most basic request for a LO. The POST
includes an empty "locationRequest" element. includes an empty "locationRequest" element.
POST /location HTTP/1.1 POST /location HTTP/1.1
Host: lis.example.com:49152 Host: lis.example.com:49152
Content-Type: application/held+xml;charset=utf-8 Content-Type: application/held+xml;charset=utf-8
skipping to change at page 27, line 22 skipping to change at page 26, line 37
Content-Type: application/held+xml;charset=utf-8 Content-Type: application/held+xml;charset=utf-8
Content-Length: 182 Content-Length: 182
<?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 xml:lang="en">Unable to determine location <message xml:lang="en">Unable to determine location
</message> </message>
</error> </error>
10.2. Simple Location Request Example 10.2. Example of a Simple Location Request
The location request shown below doesn't specify any location types The location request shown below doesn't specify any location types
or response time. or response time.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
The example response to this location request contains a list of The example response to this location request contains a list of
Location URIs. Location URIs.
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"> <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
skipping to change at page 28, line 4 skipping to change at page 27, line 7
Location URIs. Location URIs.
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"> <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2006-01-01T13:00:00.0Z"> <locationUriSet expires="2006-01-01T13:00:00.0Z">
<locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o <locationURI>https://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 xml:lang="en">Location not available
</message> </message>
</error> </error>
10.3. Location Request Example for Multiple Location Types 10.3. An Example of a Location Request for Multiple Location Types
The following Location Request message includes a request for The following Location Request message includes a request for
geodetic, civic and any Location URIs. geodetic, civic, and any Location URIs.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="true"> <locationType exact="true">
geodetic geodetic
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.0Z"> <locationUriSet expires="2006-01-01T13:00:00.0Z">
<locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o <locationURI>https://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" <presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:ae3be8585902e2253ce2@10.102.23.9"> entity="pres:ae3be8585902e2253ce2@10.102.23.9">
skipping to change at page 29, line 41 skipping to change at page 28, line 38
<method>Wiremap</method> <method>Wiremap</method>
</geopriv> </geopriv>
</status> </status>
<timestamp>2007-05-24T12:35:02+10:00</timestamp> <timestamp>2007-05-24T12:35:02+10:00</timestamp>
</tuple> </tuple>
</presence> </presence>
</locationResponse> </locationResponse>
11. IANA Considerations 11. IANA Considerations
This document requires several IANA registrations detailed in the IANA has made the registrations detailed in the following sections.
following sections.
11.1. URN Sub-Namespace Registration for 11.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 "urn:ietf:params:xml:ns:geopriv:held", per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:held URI: urn:ietf:params:xml:ns:geopriv:held
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com). Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Mary Barnes (mary.ietf.barnes@gmail.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>
<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 replace XXXX <p>See RFC 5985</p>
with the RFC number for this specification.]
<p>See RFCXXXX</p>
</body> </body>
</html> </html>
END END
11.2. XML Schema Registration 11.2. XML Schema Registration
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:geopriv:held URI: urn:ietf:params:xml:schema:geopriv:held
skipping to change at page 30, line 36 skipping to change at page 29, line 29
</body> </body>
</html> </html>
END END
11.2. XML Schema Registration 11.2. XML Schema Registration
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [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.ietf.barnes@gmail.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.
11.3. MIME Media Type Registration for 'application/held+xml' 11.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.
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
Same as the charset parameter of "application/xml" as specified in Same as the charset parameter of "application/xml" as specified in
RFC 3023 [RFC3023], section 3.2. RFC 3023 [RFC3023], Section 3.2.
Encoding considerations: Same as the encoding considerations of Encoding considerations: Same as the encoding considerations of
"application/xml" as specified in RFC 3023 [RFC3023], section 3.2. "application/xml" as specified in RFC 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. There are multiple interoperable implementations
Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please of this protocol.
replace XXXX with the RFC number for this specification.]
Published specification: RFC 5985
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)
File extension(s): .xml Additional Information:
Magic Number(s): (none)
File extension(s): .heldxml
Macintosh File Type Code(s): "TEXT" Macintosh File Type Code(s): "TEXT"
Person & email address to contact for further information: Mary
Barnes <mary.barnes@nortel.com> Person & email address to contact for further information:
Mary Barnes <mary.ietf.barnes@gmail.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 [RFC3023], and many of the considerations application/xml [RFC3023], and many of the considerations
described there also apply to application/held+xml. described there also apply to application/held+xml.
11.4. Error code Registry 11.4. Error Code Registry
This document requests that the IANA create a new registry for the As defined in this document, IANA created a new registry for the HELD
HELD protocol including an initial registry for error codes. The protocol including an initial registry for error codes. The error
error codes are included in HELD error messages as described in codes are included in HELD error messages as described in Section 6.3
Section 6.3 and defined in the schema in the 'codeType' token in the and defined in the schema in the 'codeType' token in the XML schema
XML schema in (Section 7) in Section 7.
The following summarizes the requested registry: The following is a summary of the 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
with the RFC number for this specification.] Defining RFC: RFC 5985
Registration/Assignment Procedures: Following the policies outlined Registration/Assignment Procedures: Following the policies outlined
in [RFC5226], the IANA policy for assigning new values for the in [RFC5226], the IANA policy for assigning new values for the
Error codes for HELD shall be Standards Action: Values are Error codes for HELD is Standards Action: Values are assigned only
assigned only for Standards Track RFCs approved by the IESG. for Standards Track RFCs approved by the IESG.
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.ietf.barnes@gmail.com).
This section pre-registers the following seven initial error codes as This section registers the following eight initial error codes as
described above in Section 6.3: described 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. This error code is used when supported or understood by the LIS. This error code is used when
a HELD request contains a document element that is not supported a HELD request contains a document element that is not supported
by the receiver. by the receiver.
timeout: This code indicates that the LIS could not satisfy the timeout: This code indicates that the LIS could not satisfy the
request within the time specified in the "responseTime" parameter. request within the time specified in the "responseTime" parameter.
cannotProvideLiType: This code indicates that the LIS was unable to cannotProvideLiType: This code indicates that the LIS was unable to
provide LI of the type or types requested. This code is used when provide LI of the type or types requested. This code is used when
the "exact" attribute on the "locationType" parameter is set to the "exact" attribute on the "locationType" parameter is set to
"true". "true".
notLocatable: This code indicates that the LIS is unable to locate notLocatable: This code indicates that the LIS is unable to locate
the Device, and that the Device MUST NOT make further attempts to the Device and that the Device MUST NOT make further attempts to
retrieve LI from this LIS. This error code is used to indicate retrieve LI from this LIS. This error code is used to indicate
that the Device is outside the access network served by the LIS; that the Device is outside the access network served by the LIS;
for instance, the VPN and NAT scenarios discussed in for instance, the VPN and NAT scenarios discussed in
Section 4.1.2. Section 4.1.2.
12. Contributors 12. 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 below. They made additional
section. In addition, they also contributed to the WG document, contributions to the WG document, including the XML schema.
including the XML schema.
13. Acknowledgements
The author/contributors would like to thank the participants in the
GEOPRIV WG and the following people for their constructive input and
feedback on this document (in alphabetical order): Nadine Abbott,
Bernard Aboba, Eric Arolick, Richard Barnes (in particular the
security section), Peter Blatherwick, Ben Campbell, Guy Caron, Eddy
Corbett, Martin Dawson, Lisa Dusseault, Robins George, Jerome
Grenier, Ted Hardie, Cullen Jennings, Neil Justusson, Tat Lam, Marc
Linsner, Patti McCalmont, Alexey Melnikov, Roger Marshall, Tim Polk,
Perry Prozeniuk, Carl Reed, Julian Reschke, Eric Rescorla, Dan
Romascanu, Brian Rosen, John Schnizlein, Shida Schubert, Henning
Schulzrinne, Ed Shrum, Doug Stuard, Hannes Tschofenig and Karl Heinz
Wolf.
14. Changes since last Version
NOTE TO THE RFC-Editor: Please remove this section prior to
publication as an RFC.
Changes from 15 to 16(IESG Review DISCUSSES/comments):
1) Editorial Clarifications.
2) Section 6.4 added explicit reference to draft-ietf-ltru-4646bis
3) Section 6.5.3/examples (Expiry Time): clarified the details (UTC/
Gregorian calendar) for the expiry time and updated examples to
include fractional seconds and trailing 'Z'.
4) Section 8: Clarified the usage of wildcards in the domain name for
server authentication.
5) Section 10.1: Fixed examples - added charset attribute to Content
Type and fixed lengths
6) Section 11.3 (IANA mime registration), replaced text for Optional
paramters and Encoding considerations with references to RFC 3023.
Fixed Macintosh File Type Code.
7) Updated location-conveyance reference to SIPCORE document.
Changes from 14 to 15(Gen-Art and IETF discussion ML comments post
3rd IETF LC):
1) Clarification around device support for cookies or basic/digest
authentication.
2)Additional text in section 6.3 (PIDF-LO) around the LIS including
(and not including) any information identifying the device in the
returned PIDF-LO.
3) As always, a few additional editorial changes and clarifications.
Changes from 13 to 14 (AD comments post 2nd IETF LC):
1) Section 4.3: Removed reference to location-dereference protocol
document. Generalized statement wrt HELD not meeting all the lbyr
requirements (e.g., cancelling of location references).
2) Removed section 5.1 (Delivery Protocol) and just left the
statement that this document describes the use of HTTP and that HELD
is an application layer protocol.
3) Section 6.1: "the LIS should provide the most accurate LI" -> "the
LIS provides the most accurate LI" to avoid the inference of a
normative requirement.
4) Section 6.3: clarified "locationUnknown" error code.
5) Section 6.4: changed text to indication that errors can contain
multiple "message" parameters to accommodate errors in different
languages.
6) Section 7 : updated XML schema to reflect change in error message
to accommodate multiple "message" parameters. Note, a few other
changes to XML schema based on "strict" validation.
7) Section 8: clarified that redirect should be authenticated if the
Device requires that the redirect server is authenticated.
8) Section 10:
- updated examples due to updates to XML schema
- removed empty POST example.
9) Section 11.4: Changed IANA registration for error codes from
"Specification Required" to "Standards Action"
10) Other minor clarifications.
Changes from WG 12 to 13 (Post-2nd WGLC):
1) Fixed editorial error in section 6.2 with regards to empty
"locationType" - error was introduced in 06 to 07 changes.
2) Added additional text in section 6.5.1 to improve security
associated with locationURIs.
3) Modified XML schema for errorType and responseType to allow an
attribute to be returned. Also, added extensibility to errorType.
Changes from WG 11 to 12 (Post-2nd WGLC):
1) Expanded text in section 8 (HTTP binding) to provide more detail
about the requirements for an HTTP implementation supporting HELD.
Clarified the mandatory functionality and specific handling of other
functionality of HTTP.
2) Clarification in section 9.1 for clients that have external info
wrt the identity or credentials of the LIS.
3) More nits.
Changes from WG 10 to 11 (Post-2nd WGLC):
1) Added additional text around the scope and applicability of the
URI returned from LIS Discovery (section 4).
2) Removed HTTP GET - will always use POST.
3) Removed sentence wrt mobile devices in section 6.2.
4) Added specific recommendation for minimum value for expires in
section 6.5.2 (30 Minutes).
5) Remove reference to RFC 3704 (for IP address spoofing) in section
9.3 (bullet 2).
6) Clarified that both HTTP and HTTPS are allowed - changed last
bullet in section 5.1 from REQUIRES to RECOMMENDS.
7) Clarification wrt "presence" parameter in section 6.6 - a "single"
presence parameter may be included.
Changes from WG 09 to 10 (2nd WGLC):
1) Updated text for Devices and VPNs (section 4.1.1) to include
servers such as HTTP and SOCKs, thus changed the text to be generic
in terms of locating LIS before connecting to one of these servers,
etc.
2) Fixed (still buggy) HTTP examples.
3) Added text explaining the whitespaces in XML schema are for
readability/document format limitations and that they should be
handled via parser/schema validation.
4) Miscellaneous editorial nits
Changes from WG 08 to 09 (Post-IETF LC: continued resolution of sec-
dir and gen-art review comments, along with apps-area feedback):
1) Removed heldref/heldrefs URIs, including fixing examples (which
were buggy anyways).
2) Clarified text for locationURI - specifying that the deref
protocol must define or appropriately restrict and clarifying that
requirements for deref must be met and that deref details are out of
scope for this document.
3) Clarified text in security section for support of both HTTP/HTTPS.
4) Changed definition for Location Type to force the specification of
at least one location type.
Changes from WG 07 to 08 (IETF LC: sec-dir and gen-art review
comments):
1) Fix editorial nits: rearranging sections in 4.1 for readibility,
etc.
2) Added back text in Device and VPN section referencing DHCP and
LLDP-MED when a VPN device serves as a LIS.
3) Clarified the use of both HTTP and HTTPS.
4) Defined two URIs related to 3 respectively - divided IANA
registrations into sub-sections to accomodate this change. (Note:
LIS Discovery will now define that URI, thus this document defines
the one associatied with a Location reference).
5) Clarified the description of the location URI in Protocol Overview
and Protocol parameter sections. Note that these sections again
reference location dereference protocol for completeness and
clarification of issues that are out of scope for this base document.
6) Defined new error code: notLocatable.
7) Clarifications and corrections in security section.
8) Clarified text for locationType, specifically removing extra text
from "any" description and putting that in a separate paragraph.
Also, provided an example.
9) Added boundaries for "expires" parameter.
10) Clarified that the HELD protocol as defined by this document does
not allow for canceling location references.
Changes from WG 06 to 07 (PROTO review comments):
1) Fix nits: remove unused references, move requirements to
Informational References section, fix long line in ABNF, fix ABNF
(quotes around '?'), add schemaLocation to import namespace in XML
schema.
2) Remove text in Device and VPN section referencing DHCP and LLDP-
MED when a VPN device serves as a LIS, per Issue 1 resolution at
IETF-71. (Editorial oversight in producing version 06).
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):
1) Totally replaced the security section with the details provided by
Richard Barnes so that we don't need a reference to the location
security document.
2) Fixed error codes in schema to allow extensibility. Change the
IANA registration to be "specification required".
3) Cleaned up the HELD: URI description, per comments from Martin and
James and partially addressing HELD-04 Issue 1. Put the definition
in a separate section and clarified the applicability (to also
include being a results of the discovery process) and fixed examples.
4) Updated the LocationURI section to be more accurate, address
HELD-04 Issue 3, and include the reference to the new HELD:URI
section. Also, fixed an error in the doc in that the top level parm
in the locationResponse is actually locationUriSet, which contains
any number of locationURI elements and the "expires" parameter. So,
Table 1 was also updated and a new section for the LocationURISet was
added that includes the subsections for the "locationURI" and
"expires". And, then clarified that "expires" applies to
"locationURISet" and not per "locationURI".
5) Editorial nits: pointed out offline by Richard (e.g., by-value ->
by value, by-reference -> by reference, etc.) and onlist by James and
Martin. Please refer to the diff for a complete view of editorial
changes.
6) Added text in HTTP binding section to disable HTTP caching
(HELD-04 Issue 5 on the list).
Changes from WG 03 to 04:
1) Terminology: clarified in terminology section that "attribute" and
"element" are used in the strict XML sense and "parameter" is used as
a general protocol term Replaced term "HTTP delivery" with "HTTP
transport". Still have two terms "HTTP transport" and "HTTP
binding", but those are consistent with general uses of HTTP.
2) Editorial changes and clarifications: per Roger Marshall's and
Eric Arolick's comments and subsequent WG mailing list discussion.
3) Changed normative language for describing expected and recommended
LIS behaviors to be non-normative recommendations in cases where the
protocol parameters were not the target of the discussion (e.g., we
can't prescribe to the LIS how it determines location or what it
defines to be an "accurate" location).
4) Clarified responseTime attribute (section 6.1). Changed type from
"decimal" to "nonNegativeInteger" in XML schema (section 7)
5) Updated Table 1 in section 6 to only include top-level parameters
and fixed some errors in that table (i.e., code for locationResponse)
and adding PIDF-LO to the table. Added a detailed section describing
PIDF-LO (section 6.6), moving some of the normative text in the
Protocol Overview to this section.
6) Added schema and description for locationURI to section 6.5.
Added IANA registration for HELD: URI schema.
7) Added IANA registry for error codes.
Changes from WG 02 to 03:
1) Added text to address concern over use of IP address as device
identifier, per long email thread - changes to section 3 (overview)
and section 4 (protocol overview).
2) Removed WSDL (section 8 updated, section 8.1 and 10.4 removed)
3) Added extensibility to baseRequestType in the schema (an oversight
from previous edits), along with fixing some other nits in schema
(section 7)
4) Moved discussion of Location URI from section 5.3 (Location
Response) to where it rightly belonged in Section 6.5 (Location URI
Parameter).
5) Clarified text for "expires" parameter (6.5.1) - it's an optional
parm, but required for LocationURIs
6) Clarified responseTime parameter: when missing, then the LCS
provides most precise LI, with the time required being implementation
specific.
7) Clarified that the MUST use in section 8 (HTTP binding) is a MUST
implement.
8) Updated references (removed unused/added new).
Changes from WG 01 to 02:
1) Updated Terminology to be consistent with WG agreements and other
documents (e.g., LCS -> LIS and removed duplicate terms). In the
end, there are no new terms defined in this document.
2) Modified definition of responseTime to reflect WG consensus.
3) Removed jurisdictionalCivic and postalCivic locationTypes (leaving
just "civic").
4) Clarified text that locationType is optional. Fixed table 1 and
text in section 5.2 (locationRequest description). Text in section
6.2 (description of locationType element) already defined the default
to be "any".
5) Simplified error responses. Separated the definition of error
response type from the locationResponse type thus no need for
defining an error code of "success". This simplifies the schema and
processing.
6) Updated schema/examples for the above.
7) Updated Appendix A based on updates to requirements document,
specifically changes to A.1, A.3 and adding A.10.
8) Miscellaneous editorial clarifications.
Changes from WG 00 to 01:
1) heldResponse renamed to locationResponse.
2) Changed namespace references for the PIDF-LO geoShape in the James Winterbottom
schema to match the agreed GML PIDF-LO Geometry Shape Application Andrew
Schema. Andrew Building (39)
University of Wollongong
Northfields Avenue
Wollongong, NSW 2522
AU
3) Removed "options" element - leaving optionality/extensibility to Phone: +61 2 4221 2938
XML mechanisms. EMail: james.winterbottom@andrew.com
URI: http://www.andrew.com/
4) Changed error codes to be enumerations and not redefinitions of Martin Thomson
HTTP response codes. Andrew
Andrew Building (39)
University of Wollongong
Northfields Avenue
Wollongong, NSW 2522
AU
5) Updated schema/examples for the above and removed some remnants of Phone: +61 2 4221 2915
the context element. EMail: martin.thomson@andrew.com
URI: http://www.andrew.com/
6) Clarified the definition of "Location Information (LI)" to include Barbara Stark
a reference to the location (to match the XML schema and provide BellSouth
consistency of usage throughout the document). Added an additional Room 7A43
statement in section 7.2 (locationType) to clarify that LCS MAY also 725 W Peachtree St.
return a Location URI. Atlanta, GA 30308
US
7) Modifed the definition of "Location Configuration Server (LCS)" to EMail: barbara.stark@att.com
be consistent with the current definiton in the requirements
document.
8) Updated Location Response (section 6.3) to remove reference to 13. Acknowledgements
context and discuss the used of a local identifier or unlinked
pseudonym in providing privacy/security.
9) Clarified that the source IP address in the request is used as the The author and contributors would like to thank the participants in
identifier for the target/device for the HELD protocol as defined in the GEOPRIV WG and the following people for their constructive input
this document. and feedback on this document (in alphabetical order): Nadine Abbott,
Bernard Aboba, Eric Arolick, Richard Barnes (in particular, the
security considerations section), Peter Blatherwick, Ben Campbell,
Guy Caron, Eddy Corbett, Martin Dawson, Lisa Dusseault, Robins
George, Jerome Grenier, Ted Hardie, Cullen Jennings, Neil Justusson,
Tat Lam, Marc Linsner, Patti McCalmont, Alexey Melnikov, Roger
Marshall, Tim Polk, Perry Prozeniuk, Carl Reed, Julian Reschke, Eric
Rescorla, Dan Romascanu, Brian Rosen, John Schnizlein, Shida
Schubert, Henning Schulzrinne, Ed Shrum, Doug Stuard, Hannes
Tschofenig, and Karl Heinz Wolf.
10) Miscellaneous editorial clarifications. 14. References
15. References 14.1. Normative References
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2965, October 2000.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2965, October 2000.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO) Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations", Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009. RFC 5491, March 2009.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009.
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", RFC 5986,
September 2010.
[W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-1-20041028]
Maloney, M., Thompson, H., Mendelsohn, N., and D. Beech, Thompson, H., Mendelsohn, N., Beech, D., and M. Maloney,
"XML Schema Part 1: Structures Second Edition", World Wide "XML Schema Part 1: Structures Second Edition", World Wide
Web Consortium Recommendation REC-xmlschema-1-20041028, Web Consortium Recommendation REC-xmlschema-1-20041028,
October 2004, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[W3C.REC-xmlschema-2-20041028] [W3C.REC-xmlschema-2-20041028]
Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium Second Edition", World Wide Web Consortium
Recommendation REC-xmlschema-2-20041028, October 2004, Recommendation REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[I-D.ietf-geopriv-lis-discovery] 14.2. Informative References
Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)",
draft-ietf-geopriv-lis-discovery-11 (work in progress),
May 2009.
15.2. Informative References [LLDP-MED]
TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
Endpoint Discovery".
[LOC-CONVEY]
Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
for the Session Initiation Protocol", Work in Progress,
July 2010.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999. RFC 2617, June 1999.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Configuration Protocol Option for Coordinate-based
Location Configuration Information", RFC 3825, July 2004. Location Configuration Information", RFC 3825, July 2004.
[LLDP-MED]
TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
Endpoint Discovery".
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[I-D.ietf-ltru-4646bis]
Phillips, A. and M. Davis, "Tags for Identifying
Languages", draft-ietf-ltru-4646bis-23 (work in progress),
June 2009.
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,
July 2006. July 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[I-D.ietf-geopriv-l7-lcp-ps] [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and
Location Configuration Protocol; Problem Statement and Requirements", RFC 5687, March 2010.
Requirements", draft-ietf-geopriv-l7-lcp-ps-10 (work in
progress), July 2009.
[I-D.ietf-geopriv-lbyr-requirements]
Marshall, R., "Requirements for a Location-by-Reference
Mechanism", draft-ietf-geopriv-lbyr-requirements-07 (work
in progress), February 2009.
[I-D.ietf-sipcore-location-conveyance] [RFC5808] Marshall, R., "Requirements for a Location-by-Reference
Polk, J. and B. Rosen, "Location Conveyance for the Mechanism", RFC 5808, May 2010.
Session Initiation Protocol",
draft-ietf-sipcore-location-conveyance-01 (work in
progress), July 2009.
Appendix A. HELD Compliance to IETF LCP requirements Appendix A. HELD Compliance to IETF LCP Requirements
This appendix describes HELD's compliance to the requirements This appendix describes HELD's compliance to the requirements
specified in the [I-D.ietf-geopriv-l7-lcp-ps]. specified in [RFC5687].
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
HELD uses the IP address of the location request message as the HELD uses the IP address of the location request message as the
primary source of identity for the requesting device or target. This primary source of identity for the requesting Device or target. This
identity can be used with other contextual network information to identity can be used with other contextual network information to
provide a physical location for the Target for many network provide a physical location for the Target for many network
deployments. There may be network deployments where an IP address deployments. There may be network deployments where an IP address
alone is insufficient to identify a Target in a network. However, alone is insufficient to identify a Target in a network. However,
any necessary identity extensions for these networks is beyond the any necessary identity extensions for these networks is beyond the
scope of this document. scope of this document.
A.2. L7-2: Mobility Support A.2. L7-2: Mobility Support
"The GEOPRIV Layer 7 Location Configuration Protocol MUST support a "The GEOPRIV Layer 7 Location Configuration Protocol MUST support a
broad range of mobility from devices that can only move between broad range of mobility from Devices that can only move between
reboots, to devices that can change attachment points with the impact reboots, to Devices that can change attachment points with the impact
that their IP address is changed, to devices that do not change their that their IP address is changed, to Devices that do not change their
IP address while roaming, to devices that continuously move by being IP address while roaming, to Devices that continuously move by being
attached to the same network attachment point." attached to the same network attachment point."
COMPLY COMPLY
Mobility support is inherently a characteristic of the access network Mobility support is inherently a characteristic of the access network
technology and HELD is designed to be access network agnostic. technology, and HELD is designed to be access network agnostic.
Consequently HELD complies with this requirement. In addition HELD Consequently, HELD complies with this requirement. In addition, HELD
provides specific support for mobile environments by providing an provides specific support for mobile environments by providing an
optional responseTime attribute in location request messages. optional responseTime attribute in location request messages.
Wireless networks often have several different mechanisms at their Wireless networks often have several different mechanisms at their
disposal for position determination (e.g. Assisted GPS versus disposal for position determination (e.g., assisted GPS versus
location based on serving base station identity), each providing determining the location based on the identity of the serving base
different degrees of accuracy and taking different amounts of time to station), each providing different degrees of accuracy and taking
yield a result. The responseTime parameter provides the LIS with a different amounts of time to yield a result. The responseTime
criterion which it can use to select a location determination parameter provides the LIS with a criterion which it can use to
technique. select a location determination technique.
A.3. L7-3: ASP and Access Network Provider Relationship A.3. L7-3: ASP and Access Network Provider Relationship
"The design of the L7 LCP MUST NOT assume a business or trust "The design of the L7 LCP MUST NOT assume a business or trust
relationship between the Application Service Provider (ASP) and the relationship between the Application Service Provider (ASP) and the
Access Network Provider. Requirements for resolving a reference to Access Network Provider. Requirements for resolving a reference to
location information are not discussed in this document." location information are not discussed in this document."
COMPLY COMPLY
skipping to change at page 44, line 50 skipping to change at page 37, line 46
be bound to transports other than HTTP, such as BEEP. Using a be bound to transports other than HTTP, such as BEEP. Using a
protocol such as BEEP offers the option of high request throughput protocol such as BEEP offers the option of high request throughput
over a dedicated connection between an L3 provider and an L2 provider over a dedicated connection between an L3 provider and an L2 provider
without incurring the serial restriction imposed by HTTP. This is without incurring the serial restriction imposed by HTTP. This is
less easy to do with protocols that do not decouple themselves from less easy to do with protocols that do not decouple themselves from
the transport. the transport.
A.5. L7-5: Legacy Device Considerations A.5. L7-5: Legacy Device Considerations
"The design of the GEOPRIV Layer 7 Location Configuration Protocol "The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST consider legacy residential NAT devices and NTEs in an DSL MUST consider legacy residential NAT Devices and Network Termination
environment that cannot be upgraded to support additional protocols, Equipment (NTE) in an DSL environment that cannot be upgraded to
for example to pass additional information through DHCP." support additional protocols, for example to pass additional
information through DHCP."
COMPLY COMPLY
HELD is an application protocol and operates on top of IP. A HELD HELD is an application protocol and operates on top of IP. A HELD
request from a host behind a residential NAT will traverse the NAT request from a host behind a residential NAT will traverse the NAT
acquiring the external address of the home router. The location acquiring the external address of the home router. The location
provided to the host therefore will be the address of the home router provided to the host therefore will be the address of the home router
in this circumstance. No changes are required to the home router in in this circumstance. No changes are required to the home router in
order to support this function, HELD was designed specifically to order to support this function, HELD was designed specifically to
address this deployment scenario. address this deployment scenario.
A.6. L7-6: VPN Awareness A.6. L7-6: VPN Awareness
"The design of the GEOPRIV Layer 7 Location Configuration Protocol "The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST assume that at least one end of a VPN is aware of the VPN MUST assume that at least one end of a VPN is aware of the VPN
functionality. In an enterprise scenario, the enterprise side will functionality. In an enterprise scenario, the enterprise side will
provide the LIS used by the client and can thereby detect whether the provide the LIS used by the client and can thereby detect whether the
LIS request was initiated through a VPN tunnel." LIS request was initiated through a VPN tunnel."
COMPLY COMPLY
HELD does not preclude a LIS on the far end of a VPN tunnel being HELD does not preclude a LIS on the far end of a VPN tunnel from
aware that the client request is occurring over that tunnel. It also being aware that the client request is occurring over that tunnel.
does not preclude a client device from accessing a LIS serving the It also does not preclude a client Device from accessing a LIS
local physical network and subsequently using the location serving the local physical network and subsequently using the
information with an application that is accessed over a VPN tunnel. location information with an application that is accessed over a VPN
tunnel.
A.7. L7-7: Network Access Authentication A.7. L7-7: Network Access Authentication
"The design of the GEOPRIV Layer 7 Location Configuration Protocol "The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST NOT assume prior network access authentication." MUST NOT assume prior network access authentication."
COMPLY COMPLY
HELD makes no assumptions about prior network access authentication. HELD makes no assumptions about prior network access authentication.
HELD strongly recommends the use of TLS with server-side certificates HELD strongly recommends the use of TLS with server-side certificates
for communication between the end-point and the LIS. There is no for communication between the endpoint and the LIS. There is no
requirement for the end-point to authenticate with the LIS. requirement for the endpoint to authenticate with the LIS.
A.8. L7-8: Network Topology Unawareness A.8. L7-8: Network Topology Unawareness
"The design of the GEOPRIV Layer 7 Location Configuration Protocol "The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST NOT assume end systems being aware of the access network MUST NOT assume end systems being aware of the access network
topology. End systems are, however, able to determine their public topology. End systems are, however, able to determine their public
IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP." IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP."
COMPLY COMPLY
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 [RFC5986].
[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 ". [RFC5491] rules outlined in [now RFC 5941]."
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 [RFC5491]. by the LIS MUST conform to [RFC5491].
Authors' Addresses Author's Address
Mary Barnes (editor) Mary Barnes (editor)
Nortel Polycom
2201 Lakeside Blvd
Richardson, TX
USA
Email: mary.barnes@nortel.com
James Winterbottom
Andrew
PO Box U40
Wollongong University Campus, NSW 2500
AU
Phone: +61 2 4221 2938
Email: james.winterbottom@andrew.com
URI: http://www.andrew.com/
Martin Thomson
Andrew
PO Box U40
Wollongong University Campus, NSW 2500
AU
Phone: +61 2 4221 2915
Email: martin.thomson@andrew.com
URI: http://www.andrew.com/
Barbara Stark
BellSouth
Room 7A43
725 W Peachtree St.
Atlanta, GA 30308
US
Email: barbara.stark@att.com EMail: mary.ietf.barnes@gmail.com
 End of changes. 204 change blocks. 
881 lines changed or deleted 525 lines changed or added

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