draft-ietf-geopriv-http-location-delivery-04.txt   draft-ietf-geopriv-http-location-delivery-05.txt 
GEOPRIV WG M. Barnes, Ed. GEOPRIV WG M. Barnes, Ed.
Internet-Draft Nortel Internet-Draft Nortel
Intended status: Standards Track Intended status: Standards Track
Expires: July 17, 2008 Expires: August 25, 2008
January 14, 2008 February 22, 2008
HTTP Enabled Location Delivery (HELD) HTTP Enabled Location Delivery (HELD)
draft-ietf-geopriv-http-location-delivery-04.txt draft-ietf-geopriv-http-location-delivery-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 17, 2008. This Internet-Draft will expire on August 25, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
A Layer 7 Location Configuration Protocol (L7 LCP) is described that A Layer 7 Location Configuration Protocol (L7 LCP) is described that
is used for retrieving location information from a server within an is used for retrieving location information from a server within an
access network. The protocol includes options for retrieving access network. The protocol includes options for retrieving
location information in two forms: by-value and by-reference. The location information in two forms: by value and by reference. The
protocol is an extensible application-layer protocol that is protocol is an extensible application-layer protocol that is
independent of session-layer. This document describes the use of independent of session-layer. This document describes the use of
Hypertext Transfer Protocol (HTTP) as a transport for the protocol. Hypertext Transfer Protocol (HTTP) as a transport for the protocol.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4
3. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Location by Value . . . . . . . . . . . . . . . . . . . . 7 4.1. Location by Value . . . . . . . . . . . . . . . . . . . . 7
4.2. Location by Reference . . . . . . . . . . . . . . . . . . 7 4.2. Location by Reference . . . . . . . . . . . . . . . . . . 7
4.3. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 7 4.3. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 7
4.3.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 8 4.3.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 8
4.3.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 8 4.3.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 8
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9
5.1. Delivery Protocol . . . . . . . . . . . . . . . . . . . . 9 5.1. Delivery Protocol . . . . . . . . . . . . . . . . . . . . 9
5.2. Location Request . . . . . . . . . . . . . . . . . . . . . 9 5.2. Location Request . . . . . . . . . . . . . . . . . . . . . 10
5.3. Location Response . . . . . . . . . . . . . . . . . . . . 10 5.3. Location Response . . . . . . . . . . . . . . . . . . . . 10
5.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 10 5.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 10
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10
6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11 6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11
6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 11 6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12
6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 12 6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 12
6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 12 6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 13
6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 13 6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 13
6.5. "locationURI" Parameter . . . . . . . . . . . . . . . . . 13 6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 13
6.5.1. "expires" Parameter . . . . . . . . . . . . . . . . . 14 6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 14
6.6. "pidf-LO" Parameter . . . . . . . . . . . . . . . . . . . 15 6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 14
6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 14
7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. HELD: URI Definition . . . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Return Routability . . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9.2. Transaction Layer Security . . . . . . . . . . . . . . . . 21 10.1. Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . 20
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.1.1. Assuring that the proper LIS has been contacted . . . 21
10.1. HTTP Example Messages . . . . . . . . . . . . . . . . . . 21 10.1.2. Protecting responses from modification . . . . . . . . 21
10.2. Simple Location Request Example . . . . . . . . . . . . . 24 10.2. Privacy and Confidentiality . . . . . . . . . . . . . . . 22
10.3. Location Request Example for Multiple Location Types . . . 25 10.3. Summary of Security Considerations . . . . . . . . . . . . 23
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 26 11.1. HTTP Example Messages . . . . . . . . . . . . . . . . . . 23
11.1.1. URN Sub-Namespace Registration for 11.2. Simple Location Request Example . . . . . . . . . . . . . 26
urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . 26 11.3. Location Request Example for Multiple Location Types . . . 27
11.1.2. URN Sub-Namespace Registration for 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
urn:ietf:params:xml:ns:geopriv:held:http . . . . . . . 27 12.1. URN Sub-Namespace Registration for
11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 28 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 28
11.3. MIME Media Type Registration for 'application/held+xml' . 28 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 29
11.4. Error code Registry . . . . . . . . . . . . . . . . . . . 29 12.3. MIME Media Type Registration for 'application/held+xml' . 29
11.5. URI Registration . . . . . . . . . . . . . . . . . . . . . 29 12.4. Error code Registry . . . . . . . . . . . . . . . . . . . 30
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30 12.5. URI Registration . . . . . . . . . . . . . . . . . . . . . 31
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32
14. Changes since last Version . . . . . . . . . . . . . . . . . . 31 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 15. Changes since last Version . . . . . . . . . . . . . . . . . . 32
15.1. Normative References . . . . . . . . . . . . . . . . . . . 33 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
15.2. Informative References . . . . . . . . . . . . . . . . . . 35 16.1. Normative References . . . . . . . . . . . . . . . . . . . 36
Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 36 16.2. Informative References . . . . . . . . . . . . . . . . . . 37
A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 36 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 38
A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 36 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 38
A.3. L7-3: ASP and Access Network Provider Relationship . . . . 37 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 38
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 37 A.3. L7-3: ASP and Access Network Provider Relationship . . . . 39
A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 37 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 39
A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 38 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 40
A.7. L7-7: Network Access Authentication . . . . . . . . . . . 38 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 40
A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 38 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 40
A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 39 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 41
A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 39 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . . . 43
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 [11] provides some problem statement and requirements document [13] provides some
scenarios in which the Device might rely on its access network to scenarios in which the Device might rely on its access network to
provide location information. The LIS service applies to access provide location information. The LIS service applies to access
networks employing both wired technology (e.g. DSL, Cable) and networks employing both wired technology (e.g. DSL, Cable) and
wireless technology (e.g. WiMAX) with varying degrees of Device wireless technology (e.g. WiMAX) with varying degrees of Device
mobility. This document describes a protocol that can be used to mobility. This document describes a protocol that can be used to
acquire Location Information (LI) from a Location Information Server acquire Location Information (LI) from a Location Information Server
(LIS) within an access network. (LIS) within an access network.
This specification identifies two types of location information that This specification identifies two types of location information that
may be retrieved from the LIS. Location may be retrieved from the may be retrieved from the LIS. Location may be retrieved from the
LIS by-value, that is, the Device may acquire a literal location LIS by value, that is, the Device may acquire a literal location
object describing the location of the Device. The Device may also object describing the location of the Device. The Device may also
request that the LIS provide a location reference in the form of a request that the LIS provide a location reference in the form of a
location URI or set of location URIs, allowing the Device to location URI or set of location URIs, allowing the Device to
distribute its LI by-reference. Both of these methods can be distribute its LI by reference. Both of these methods can be
provided concurrently from the same LIS to accommodate application provided concurrently from the same LIS to accommodate application
requirements for different types of location information. requirements for different types of location information.
This specification defines an extensible XML-based protocol that This specification defines an extensible XML-based protocol that
enables the retrieval of LI from a LIS by a Device. This protocol enables the retrieval of LI from a LIS by a Device. This protocol
can be bound to any session-layer protocol, particularly those can be bound to any session-layer protocol, particularly those
capable of MIME transport. This document describes the use of capable of MIME transport. This document describes the use of
Hypertext Transfer Protocol (HTTP) as a transport for the protocol. Hypertext Transfer Protocol (HTTP) as a transport for the protocol.
2. Conventions & Terminology 2. Conventions & Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1]. document are to be interpreted as described in [1].
This document uses the terms (and their acronym forms) Access This document uses the terms (and their acronym forms) Access
Provider (AP), Location Information (LI), Location Object (LO), Provider (AP), Location Information (LI), Location Object (LO),
Device, Target, Location Generator (LG), Location Recipient (LR), Device, Target, Location Generator (LG), Location Recipient (LR),
Rule Maker (RM) and Rule Holder (RH) as defined in RFC 3693, GEOPRIV Rule Maker (RM) and Rule Holder (RH) as defined in RFC 3693, GEOPRIV
Requirements [7] . The terms Location Information Server (LIS), Requirements [8] . The terms Location Information Server (LIS),
Access Network, Access Provider (AP) and Access Network Provider are Access Network, Access Provider (AP) and Access Network Provider are
used in the same context as defined in the L7 LCP Problem statement used in the same context as defined in the L7 LCP Problem statement
and Requirements document [11]. The usage of the terms, Civic and Requirements document [13]. 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). An Access Provider (AP) operates the LIS so the access network). An Access Provider (AP) operates the LIS so
that Devices (and Targets) can retrieve LI. The LIS exists because that Devices (and Targets) can retrieve their LI. The LIS exists
not all Devices are capable of determining LI, and because, even if a because not all Devices are capable of determining LI, and because,
device is able to determine its own LI, it may be more efficient with even if a device is able to determine its own LI, it may be more
assistance. This document does not specify how LI is determined. efficient with assistance. This document does not specify how LI is
determined.
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 [7] and the LIS defined in [11] and functional elements identified in [8] and the LIS defined in [13] and
where this protocol applies, with the Rule Maker and Target where this protocol applies, with the Rule Maker and Target
represented by the role of the Device. represented by the role of the Device.
+---------------------------------------------+ +---------------------------------------------+
| Access Network Provider | | Access Network Provider |
| | | |
| +--------------------------------------+ | | +--------------------------------------+ |
| | Location Information Server | | | | Location Information Server | |
| | | | | | | |
| | | | | | | |
skipping to change at page 6, line 37 skipping to change at page 6, line 37
<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 [23]. be found in the SIP Location Conveyance document [25].
4. Protocol Overview 4. Protocol Overview
The HELD protocol facilitates retrieval of location directly in the The HELD protocol facilitates retrieval of location directly in the
form of a PIDF-LO document (by-value) and indirectly as a Location form of a PIDF-LO document (by value) and indirectly as a Location
URI (by-reference). The policy that describes to whom, and how, LI URI (by reference). The policy that describes to whom, and how, LI
is granted is outside the scope of this document and may be specified is granted is outside the scope of this document and may be specified
in separate specifications as required. The Device must first in separate specifications as required.
discover the URI for the LIS for sending the HELD protocol requests
as identified by the requirement in the L7 LCP problem statement and As described in the L7 LCP problem statement and requirements [13],
requirements [11]. The discovery methods are specified in [14]. The the Device must first discover the URI for the LIS for sending the
LIS uses the source IP address of the request sent from the Device as HELD protocol requests. The discovery methods are specified in [16].
the identifier in determining the location of the device. The use of
additional identifiers for the HELD protocol is outside the scope of For the HELD protocol requests, the LIS uses the source IP address of
this document. the request sent from the Device as the identifier in determining the
location of the device. The use of additional identifiers for the
HELD protocol is outside the scope of this document.
4.1. Location by Value 4.1. Location by Value
Where a Device requires LI directly, it can request that the LIS Where a Device requires LI directly, it can request that the LIS
create a PIDF-LO document. This approach fits well with a create a PIDF-LO document. This approach fits well with a
configuration whereby the device directly makes use of the provided configuration whereby the device directly makes use of the provided
PIDF-LO document. The details on the information that may be PIDF-LO document. The details on the information that may be
included in the PIDF-LO MUST follow the subset of those rules included in the PIDF-LO MUST follow the subset of those rules
relating to the construction of the "location-info" element in the relating to the construction of the "location-info" element in the
PIDF-LO Usage Clarification, Considerations and Recommendations PIDF-LO Usage Clarification, Considerations and Recommendations
document [10]. Further detail is included in the detailed protocol document [12]. Further detail is included in the detailed protocol
section of this document Section 6 section of this document Section 6
4.2. Location by Reference 4.2. Location by Reference
Requesting location directly does not always address the requirements Requesting location directly does not always address the requirements
of an application. A Device can request a location URI instead of of an application. A Device can request a location URI instead of
literal location. A Location URI is a URI [20] of any scheme, which literal location. A Location URI is a URI [22] of any scheme, which
a Location Recipient (LR) can use to retrieve LI. A location URI a Location Recipient (LR) can use to retrieve LI. A location URI
provided by a LIS can be assumed to be globally-addressable; that is, provided by a LIS can be assumed to be globally-addressable; that is,
anyone in possession of the URI can access the LIS. This does not in anyone in possession of the URI can access the LIS. However, this
any way suggest that the LIS is bound to reveal the location does not in any way suggest that the LIS is bound to reveal the
associated with the location URI. This issue is deemed out of scope location associated with the location URI. This issue is deemed out
for this document. The merits and drawbacks of using a Location URI of scope for this document. The merits and drawbacks of using a
approach are discussed in [15]. Location URI approach are discussed in [17].
4.3. Device Identifiers, NAT and VPNs 4.3. Device Identifiers, NAT and VPNs
Use of the HELD protocol is subject to the viability of the Use of the HELD protocol is subject to the viability of the
identifier used by the LIS to determine location. This document identifier used by the LIS to determine location. This document
describes the use of the IP address of the Device as the identifier. describes the use of the source IP address sent from the Device as
When Network Address Translation (NAT), a Virtual Private Network the identifier used by the LIS. When Network Address Translation
(VPN) or other forms of address modification occur between the Device (NAT), a Virtual Private Network (VPN) or other forms of address
and the LIS, the location returned could be inaccurate. modification occur between the Device and the LIS the location
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 the LIS for example for a teleworker, then the IP address seen by a LIS
might not be the right address to identify the location of the inside the enterprise network might not be the right address to
Device. identify the location of the Device. Section 4.3.2 provides
recommendations to address this issue.
4.3.1. Devices and VPNs 4.3.1. Devices and VPNs
To minimize the impact of VPNs, Devices should perform their HELD To minimize the impact of VPNs, Devices should perform their HELD
query prior to establishing a VPN tunnel. It is RECOMMENDED that query prior to establishing a VPN tunnel. It is RECOMMENDED that
discovery [14] and an initial query are performed before establishing discovery [16] and an initial query are performed before establishing
the VPN. If a Device performs the HELD query after establishing the the VPN. If a Device performs the HELD query after establishing the
VPN tunnel, the Device may receive inaccurate location information. VPN tunnel the Device may receive inaccurate location information.
Devices that establish VPN connections for use by other devices Devices that establish VPN connections for use by other devices
inside a LAN or other closed network may serve as a LIS, that inside a LAN or other closed network could serve as a LIS, that
implements the HELD protocol, for those other Devices. Devices implements the HELD protocol, for those other Devices. Devices
within the closed network are not necessarily able to detect the within the closed network are not necessarily able to detect the
presence of the VPN and rely on the VPN device. To this end, a VPN presence of the VPN and rely on the VPN device. To this end, a VPN
device should provide the address, of the LIS server it provides, in device should provide the address of the LIS server it provides, in
response to discovery queries. response to discovery queries, rather than passing such queries
through the VPN tunnel.
It could also be useful for a VPN device to serve as a LIS for other It could also be useful for a VPN device to serve as a LIS for other
location configuration options such as Dynamic Host Configuration location configuration options such as Dynamic Host Configuration
Protocol (DHCP)[21] or Link Layer Discovery Protocol - Media Endpoint Protocol (DHCP)[23] or Link Layer Discovery Protocol - Media Endpoint
Discovery (LLDP-MED) [25]. VPN devices that serve as a LIS may Discovery (LLDP-MED) [27]. VPN devices that serve as a LIS may
acquire their own location using HELD. acquire their own location using HELD.
4.3.2. LIS Handling of NATs and VPNs 4.3.2. LIS Handling of NATs and VPNs
In the cases where the Device uses a VPN connection or is behind 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 may not be able to return private network to the Internet), the LIS might not be able to return
an accurate LI. If the LIS cannot determine an accurate LI, it an accurate LI. If the LIS cannot determine an accurate LI, it
should not provide location information to the requesting device. should not provide location information to the requesting device.
The LIS needs to be configured to recognize identifiers that The LIS needs to be configured to recognize identifiers that
represent these conditions. represent these conditions.
LIS operators have a large role in ensuring the best possible LIS operators have a large role in ensuring the best possible
environment for location determination. The LIS operator needs to environment for location determination. The LIS operator needs to
ensure that the LIS is properly configured with identifiers that fall ensure that the LIS is properly configured with identifiers that fall
within NATs and VPNs. In order to serve a Device on a remote side of within NATs and VPNs. In order to serve a Device on a remote side of
a NAT or VPN a LIS needs to have a presence on the side of the NAT or a NAT or VPN a LIS needs to have a presence on the side of the NAT or
VPN nearest the Device. VPN nearest the Device.
5. Protocol Description 5. Protocol Description
As discussed in Section 4, this protocol provides for the retrieval As discussed in Section 4, this protocol provides for the retrieval
of location in the form of a PIDF-LO document and/or Location URI(s) of the device's location in the form of a PIDF-LO document and/or
from a LIS. Three messages are defined to support the location Location URI(s) from a LIS. Three messages are defined to support
retrieval: locationRequest, locationResponse and error. Messages are the location retrieval: locationRequest, locationResponse and error.
defined as XML documents. Messages are defined as XML documents.
The Location Request (locationRequest) message is described in The Location Request (locationRequest) message is described in
Section 5.2. A Location Request message from a Device indicates Section 5.2. A Location Request message from a Device indicates
whether location in the form of a PIDF-LO document (with specific whether location in the form of a PIDF-LO document (with specific
type(s) of location) and/or Location URI(s) should be returned. The type(s) of location) and/or Location URI(s) should be returned. The
LIS replies with a response (locationResponse), including a PIDF-LO LIS replies with a locationResponse message, including a PIDF-LO
document and/or one or more Location URIs in case of success, or an document and/or one or more Location URIs in case of success. In the
error message in case of an error. case of an error, the LIS replies with an error message.
A MIME type "application/held+xml" is registered in Section 11.3 to A MIME type "application/held+xml" is registered in Section 12.3 to
distinguish HELD messages from other XML document bodies. This distinguish HELD messages from other XML document bodies. This
specification follows the recommendations and conventions described specification follows the recommendations and conventions described
in [18], including the naming convention of the type ('+xml' suffix) in [20], including the naming convention of the type ('+xml' suffix)
and the usage of the 'charset' parameter. and the usage of the 'charset' parameter.
Section 6 contains a more thorough description of the protocol Section 6 contains a more thorough description of the protocol
parameters, valid values, and how each should be handled. Section 7 parameters, valid values, and how each should be handled. Section 7
contains a more specific definition of the structure of these contains a more specific definition of the structure of these
messages in the form of an XML Schema [12]. messages in the form of an XML Schema [14].
5.1. Delivery Protocol 5.1. Delivery Protocol
The HELD protocol is an application-layer protocol that is defined The HELD protocol is an application-layer protocol specified by an
independently of any lower layers. This means that any protocol can XML document. The HELD protocol is defined independently of any
be used to transport this protocol providing that it can provide a lower layers used to transport messages from one host to another.
few basic features: This means that any protocol can be used to transport this protocol
o The protocol must have acknowledged delivery. providing that it can provide a few basic features:
o The protocol must be able to correlate a response with a request.
o The protocol must provide authentication, privacy and protection o The HELD protocol doesn't provide any mechanisms that enable
against modification. detection of missing messages and retransmission, thus the
protocol must have acknowledged delivery.
o The HELD protocol is a request, response protocol, thus the
protocol must be able to correlate a response with a request.
o The HELD protocol must provide authentication, confidentiality and
protection against modification per Section 10.2.
This document describes the use of a combination of HTTP [3], TLS [2] This document describes the use of a combination of HTTP [3], TLS [2]
and TCP [16] in Section 8 . and TCP [18] in Section 9.
5.2. Location Request 5.2. Location Request
A location request message is sent from the Device to the LIS when it A location request message is sent from the Device to the LIS when
requires LI. The type of LI that a Device requests is determined by the Device requires its own LI. The type of LI that a Device
the type of LI that is included in the "locationType" element. requests is determined by the type of LI that is included in the
"locationType" element.
The location request is made by sending a document formed of a The location request is made by sending a document formed of a
"locationRequest" element. The LIS uses the source IP address of the "locationRequest" element. The LIS uses the source IP address of the
location request message as the primary source of identity for the location request message as the primary source of identity for the
requesting device or target. It is anticipated that other Device requesting device or target. It is anticipated that other Device
identities may be provided through schema extensions. The successful identities may be provided through schema extensions. The successful
response to a location request message is a document formed of a response to a location request message is a document formed of a
"locationResponse" element, unless the request fails, in which case "locationResponse" element, unless the request fails, in which case
the LIS MUST provide an error indication document. the LIS MUST provide an error indication document.
The LIS MUST ignore any part of a location request message that it The LIS MUST ignore any part of a location request message that it
does not understand. does not understand.
5.3. Location Response 5.3. Location Response
The response to a Location request MUST contain a PIDF-LO and/or The response to a location request MUST contain a PIDF-LO and/or
Location URI(s), depending upon the requested "locationType". location URI(s). The response SHOULD contain location information of
the requested "locationType". The cases whereby a different type of
location information MAY be returned are described in Section 6.2.
5.4. Indicating Errors 5.4. Indicating Errors
In the event of an error, the LIS MUST respond to the Device with an If the LIS is unable to provide location information based on the
error document. The error response applies to all request types and received locationRequest message, it MUST return an error message.
MUST also be sent in response to any unrecognized request. The LIS may return an error message in response to requests for any
"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 the message SHOULD be indicated with an "xml:lang" attribute. of the message SHOULD be indicated with an "xml:lang" attribute.
6. Protocol Parameters 6. Protocol Parameters
This section describes, in detail the parameters that are used for This section describes in detail the parameters that are used for
this protocol. Table 1 lists the top-level components used within this protocol. Table 1 lists the top-level components used within
the protocol and where they are mandatory or optional for each of the the protocol and where they are mandatory or optional for each of the
messages. messages.
+------------------------+----------------+-----------------+-------+ +--------------------------+---------------+----------------+-------+
| Parameter | Location | Location | Error | | Parameter | Location | Location | Error |
| | Request | Response | | | | Request | Response | |
+------------------------+----------------+-----------------+-------+ +--------------------------+---------------+----------------+-------+
| responseTime | o | | | | responseTime | o | | |
| (Section 6.1) | | | | | (Section 6.1) | | | |
| locationType | o | | | | locationType | o | | |
| (Section 6.2) | | | | | (Section 6.2) | | | |
| code (Section 6.3) | | | m | | code (Section 6.3) | | | m |
| message (Section 6.4) | | | o | | message (Section 6.4) | | | o |
| locationURI | | o | | | locationUriSet | | o | |
| (Section 6.5) | | | | | (Section 6.5) | | | |
| PIDF-LO (Section 6.6) | | o | | | Presence (PIDF-LO) | | o | |
+------------------------+----------------+-----------------+-------+ | (Section 6.6) | | | |
+--------------------------+---------------+----------------+-------+
Table 1: Message Parameter Usage Table 1: Message Parameter Usage
6.1. "responseTime" Parameter 6.1. "responseTime" Parameter
The "responseTime" attribute MAY be included in a location request The "responseTime" attribute MAY be included in a location request
message. The "responseTime" attribute includes a time value message. The "responseTime" attribute includes a time value
indicating to the LIS how long the Device is prepared to wait for a indicating to the LIS how long the Device is prepared to wait for a
response and/or a purpose for which the Device needs the location. response and/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
skipping to change at page 11, line 42 skipping to change at page 12, line 14
6.2. "locationType" Parameter 6.2. "locationType" Parameter
The "locationType" element MAY be included in a location request The "locationType" element MAY be included in a location request
message. It contains a list of LI types that are requested by the message. It contains a list of LI types that are requested by the
Device. The following list describes the possible values: Device. The following list describes the possible values:
any: The LIS SHOULD attempt to provide LI in all forms available to any: The LIS SHOULD attempt to provide LI in all forms available to
it. The LIS SHOULD return location information in a form that is it. The LIS SHOULD return location information in a form that is
suited for routing and responding to an emergency call in its suited for routing and responding to an emergency call in its
jurisdiction. The LIS MAY alternatively or additionally return a jurisdiction, specifically by value. The LIS MAY alternatively or
location URI. If the "locationType" element is absent, this value additionally return a location URI. If the "locationType" element
MUST be assumed as the default. is absent, this value MUST be assumed as the default.
geodetic: The LIS SHOULD return a geodetic location for the Target. geodetic: The LIS SHOULD return a geodetic location for the Target.
civic: The LIS SHOULD return a civic address for the Target. Any civic: The LIS SHOULD return a civic address for the Target. Any
type of civic address may be returned. type of civic address may be returned.
locationURI: The LIS SHOULD return a location URI for the Target. locationURI: The LIS SHOULD return a set of location URIs for the
Target.
The LIS SHOULD return the requested location type or types. The LIS The LIS SHOULD return the requested location type or types. The LIS
MAY provide additional location types, or it MAY provide alternative MAY provide additional location types, or it MAY provide alternative
types if the request cannot be satisfied for a requested location types if the request cannot be satisfied for a requested location
type. A location URI provided by the LIS is a reference to the most type. A location URI provided by the LIS is a reference to the most
current available LI, and the Target Device should understand that it current available LI and is not a stable reference to a specific
is not a stable reference to a specific location. The location types location. The location types the LIS returns also depend on the
the LIS returns also depends on the setting of the optional "exact" setting of the optional "exact" attribute, as described in the
attribute, as described in the following section. following section.
The "SHOULD"-strength requirement on this parameter is included to The "SHOULD"-strength requirements on this parameter are included to
allow for soft-failover. This enables a fixed client configuration allow for soft-failover. This enables a fixed client configuration
that prefers a specific location type without causing location that prefers a specific location type without causing location
requests to fail when that location type is unavailable. For requests to fail when that location type is unavailable. For
example, a notebook computer could be configured to retrieve civic example, a notebook computer could be configured to retrieve civic
addresses, which is usually available from typical home or work addresses, which is usually available from typical home or work
situations. However, when using a wireless modem, the LIS might be situations. However, when using a wireless modem, the LIS might be
unable to provide a civic address and thus provides a geodetic unable to provide a civic address and thus provides a geodetic
address. address.
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 location URI when only something beyond what is specified, such as a set of location URIs
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 is used processed transport-level responses. For example where HTTP is used
as the transport, HELD error messages MUST be accompanied by a 200 OK as the transport, HELD error messages MUST be accompanied by a 200 OK
HTTP response. HTTP response.
HELD error responses may be one of the following tokens: The value of the response code MUST be one of the following tokens:
requestError: This code indicates that the request was badly formed requestError: This code indicates that the request was badly formed
in some fashion. in some fashion (other than the XML content).
xmlError: This code indicates that the XML content of the request xmlError: This code indicates that the XML content of the request
was either badly formed or invalid. was either badly formed or invalid.
generalLisError: This code indicates that an unspecified error generalLisError: This code indicates that an unspecified error
occurred at the LIS. occurred at the LIS.
locationUnknown: This code indicates that the LIS could not locationUnknown: This code indicates that the LIS could not
determine the location of the Device. determine the location of the Device.
unsupportedMessage: This code indicates that the request was not unsupportedMessage: This code indicates that an element in the XML
supported or understood by the LIS. document for the request, was not supported or understood by the
LIS.
timeout: This code indicates that the LIS could not satisfy the timeout: This code indicates that the LIS could not satisfy the
request within the time specified in the "responseTime" parameter. request within the time specified in the "responseTime" parameter.
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".
6.4. "message" Parameter 6.4. "message" Parameter
The "error" message MAY include a "message" attribute to convey some The "error" message MAY include a "message" attribute to convey some
additional, human-readable information about the result of the additional, human-readable information about the result of the
request. This message MAY be included in any language, which SHOULD request. This message MAY be included in any language, which SHOULD
be indicated by the "xml:lang", attribute. The default language is be indicated by the "xml:lang", attribute. The default language is
assumed to be English. assumed to be English.
6.5. "locationURI" Parameter 6.5. "locationUriSet" Parameter
The "locationURI" element includes a single Location URI. Each
Location URI that is allocated by the LIS is unique to the device
that is requesting it. A "locationResponse" message MAY contain any
number of "locationURI" elements.
The "locationURI" elements MUST be in the form of a HELD: URI, which
is defined following RFC3986 [20] and the associated URI Guidelines
[22] recommendations, per the following ABNF syntax:
HELD-URI = "held" ":" "//" [ location-id "@" ] host [ ":" port ]
[ path-absolute ] [ uri-extensions ]
location-id = token
uri-extensions = "?" extension *(COMMA extension)
extension = generic-param
generic-param = token [ EQUAL gen-value ]
gen-value = token / host / quoted-string
token = 1*(alphanum / "-" / "." / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" )
The following summarizes the primary elements comprising the HELD-
URI:
host: As defined in RFC3986 [20]
port: As defined in RFC3986 [20]. There is no unique port
associated with location URIs.
path-absolute As defined in RFC3986 [20]
location-id: A token used to identify the locationURI uniquely to
the device that is requesting it.
extension: To allow for future extensions of the information
associated with locationURIs, for use by the LIS.
The HELD: URI is not intended to be human-readable text, therefore it The "locationUriSet" element, received in a "locationResponse"
is encoded entirely in US-ASCII. The following are examples of HELD: message MAY contain any number of "locationURI" elements. It is
URIs: RECOMMENDED that the LIS allocate a Location URI for each scheme that
it supports and that each scheme is present only once. The held: URI
scheme as defined in Section 8 is one possible scheme for the
"locationURI" element. URI schemes and their secure variants, such
as http and https, MUST be regarded as two separate schemes.
held://5432+379xyziou@ls.example.com If a "locationUriSet" element is received in a "locationResponse"
held://thislocation@ls.example.com message, it MUST contain an "expires" attribute, which defines the
held://ls.example.com/thislocation length of time for which the set of "locationURI" elements are valid.
held://9876abcde@ls.example.com/civic
The URIs are case sensitive and exact equivalency is required for 6.5.1. "locationURI" Parameter
HELD-URI comparisons. For example, in the above examples, although
similar in information, the 2nd and 3rd URIs are not considered
equivalent.
A "locationURI" MUST NOT contain any information that could be used The "locationURI" element includes a single Location URI. Each
to identify the Device or Target. It is recommended that a Location URI that is allocated by the LIS is unique to the device
"locationURI" contain a public address for the LIS in the "host" that is requesting it.
component and an anonymous identifier, such as a local identifer or
unlinked pseudonym, in the "location-id" component. The "path-
absolute" component is included to allow a LIS to more readily
dereference the location, depending upon its implementation.
Upon receipt of the "locationURI" in the response, the Device can A "locationURI" SHOULD NOT contain any information that could be used
then deference the location to obtain a PIDF-LO in a subsequent to identify the Device or Target. Thus, it is RECOMMENDED that the
request to a LIS, as described in [24]. The following section "locationURI" element contain a public address for the LIS and an
discusses the "expires" attribute, which defines the length of time anonymous identifier, such as a local identifier or unlinked
for which a specific HELD-URI is valid. pseudonym. Further guidelines to ensure the the privacy and
confidentiality of the information contained in the
"locationResponse" message, including the "locationURI", are included
in Section 10.2.
6.5.1. "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 Location URI is included. The "expires" attribute message when a "locationUriSet" element is included. The "expires"
indicates the time at which the Location URI provided by the LIS will attribute indicates the date/time at which the Location URIs provided
expire. by the LIS will expire.
Responses to Location requests for Location URIs MUST include the Location responses that contain a "locationUriSet" element MUST
expiry time of the Location URI. If a Device dereferences the include the expiry time in the "expires" attribute. If a Device
location URI after the expiry time, it would be possible to get an dereferences a location URI after the expiry time, the dereference
entirely invalid location for that Device. SHOULD fail.
6.6. "pidf-LO" Parameter 6.6. "Presence" Parameter (PIDF-LO)
A "pidf-LO" may be included in the "locationResponse" message when A "presence" parameter may be included in the "locationResponse"
specific locationTypes (e.g., "geodetic" or "civic") are requested or message when specific locationTypes (e.g., "geodetic" or "civic") are
a "locationType" of "any" is requested. The details on the requested or a "locationType" of "any" is requested. The details on
information that may be included in the PIDF-LO MUST follow the the information that may be included in the presence parameter (in
subset of those rules relating to the construction of the the form of a PIDF-LO) MUST follow the subset of those rules relating
"location-info" element in the PIDF-LO Usage Clarification, to the construction of the "location-info" element in the PIDF-LO
Considerations and Recommendations document [10]. The LIS MUST Usage Clarification, Considerations and Recommendations document
follow those rules in generating the PIDF-LO in this case. Per the [12]. The LIS MUST follow those rules in generating the PIDF-LO for
GEOPRIV Location Object format specified in [8], the "entity" element the presence parameter in this case. Per the GEOPRIV Location Object
MUST reflect the Target of the Location Information. In addition, format specified in [10], the "entity" element MUST reflect the
the default values for <retransmission-allowed> and <retention- Target of the Location Information. In addition, the default values
expiry> as specified in [8] MUST be applied. A default value of "no" for <retransmission-allowed> and <retention-expiry> as specified in
SHALL be used for the <retransmission-allowed> element. A default [10] MUST be applied. A default value of "no" SHALL be used for the
value of 24 hours SHALL be used for <retention-expiry> value of any <retransmission-allowed> element. A default value of 24 hours SHALL
generated PIDF-LO documents. A LIS MAY provide a shorter value for be used for <retention-expiry> value of any generated PIDF-LO
<retention-expiry> but MUST NOT provide a value longer than 24 hours. documents. A LIS MAY provide a shorter value for <retention-expiry>
but MUST NOT provide a value longer than 24 hours.
Note that the PIDF-LO is not explicitly shown in the XML schema Note that the presence parameter is not explicitly shown in the XML
Section 7 for a location response message due to XML schema schema Section 7 for a location response message due to XML schema
constraints. constraints.
7. XML Schema 7. XML Schema
This section gives the XML Schema Definition [12] of the This section gives the XML Schema Definition [14] of the
"application/held+xml" format. This is presented as a formal "application/held+xml" format. This is presented as a formal
definition of the "application/held+xml" format. Note that the XML definition of the "application/held+xml" format. Note that the XML
Schema definition is not intended to be used with on-the-fly Schema definition is not intended to be used with on-the-fly
validation of the presence XML document. validation of the presence XML document.
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held" targetNamespace="urn:ietf:params:xml:ns:geopriv:held"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:held="urn:ietf:params:xml:ns:geopriv:held" xmlns:held="urn:ietf:params:xml:ns:geopriv:held"
skipping to change at page 17, line 29 skipping to change at page 17, line 10
<xs:complexType name="locationTypeType"> <xs:complexType name="locationTypeType">
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="held:locationTypeBase"> <xs:extension base="held:locationTypeBase">
<xs:attribute name="exact" type="xs:boolean" <xs:attribute name="exact" type="xs:boolean"
use="optional" default="false"/> use="optional" default="false"/>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
<!-- Response code -->
<xs:simpleType name="codeType">
<xs:restriction base="xs:token">
<xs:enumeration value="requestError"/>
<xs:enumeration value="xmlError"/>
<xs:enumeration value="generalLisError"/>
<xs:enumeration value="locationUnknown"/>
<xs:enumeration value="unsupportedMessage"/>
<xs:enumeration value="timeout"/>
<xs:enumeration value="cannotProvideLiType"/>
</xs:restriction>
</xs:simpleType>
<!-- Message Definitions --> <!-- Message Definitions -->
<xs:complexType name="baseRequestType"> <xs:complexType name="baseRequestType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence/> <xs:sequence/>
<xs:attribute name="responseTime" type="held:responseTimeType" <xs:attribute name="responseTime" type="held:responseTimeType"
use="optional"/> use="optional"/>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:complexType name="errorType"> <xs:complexType name="errorType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence/> <xs:sequence/>
<xs:attribute name="code" type="held:codeType" <xs:attribute name="code" type="xs:token"
use="required"/> use="required"/>
<xs:attribute name="message" type="xs:token" <xs:attribute name="message" type="xs:string"
use="optional"/> use="optional"/>
<xs:attribute ref="xml:lang" use="optional"/> <xs:attribute ref="xml:lang" use="optional"/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:element name="error" type="held:errorType"/> <xs:element name="error" type="held:errorType"/>
<!-- Location Response --> <!-- Location Response -->
<xs:complexType name="locationResponseType"> <xs:complexType name="locationResponseType">
skipping to change at page 19, line 15 skipping to change at page 18, line 28
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:element name="locationRequest" <xs:element name="locationRequest"
type="held:locationRequestType"/> type="held:locationRequestType"/>
</xs:schema> </xs:schema>
8. HTTP Binding 8. HELD: URI Definition
This section defines the schema for a held: URI. This URI schema is
one possible URI scheme for the "locationURI" element, described in
Section 6.5.1, in a HELD "locationResponse " message. In this case,
the held: URI indicates to the Device where to obtain the actual
location information for a Target. In addition, the held: URI can be
the result of the LIS discovery process [16] and indicates to the
Device the LIS from which LI should be requested.
The held: URI is defined using a subset of the URI schema specified
in Appendix A. of RFC3986 [22] and the associated URI Guidelines
[24] per the following ABNF syntax:
HELD-URI = "held" ":" "//" host [":" port] [ path-absolute ] [? query]
The following summarizes the primary elements comprising the HELD-
URI:
host: As defined in RFC3986 [22]
port: As defined in RFC3986 [22]. There is no unique port
associated with location URIs.
path-absolute As defined in RFC3986 [22].
query: As defined in RFC3986 [22]. This allows for additional
information associated with the URIs such as a unique anonymous
identifier for the Device associated with the target location.
The held: URI is not intended to be human-readable text, therefore it
is encoded entirely in US-ASCII. The following are examples of held:
URIs:
held://ls.example.com:49152/thisLocation?token=xyz987
held://ls.example.com/THISLOCATION
held://ls.example.com/THISlocation
held://ls.example.com/civic
Other than the "host" portion, URIs are case sensitive and exact
equivalency is required for HELD-URI comparisons. For example, in
the above examples, although similar in information, the 2nd and 3rd
URIs are not considered equivalent.
In the case where the held: URI is contained in a "locationURI"
element in a HELD locationResponse message, it is important to note
that the URI is only valid for the length of time indicated by the
"expires" attribute.
9. HTTP Binding
This section describes the use of HTTP [3] as a transport mechanism This section describes the use of HTTP [3] as a transport mechanism
for this protocol, which all conforming implementations MUST support. for this protocol, which all conforming implementations MUST support.
The request is carried in the body of an HTTP POST request. The MIME The request is carried in the body of an HTTP POST request. The MIME
type of both request and response bodies should be type of both request and response bodies should be
"application/held+xml". "application/held+xml". This should be reflected in the HTTP
Content-Type and Accept header fields.
The LIS populates the HTTP headers so that they are consistent with The LIS populates the HTTP headers so that they are consistent with
the contents of the message. In particular, the "expires" and cache the contents of the message. In particular, the cache control header
control headers are used to control the caching of any PIDF-LO SHOULD be set to disable the HTTP caching of any PIDF-LO document or
document or Location URIs. The HTTP status code SHOULD indicate a Location URIs. Otherwise, there is the risk of stale locations
2xx series response when a PIDF-LO document or Location URI is and/or the unauthorized disclosure of the LI. This also allows the
included. LIS to control any caching with the "expires" parameter. The HTTP
status code MUST indicate a 2xx series response for all HELD
locationResponse messages.
The use of HTTP also includes a default behaviour, which is triggered The use of HTTP also includes a default behaviour, which is triggered
by a GET request, or a POST with no request body. If either of these by a GET request, or a POST with no request body. If either of these
queries are received, the LIS MUST attempt to provide either a queries are received, the LIS MUST attempt to provide either a
PIDF-LO document or a Location URI, as if the request was a location PIDF-LO document or a Location URI, as if the request was a location
request. request.
The implementation of HTTP as a transport mechanism MUST implement The implementation of HTTP as a transport mechanism MUST implement
TLS as described in [4]. TLS provides message integrity and privacy TLS as described in [4]. TLS provides message integrity and privacy
between Device and LIS. The LIS MUST use the server authentication between Device and LIS. The LIS MUST use the server authentication
method described in [4]; the Device MUST fail a request if server method described in [4]; the Device MUST fail a request if server
authentication fails, except in the event of an emergency. authentication fails, except in the event of an emergency.
9. Security Considerations 10. Security Considerations
The Security Requirements for the Geopriv Location System [Editor's HELD is a location acquisition protocol whereby the a client requests
note: need to add explicit reference to this doc, BUT xml2rfc not its location from a LIS. Specific requirements and security
happy with that doc not having an abbreviated title] identifies the considerations for location acquisition protocols are provided in
threat model for the protocols that interface with a LIS. The threat [13]. An in-depth discussion of the security considerations
model for the HELD protocol assumes that the LIS exists within the applicable to the use of Location URIs and by reference provision of
same administrative domain as the Device. The LIS requires access to LI is included in [17].
network information so that it can determine Location. Therefore,
the LIS can use network information to protect against a number of
the possible attacks.
Specific requirements and security considerations for location By using the HELD protocol, the client and the LIS expose themselves
acquisition protocols are provided in [11] including that the LCP to two types of risk:
MUST NOT assume prior network access authentication, which is
addressed in Section 9.2
An in-depth discussion of the security considerations applicable to Accuracy: Client receives incorrect location information
the use of Location URIs and by-reference provision of LI is included Privacy: An unauthorized entity receives location information
in [15].
9.1. Return Routability These two risks are addressed in the two sections below, followed by
a summary of the security considerations for implementations of the
HELD protocol.
It is RECOMMENDED that Location Information Servers use return 10.1. Accuracy
routability rather than requiring Device authentication. Device
authentication SHOULD NOT be required due to the administrative
challenge of issuing and managing of client credentials, particularly
when networks allow visiting users to attach devices. However, the
LIS MAY require any form of authentication as long as these factors
are considered.
Addressing information used in a request to the LIS is used to The provision of an accurate location to the requestor depends on the
determine the identity of the Device, and to address a response. success of four steps:
This ensures that a Device can only request its own LI.
A temporary spoofing of IP address could mean that a device could 1. The client must determine the proper LIS.
request a Location URI that would result in another Device's 2. The client must connect to the proper LIS.
location. One or more of the follow approaches are RECOMMENDED to 3. The LIS must be able to return the desired location.
4. HELD messages must be transmitted unmodified between the LIS
and the client.
Of these, only the second and the fourth are within the scope of this
document. The first step is based on either manual configuration or
on the LIS discovery defined in [16], in which appropriate security
considerations are already discussed. The third step is dependent on
the specific positioning capabilities of the LIS, and is thus outside
the scope of this document.
10.1.1. Assuring that the proper LIS has been contacted
After the client has initiated a connection to a LIS, it can receive
different levels of assurance that this LIS is the proper LIS based
on whether the proper LIS is identified by a domain name or an IP
address.
When the LIS is identified by a domain name and the HELD transaction
is conducted using TLS [2], the LIS can authenticate itself to the
client using the standard mechanism of presenting a certificate
binding that domain name to the public key used in TLS. Therefore,
any binding of HELD MUST be capable of being transacted over TLS so
that the client can request the above authentication, and a LIS
implementation for a binding MUST include this feature. Note that in
order for the presented certificate to be valid at the client, the
client must be able to validate the certificate; in particular, the
validation path of the certificate must end in one of the client's
trust anchors, even if that trust anchor is the LIS certificate
itself.
When the proper LIS is identified by an IP address, there is a risk
that a malicious LIS could mimic the proper LIS by spoofing that IP
address. If the client deems this risk unacceptable, it is
recommended that the client perform a DNS lookup on the corresponding
domain name in the in-addr.arpa domain to determine a domain name for
the LIS. If a domain name is available, then the standard TLS
authentication mechanism can then be used to authenticate the
identity of the LIS. If not, then the client can obtain no further
assurance about the authenticity of the contacted LIS. In order to
minimize the probability of such spoofing attacks, administrative
domains that offer a LIS SHOULD take measures to prevent IP address
spoofing as described in [5] and [9].
10.1.2. Protecting responses from modification
In order to prevent that response from being modified en route,
messages must be transmitted over an integrity-protected channel.
When the transaction is being conducted over TLS (a required feature
per Section 10.1.1), the channel will be integrity protected by
appropriate ciphersuites. When TLS is not used, this protection will
vary depending on the binding; in most cases, without protection from
TLS, the response will not be protected from modification en route.
10.2. Privacy and Confidentiality
Location information returned by the LIS must be protected from
access by unauthorized parties, whether those parties request the
location from the LIS or intercept it en route. As in section
Section 10.1.2, transactions conducted over TLS with appropriate
ciphersuites are protected from access by unauthorized parties en
route. Conversely, in most cases, when not conducted over TLS, the
response will be accessible while en route from the LIS to the
requestor.
Because HELD is an LCP and identifies clients and targets by 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
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.
Note that this is a necessary, but not sufficient criterion for
authorization. A LIS MAY deny requests according to any local
policy.
A prerequisite for meeting this requirement is that the LIS must have
some assurance of the identity of the client. Since the target of
the returned location is identified by an IP address, simply sending
the response to this IP address will provide sufficient assurance in
many cases. This is the default mechanism in HELD for assuring that
location is given only authorized clients; LIS implementations MUST
support a mode of operation in which this is the only client
authentication.
Using IP return routability as an authenticator means that location
information is vulnerable to exposure through IP address spoofing
attacks. A temporary spoofing of IP address could mean that a device
could request a Location URI that would result in another Device's
location. One or more of the following approaches are RECOMMENDED to
limit this exposure: limit this exposure:
o Location URIs SHOULD have a limited lifetime, as reflected by the o Location URIs SHOULD have a limited lifetime, as reflected by the
value for the expires element (Section 6.5.1). value for the expires element in Section 6.5.2.
o The network SHOULD have mechanisms that protect against IP address o The network SHOULD have mechanisms that protect against IP address
spoofing. spoofing, such as those defined in [9].
o The LIS SHOULD ensure that requests can only originate from within
its administrative domain.
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, then all changes. If the LIS detects a change in the network that results
location URIs MUST be invalidated. in it no longer being able to determine the location of the
Device, then all location URIs for that Device SHOULD be
invalidated.
The above measures are dependent on network configuration and SHOULD The above measures are dependent on network configuration, which
be considered with circumstances in mind. For instance, in a fixed SHOULD be considered. For instance, in a fixed internet access,
internet access, providers may be able to restrict the allocation of providers may be able to restrict the allocation of IP addresses to a
IP addresses to a single physical line, ensuring that spoofing is not single physical line, ensuring that spoofing is not possible; in such
possible; in such an environment, other measures may not be an environment, other measures may not be necessary.
necessary.
9.2. Transaction Layer Security When there are further mechanisms available to authenticate ownership
of the IP address, the LIS SHOULD use them to authenticate that the
client is the owner of the target IP address. For example, in a TLS
transaction, the client could present a certificate with a public key
bound to an IPv6 Cryptographically Generated Address, and the LIS
could verify this binding.
All bindings for this protocol MUST ensure that messages are 10.3. Summary of Security Considerations
adequately protected against eavesdropping and modification.
Bindings MUST also provide a means of authenticating the LIS.
It is RECOMMENDED that all bindings also use TLS [2]. The following summarizes the security considerations for
implementations of the HELD protocol:
For the HTTP binding, TLS MUST be used. TLS provides protection o All bindings MUST provide the following security services:
against eavesdropping and modification. The server authentication * Authentication of a LIS domain name
methods described in HTTP on TLS [4] MUST be used. * Integrity of messages between the client and the LIS
* Confidentiality of messages between the client and the LIS
o It is RECOMMENDED that all bindings use TLS.
o For the HTTP binding, TLS MUST be implemented. The server
authentication methods described in HTTP on TLS [4] MUST be
implemented.
o A LIS implementation for a binding MUST support the specified
security features
o A LIS MUST verify that the requestor is the target of the returned
location.
o A LIS MUST support operation when the only client authentication
available is via IP return routability.
o A LIS SHOULD set expiration times for location URIs it issues.
o Administrative domains SHOULD take measures to prevent IP address
spoofing.
10. Examples 11. Examples
10.1. HTTP Example Messages 11.1. HTTP Example Messages
The examples in this section show a complete HTTP message that The examples in this section show a complete HTTP message that
includes the HELD request or response document. includes the HELD request or response document.
This example shows the most basic request for a LO. This uses the This example shows the most basic request for a LO. This uses the
GET feature described by the HTTP binding. This example assumes that GET feature described by the HTTP binding. This example assumes that
the LIS service exists at the URL "https://lis.example.com/location". the LIS service exists at the URL "https://lis.example.com/location".
GET /location HTTP/1.1 GET /location HTTP/1.1
Host: lis.example.com Host: lis.example.com
skipping to change at page 24, line 24 skipping to change at page 26, line 24
<?xml version="1.0"?> <?xml version="1.0"?>
<error xmlns="urn:ietf:params:xml:ns:geopriv:held" <error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="locationUnknown" code="locationUnknown"
message="Unable to determine location"/> message="Unable to determine location"/>
Note: To focus on important portions of messages, all examples Note: To focus on important portions of messages, all examples
following this note do not show HTTP headers or the XML prologue. following this note do not show HTTP headers or the XML prologue.
In addition, sections of XML not relevant to the example are In addition, sections of XML not relevant to the example are
replaced with comments. replaced with comments.
10.2. Simple Location Request Example 11.2. Simple Location Request Example
The location request shown below doesn't specify any location types The location request shown below doesn't specify any location types
or response time. or response time.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
The response to this location request is a list of Location URIs. The response to this location request is a list of Location URIs.
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"> <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2006-01-01T13:00:00"> <locationUriSet expires="2006-01-01T13:00:00">
<locationURI>held://ls.example.com:9768/357yc6s64ceyoiuy5ax3o <locationURI>held://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI> </locationURI>
<locationURI>held://9769+357yc6s64ceyoiuy5ax3o@ls.example.com <locationURI>sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
</locationURI> </locationURI>
</locationUriSet> </locationUriSet>
</locationResponse> </locationResponse>
An error response to this location request is shown below: An error response to this location request is shown below:
<error xmlns="urn:ietf:params:xml:ns:geopriv:held" <error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="locationUnknown" code="locationUnknown"
message="Location not available"/> message="Location not available"/>
10.3. Location Request Example for Multiple Location Types 11.3. Location Request Example 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"> <locationUriSet expires="2006-01-01T13:00:00">
<locationURI>held://ls.example.com:9768/357yc6s64ceyoiuy5ax3o <locationURI>held://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI> </locationURI>
<locationURI>held://9769+357yc6s64ceyoiuy5ax3o@ls.example.com: <locationURI>sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
</locationURI> </locationURI>
</locationUriSet> </locationUriSet>
<presence xmlns="urn:ietf:params:xml:ns:pidf:geopriv10" <presence xmlns="urn:ietf:params:xml:ns:pidf:geopriv10"
entity="pres:ae3be8585902e2253ce2@10.102.23.9"> entity="pres:ae3be8585902e2253ce2@10.102.23.9">
<tuple id="lisLocation"> <tuple id="lisLocation">
<status> <status>
<geopriv> <geopriv>
<location-info> <location-info>
<gs:Circle <gs:Circle
xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gs="http://www.opengis.net/pidflo/1.0"
skipping to change at page 26, line 26 skipping to change at page 28, line 35
</retention-expiry> </retention-expiry>
</usage-rules> </usage-rules>
<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 12. IANA Considerations
This document requires several IANA registrations detailed in the This document requires several IANA registrations detailed in the
following sections. following sections.
11.1. URN Sub-Namespace Registration 12.1. URN Sub-Namespace Registration for
This specification registers two new XML namespaces, as per the
guidelines in [6].
11.1.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". "urn:ietf:params:xml:ns:geopriv:held", per the guidelines in [7].
URI: urn:ietf:params:xml:ns:geopriv:held URI: urn:ietf:params:xml:ns:geopriv:held
Registrant Contact: IETF, GEOPRIV working group, Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com). (geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head> <head>
<title>HELD Messages</title> <title>HELD Messages</title>
</head> </head>
skipping to change at page 27, line 23 skipping to change at page 29, line 25
<body> <body>
<h1>Namespace for HELD Messages</h1> <h1>Namespace for HELD Messages</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held</h2> <h2>urn:ietf:params:xml:ns:geopriv:held</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]] with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p> <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
11.1.2. URN Sub-Namespace Registration for 12.2. XML Schema Registration
urn:ietf:params:xml:ns:geopriv:held:http
TThis section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:held:http."
URI: urn:ietf:params:xml:ns:geopriv:held:http
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>HELD HTTP Binding WS</title>
</head>
<body>
<h1>Namespace for HELD HTTP Binding WS</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:http</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body>
</html>
END
11.2. XML Schema Registration This section registers an XML schema as per the guidelines in [7].
This section registers an XML schema as per the guidelines in [6].
URI: urn:ietf:params:xml:schema:geopriv:held URI: urn:ietf:params:xml:schema:geopriv:held
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Mary Barnes (mary.barnes@nortel.com). Mary Barnes (mary.barnes@nortel.com).
Schema: The XML for this schema can be found as the entirety of Schema: The XML for this schema can be found as the entirety of
Section 7 of this document. Section 7 of this document.
11.3. MIME Media Type Registration for 'application/held+xml' 12.3. MIME Media Type Registration for 'application/held+xml'
This section registers the "application/held+xml" MIME type. This section registers the "application/held+xml" MIME type.
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type application/held+xml Subject: Registration of MIME media type application/held+xml
MIME media type name: application MIME media type name: application
MIME subtype name: held+xml MIME subtype name: held+xml
Required parameters: (none) Required parameters: (none)
Optional parameters: charset Optional parameters: charset
Indicates the character encoding of enclosed XML. Default is Indicates the character encoding of enclosed XML. Default is
UTF-8. UTF-8.
Encoding considerations: Uses XML, which can employ 8-bit Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See RFC characters, depending on the character encoding used. See RFC
skipping to change at page 28, line 27 skipping to change at page 29, line 49
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type application/held+xml Subject: Registration of MIME media type application/held+xml
MIME media type name: application MIME media type name: application
MIME subtype name: held+xml MIME subtype name: held+xml
Required parameters: (none) Required parameters: (none)
Optional parameters: charset Optional parameters: charset
Indicates the character encoding of enclosed XML. Default is Indicates the character encoding of enclosed XML. Default is
UTF-8. UTF-8.
Encoding considerations: Uses XML, which can employ 8-bit Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See RFC characters, depending on the character encoding used. See RFC
3023 [18], section 3.2. 3023 [20], section 3.2.
Security considerations: This content type is designed to carry Security considerations: This content type is designed to carry
protocol data related to the location of an entity, which could protocol data related to the location of an entity, which could
include information that is considered private. Appropriate include information that is considered private. Appropriate
precautions should be taken to limit disclosure of this precautions should be taken to limit disclosure of this
information. information.
Interoperability considerations: This content type provides a basis Interoperability considerations: This content type provides a basis
for a protocol for a protocol
Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number for this specification.]] replace XXXX with the RFC number for this specification.]]
Applications which use this media type: Location information Applications which use this media type: Location information
providers and consumers. providers and consumers.
Additional Information: Magic Number(s): (none) Additional Information: Magic Number(s): (none)
File extension(s): .xml File extension(s): .xml
Macintosh File Type Code(s): (none) Macintosh File Type Code(s): (none)
Person & email address to contact for further information: Mary Person & email address to contact for further information: Mary
Barnes <mary.barnes@nortel.com> Barnes <mary.barnes@nortel.com>
Intended usage: LIMITED USE Intended usage: LIMITED USE
Author/Change controller: The IETF Author/Change controller: The IETF
Other information: This media type is a specialization of Other information: This media type is a specialization of
application/xml [18], and many of the considerations described application/xml [20], and many of the considerations described
there also apply to application/held+xml. there also apply to application/held+xml.
11.4. Error code Registry 12.4. Error code Registry
This document requests that the IANA create a new registry the HELD This document requests that the IANA create a new registry for the
protocol including an initial registry for error codes. The error HELD protocol including an initial registry for error codes. The
codes are included in HELD error messages as described in Section 6.3 error codes are included in HELD error messages as described in
and defined in the schema in the 'codeType' token in the XML schema Section 6.3 and defined in the schema in the 'codeType' token in the
in (Section 7) XML schema in (Section 7)
The following summarizes the requested registry: The following summarizes the requested registry:
Related Registry: Geopriv HELD Registries, Error codes for HELD Related Registry: Geopriv HELD Registries, Error codes for HELD
Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.] with the RFC number for this specification.]
Registration/Assignment Procedures: New error codes are allocated on Registration/Assignment Procedures: New error codes are allocated on
a first-come/first-serve basis with specification recommended. a first-come/first-serve basis with specification required.
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Mary Barnes (mary.barnes@nortel.com). Mary Barnes (mary.barnes@nortel.com).
This section pre-registers the following seven initial error codes as This section pre-registers the following seven initial error codes as
described above in Section 6.3: described above in Section 6.3:
requestError: This code indicates that the request was badly formed requestError: This code indicates that the request was badly formed
in some fashion. in some fashion.
xmlError: This code indicates that the XML content of the request xmlError: This code indicates that the XML content of the request
was either badly formed or invalid. was either badly formed or invalid.
generalLisError: This code indicates that an unspecified error generalLisError: This code indicates that an unspecified error
occurred at the LIS. occurred at the LIS.
locationUnknown: This code indicates that the LIS could not locationUnknown: This code indicates that the LIS could not
determine the location of the Device. determine the location of the Device.
unsupportedMessage: This code indicates that the request was not unsupportedMessage: This code indicates that the request was not
supported or understood by the LIS. supported or understood by the LIS.
timeout: This code indicates that the LIS could not satisfy the timeout: This code indicates that the LIS could not satisfy the
request within the time specified in the "responseTime" parameter. request within the time specified in the "responseTime" parameter.
skipping to change at page 29, line 43 skipping to change at page 31, line 20
determine the location of the Device. determine the location of the Device.
unsupportedMessage: This code indicates that the request was not unsupportedMessage: This code indicates that the request was not
supported or understood by the LIS. supported or understood by the LIS.
timeout: This code indicates that the LIS could not satisfy the timeout: This code indicates that the LIS could not satisfy the
request within the time specified in the "responseTime" parameter. request within the time specified in the "responseTime" parameter.
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".
11.5. URI Registration 12.5. URI Registration
The following summarizes the information necessary to register the The following summarizes the information necessary to register the
held: URI. [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the held: URI. [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the
RFC number for this specification in the following list.] RFC number for this specification in the following list.]
URI Scheme Name: held URI Scheme Name: held
Status: permanent Status: permanent
URI Scheme syntax: See section URI Scheme syntax: See section
URI Scheme Semantics: The held: URI is intended to be used as a URI Scheme Semantics: The held: URI is intended to be used as a
reference to a location object. Further detail is provided in reference to a location object or a location information server.
Section 6.5 of RFCXXXX. Further detail is provided in Section 8 of RFCXXXX.
Encoding Considerations: The HELD: URI is not intended to be human- Encoding Considerations: The HELD: URI is not intended to be human-
readable text, therefore they are encoded entirely in US-ASCII. readable text, therefore they are encoded entirely in US-ASCII.
Applications/protocols that use this URI scheme: The HELD protocol Applications/protocols that use this URI scheme: The HELD protocol
described in RFCXXXX and the GEOPRIV Location De-reference described in RFCXXXX, the GEOPRIV Location De-reference Protocol
Protocol [24] [26] and GEOPRIV Location Information Server Discovery [16].
Interoperability considerations: This URI is intended for use as a Interoperability considerations: This URI may be used as a parameter
parameter for the HELD protocol and this URI is also used as an for the HELD protocol in the locationResponse message. This URI
input parameter for the GEOPRIV Location De-reference Protocol is also used as an input parameter for the GEOPRIV Location De-
[24]. Refer to Section 6.5 in RFXXXX for further detail, in reference Protocol [26]. This URI may also be a result of the
particular on the lack of permanence of a specific HELD: URI and GEOPRIV Location Information Server Discovery [16] and thus used
thus the importance of using these URIs only within the specific as the target for the HELD protocol request messages. Refer to
contexts outlined in the references. Section 8 in RFXXXX for further detail and a particular example on
Security considerations: Section 9 in RFXXXX addresses the necessary the lack of permanence of a specific HELD: URI and thus the
security associated with the transport of location information importance of using these URIs only within the specific contexts
between a Device and the LIS to ensure the privacy and integrity outlined in the references.
of the held: URI. The schema for the held: URI allows for a Security considerations: Section 10 in RFXXXX addresses the
random identifier in the form of a token in the URI Section 6.5 in necessary security associated with the transport of location
RFCXXXX also recommends that the token be allocated such that it information between a Device and the LIS to ensure the privacy and
does not reveal any detail at all about the content of the PIDF-LO integrity of the held: URI. Section 6.5.1 in RFCXXXX also
that it may indirectly reference. recommends that the URI be allocated such that it does not reveal
any detail at all about the content of the PIDF-LO that it may
indirectly reference.
Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary
Barnes (mary.barnes@nortel.com). Barnes (mary.barnes@nortel.com).
Author/Change controller: This scheme is registered under the IETF Author/Change controller: This scheme is registered under the IETF
tree. As such, IETF maintains change control. tree. As such, IETF maintains change control.
References: RFC XXXX, GEOPRIV Location De-reference Protocol [24] References: RFC XXXX, GEOPRIV Location De-reference Protocol [26],
GEOPRIV Location Information Server Discovery [16]
12. Contributors 13. Contributors
James Winterbottom, Martin Thomson and Barbara Stark are the authors James Winterbottom, Martin Thomson and Barbara Stark are the authors
of the original document, from which this WG document was derived. of the original document, from which this WG document was derived.
Their contact information is included in the Author's address Their contact information is included in the Author's address
section. In addition, they also contributed to the WG document, section. In addition, they also contributed to the WG document,
including the XML schema. including the XML schema.
13. Acknowledgements 14. Acknowledgements
The author/contributors would like to thank the participants in the The author/contributors would like to thank the participants in the
GEOPRIV WG and the following people for their constructive input and GEOPRIV WG and the following people for their constructive input and
feedback on this document (in alphabetical order): Nadine Abbott, feedback on this document (in alphabetical order): Nadine Abbott,
Eric Arolick, Richard Barnes, Peter Blatherwick, Guy Caron, Martin Eric Arolick, Richard Barnes (in particular the security section),
Dawson, Lisa Dusseault, Jerome Grenier, Ted Hardie, Neil Justusson, Peter Blatherwick, Guy Caron, Martin Dawson, Lisa Dusseault, Jerome
Tat Lam, Marc Linsner, Patti McCalmont, Roger Marshall, Perry Grenier, Ted Hardie, Neil Justusson, Tat Lam, Marc Linsner, Patti
Prozeniuk, Carl Reed, Brian Rosen, John Schnizlein, Shida Schubert, McCalmont, Roger Marshall, Perry Prozeniuk, Carl Reed, Brian Rosen,
Henning Schulzrinne, Ed Shrum, Doug Stuard and Hannes Tschofenig. John Schnizlein, Shida Schubert, Henning Schulzrinne, Ed Shrum, Doug
Stuard and Hannes Tschofenig.
14. Changes since last Version 15. Changes since last Version
NOTE TO THE RFC-Editor: Please remove this section prior to NOTE TO THE RFC-Editor: Please remove this section prior to
publication as an RFC. publication as an RFC.
Changes from WG 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: Changes from WG 03 to 04:
1) Terminology: clarified in terminology section that "attribute" and 1) Terminology: clarified in terminology section that "attribute" and
"element" are used in the strict XML sense and "parameter" is used as "element" are used in the strict XML sense and "parameter" is used as
a general protocol term Replaced term "HTTP delivery" with "HTTP a general protocol term Replaced term "HTTP delivery" with "HTTP
transport". Still have two terms "HTTP transport" and "HTTP transport". Still have two terms "HTTP transport" and "HTTP
binding", but those are consistent with general uses of HTTP. binding", but those are consistent with general uses of HTTP.
2) Editorial changes and clarifications: per Roger Marshall's and 2) Editorial changes and clarifications: per Roger Marshall's and
Eric Arolick's comments and subsequent WG mailing list discussion. Eric Arolick's comments and subsequent WG mailing list discussion.
skipping to change at page 33, line 44 skipping to change at page 36, line 5
8) Updated Location Response (section 6.3) to remove reference to 8) Updated Location Response (section 6.3) to remove reference to
context and discuss the used of a local identifier or unlinked context and discuss the used of a local identifier or unlinked
pseudonym in providing privacy/security. pseudonym in providing privacy/security.
9) Clarified that the source IP address in the request is used as the 9) Clarified that the source IP address in the request is used as the
identifier for the target/device for the HELD protocol as defined in identifier for the target/device for the HELD protocol as defined in
this document. this document.
10) Miscellaneous editorial clarifications. 10) Miscellaneous editorial clarifications.
15. References 16. References
15.1. Normative References 16.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999. HTTP/1.1", RFC 2616, June 1999.
[4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[5] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup [5] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[6] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
Language) XML-Signature Syntax and Processing", RFC 3275, Language) XML-Signature Syntax and Processing", RFC 3275,
March 2002. March 2002.
[6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[7] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. [8] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
Polk, "Geopriv Requirements", RFC 3693, February 2004. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[8] Peterson, J., "A Presence-based GEOPRIV Location Object [9] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[10] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[9] Thomson, M. and J. Winterbottom, "Revised Civic Location Format [11] Thomson, M. and J. Winterbottom, "Revised Civic Location Format
for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-07 (work in for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-07 (work in
progress), December 2007. progress), December 2007.
[10] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [12] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations and PIDF-LO Usage Clarification, Considerations and
Recommendations", draft-ietf-geopriv-pdif-lo-profile-10 (work Recommendations", draft-ietf-geopriv-pdif-lo-profile-11 (work
in progress), October 2007. in progress), February 2008.
[11] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location [13] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location
Configuration Protocol; Problem Statement and Requirements", Configuration Protocol; Problem Statement and Requirements",
draft-ietf-geopriv-l7-lcp-ps-06 (work in progress), draft-ietf-geopriv-l7-lcp-ps-06 (work in progress),
November 2007. November 2007.
[12] Thompson, H., Maloney, M., Beech, D., and N. Mendelsohn, "XML [14] Thompson, H., Maloney, M., Beech, D., and N. Mendelsohn, "XML
Schema Part 1: Structures Second Edition", World Wide Web Schema Part 1: Structures Second Edition", World Wide Web
Consortium Recommendation REC-xmlschema-1-20041028, 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>.
[13] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second [15] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second
Edition", World Wide Web Consortium Recommendation REC- Edition", World Wide Web Consortium Recommendation REC-
xmlschema-2-20041028, October 2004, 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>.
[14] Thomson, M. and J. Winterbottom, "Discovering the Local [16] Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", Location Information Server (LIS)",
draft-thomson-geopriv-lis-discovery-03 (work in progress), draft-ietf-geopriv-lis-discovery-00 (work in progress),
September 2007. December 2007.
[15] Marshall, R., "Requirements for a Location-by-Reference [17] Marshall, R., "Requirements for a Location-by-Reference
Mechanism", draft-ietf-geopriv-lbyr-requirements-01 (work in Mechanism", draft-ietf-geopriv-lbyr-requirements-01 (work in
progress), October 2007. progress), October 2007.
15.2. Informative References 16.2. Informative References
[16] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [18] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
[17] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence [19] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
and Instant Messaging", RFC 2778, February 2000. and Instant Messaging", RFC 2778, February 2000.
[18] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", [20] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001. RFC 3023, January 2001.
[19] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [21] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[20] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [22] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005. January 2005.
[21] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host [23] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004. Configuration Information", RFC 3825, July 2004.
[22] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and [24] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 115, Registration Procedures for New URI Schemes", BCP 115,
RFC 4395, February 2006. RFC 4395, February 2006.
[23] Polk, J. and B. Rosen, "Location Conveyance for the Session [25] Polk, J. and B. Rosen, "Location Conveyance for the Session
Initiation Protocol", draft-ietf-sip-location-conveyance-09 Initiation Protocol", draft-ietf-sip-location-conveyance-09
(work in progress), November 2007. (work in progress), November 2007.
[24] Winterbottom, J., Tschofenig, H., Schulzrinne, H., Thomson, M., [26] Winterbottom, J., Tschofenig, H., Schulzrinne, H., Thomson, M.,
and M. Dawson, "An HTTPS Location Dereferencing Protocol Using and M. Dawson, "An HTTPS Location Dereferencing Protocol Using
HELD", draft-winterbottom-geopriv-deref-protocol-00 (work in HELD", draft-winterbottom-geopriv-deref-protocol-00 (work in
progress), November 2007. progress), November 2007.
[25] TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media [27] TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
Endpoint Discovery". Endpoint Discovery".
Appendix A. HELD Compliance to IETF LCP requirements Appendix A. HELD Compliance to IETF LCP requirements
This appendix describes HELD's compliance to the requirements This appendix describes HELD's compliance to the requirements
specified in the [11]. specified in the [13].
A.1. L7-1: Identifier Choice A.1. L7-1: Identifier Choice
"The L7 LCP MUST be able to carry different identifiers or MUST "The L7 LCP MUST be able to carry different identifiers or MUST
define an identifier that is mandatory to implement. Regarding the define an identifier that is mandatory to implement. Regarding the
latter aspect, such an identifier is only appropriate if it is from latter aspect, such an identifier is only appropriate if it is from
the same realm as the one for which the location information service the same realm as the one for which the location information service
maintains identifier to location mapping." maintains identifier to location mapping."
COMPLY COMPLY
skipping to change at page 37, line 17 skipping to change at page 39, line 29
"The design of the L7 LCP MUST NOT assume a business or trust "The design of the L7 LCP MUST NOT assume a business or trust
relationship between the Application Service Provider (ASP) and the relationship between the Application Service Provider (ASP) and the
Access Network Provider. Requirements for resolving a reference to Access Network Provider. Requirements for resolving a reference to
location information are not discussed in this document." location information are not discussed in this document."
COMPLY COMPLY
HELD describes a location acquisition protocol and has no HELD describes a location acquisition protocol and has no
dependencies on the business or trust relationship between the ASP dependencies on the business or trust relationship between the ASP
and the Access Network Provider. Location acquisition using HELD is and the Access Network Provider. Location acquisition using HELD is
subject to the restrictions described in Section 9. subject to the restrictions described in Section 10.
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship A.4. L7-4: Layer 2 and Layer 3 Provider Relationship
"The design of the GEOPRIV Layer 7 Location Configuration Protocol "The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST assume that there is a trust and business relationship between MUST assume that there is a trust and business relationship between
the L2 and the L3 provider. The L3 provider operates the LIS and the L2 and the L3 provider. The L3 provider operates the LIS and
needs to obtain location information from the L2 provider since this needs to obtain location information from the L2 provider since this
one is closest to the end host. If the L2 and L3 provider for the one is closest to the end host. If the L2 and L3 provider for the
same host are different entities, they cooperate for the purposes same host are different entities, they cooperate for the purposes
needed to determine end system locations." needed to determine end system locations."
skipping to change at page 39, line 12 skipping to change at page 41, line 25
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 [14]. HELD uses the discovery mechanism in [16].
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 ". [10] rules outlined in ". [12]
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 [10]. by the LIS MUST conform to [12].
Authors' Addresses Authors' Addresses
Mary Barnes (editor) Mary Barnes (editor)
Nortel Nortel
2201 Lakeside Blvd 2201 Lakeside Blvd
Richardson, TX Richardson, TX
Email: mary.barnes@nortel.com Email: mary.barnes@nortel.com
James Winterbottom James Winterbottom
Andrew Andrew
PO Box U40 PO Box U40
Wollongong University Campus, NSW 2500 Wollongong University Campus, NSW 2500
AU AU
Phone: +61 2 4221 2938 Phone: +61 2 4221 2938
Email: james.winterbottom@andrew.com Email: james.winterbottom@andrew.com
URI: http://www.andrew.com/ URI: http://www.andrew.com/
Martin Thomson Martin Thomson
Andrew Andrew
PO Box U40 PO Box U40
Wollongong University Campus, NSW 2500 Wollongong University Campus, NSW 2500
AU AU
Phone: +61 2 4221 2915 Phone: +61 2 4221 2915
Email: martin.thomson@andrew.com Email: martin.thomson@andrew.com
URI: http://www.andrew.com/ URI: http://www.andrew.com/
 End of changes. 157 change blocks. 
421 lines changed or deleted 550 lines changed or added

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