draft-ietf-geopriv-http-location-delivery-09.txt   draft-ietf-geopriv-http-location-delivery-10.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: March 12, 2009 Expires: May 2, 2009
September 8, 2008 October 29, 2008
HTTP Enabled Location Delivery (HELD) HTTP Enabled Location Delivery (HELD)
draft-ietf-geopriv-http-location-delivery-09.txt draft-ietf-geopriv-http-location-delivery-10.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 March 12, 2009. This Internet-Draft will expire on May 2, 2009.
Abstract Abstract
A Layer 7 Location Configuration Protocol (L7 LCP) is described that A Layer 7 Location Configuration Protocol (L7 LCP) is described that
is used for retrieving location information from a server within an is used for retrieving location information from a server within an
access network. The protocol includes options for retrieving access network. The protocol includes options for retrieving
location information in two forms: by value and by reference. The location information in two forms: by value and by reference. The
protocol is an extensible application-layer protocol that is protocol is an extensible application-layer protocol that is
independent of session-layer. This document describes the use of independent of session-layer. This document describes the use of
HyperText Transfer Protocol (HTTP) and HTTP over Transport Layer HyperText Transfer Protocol (HTTP) and HTTP over Transport Layer
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 7 4.1. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 7
4.1.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 7 4.1.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 7
4.1.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 8 4.1.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 8
4.2. Location by Value . . . . . . . . . . . . . . . . . . . . 8 4.2. Location by Value . . . . . . . . . . . . . . . . . . . . 8
4.3. Location by Reference . . . . . . . . . . . . . . . . . . 8 4.3. Location by Reference . . . . . . . . . . . . . . . . . . 9
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9
5.1. Delivery Protocol . . . . . . . . . . . . . . . . . . . . 10 5.1. Delivery Protocol . . . . . . . . . . . . . . . . . . . . 10
5.2. Location Request . . . . . . . . . . . . . . . . . . . . . 10 5.2. Location Request . . . . . . . . . . . . . . . . . . . . . 10
5.3. Location Response . . . . . . . . . . . . . . . . . . . . 10 5.3. Location Response . . . . . . . . . . . . . . . . . . . . 10
5.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 10 5.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 11
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11
6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11 6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 12
6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12 6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12
6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 14 6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 14
6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 14 6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 14
6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 15 6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 15
6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 15 6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 15
6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 15 6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 15
6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 16 6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 16
6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 16 6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 16
7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. HTTP/HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . 20 8. HTTP/HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9.1. Assuring that the proper LIS has been contacted . . . . . 21 9.1. Assuring that the proper LIS has been contacted . . . . . 22
9.2. Protecting responses from modification . . . . . . . . . . 22 9.2. Protecting responses from modification . . . . . . . . . . 22
9.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 22 9.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 22
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. HTTPS Example Messages . . . . . . . . . . . . . . . . . . 23 10.1. HTTPS Example Messages . . . . . . . . . . . . . . . . . . 24
10.2. Simple Location Request Example . . . . . . . . . . . . . 26 10.2. Simple Location Request Example . . . . . . . . . . . . . 26
10.3. Location Request Example for Multiple Location Types . . . 27 10.3. Location Request Example for Multiple Location Types . . . 27
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
11.1. URN Sub-Namespace Registration for 11.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 28 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 28
11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 29 11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 29
11.3. MIME Media Type Registration for 'application/held+xml' . 29 11.3. MIME Media Type Registration for 'application/held+xml' . 29
11.4. Error code Registry . . . . . . . . . . . . . . . . . . . 30 11.4. Error code Registry . . . . . . . . . . . . . . . . . . . 30
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
14. Changes since last Version . . . . . . . . . . . . . . . . . . 32 14. Changes since last Version . . . . . . . . . . . . . . . . . . 32
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
15.1. Normative References . . . . . . . . . . . . . . . . . . . 37 15.1. Normative References . . . . . . . . . . . . . . . . . . . 37
15.2. Informative References . . . . . . . . . . . . . . . . . . 38 15.2. Informative References . . . . . . . . . . . . . . . . . . 38
Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 39 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 39
A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 39 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 39
A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 39 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 40
A.3. L7-3: ASP and Access Network Provider Relationship . . . . 40 A.3. L7-3: ASP and Access Network Provider Relationship . . . . 40
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 40 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 41
A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 41 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 41
A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 41 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 41
A.7. L7-7: Network Access Authentication . . . . . . . . . . . 41 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 42
A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 42 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 42
A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 42 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 42
A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 42 A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . . . . 44 Intellectual Property and Copyright Statements . . . . . . . . . . 45
1. Introduction 1. Introduction
The location of a Device is information that is useful for a number The location of a Device is information that is useful for a number
of applications. The L7 Location Configuration Protocol (LCP) of applications. The L7 Location Configuration Protocol (LCP)
problem statement and requirements document problem statement and requirements document
[I-D.ietf-geopriv-l7-lcp-ps] provides some scenarios in which a [I-D.ietf-geopriv-l7-lcp-ps] provides some scenarios in which a
Device might rely on its access network to provide location Device might rely on its access network to provide location
information. The Location Information Server (LIS) service applies information. The Location Information Server (LIS) service applies
to access networks employing both wired technology (e.g. DSL, Cable) to access networks employing both wired technology (e.g. DSL, Cable)
skipping to change at page 7, line 40 skipping to change at page 7, line 40
of the NAT, since the covered geographical area is small. of the NAT, since the covered geographical area is small.
On the other hand, if there is a VPN between the Device and the LIS, On the other hand, if there is a VPN between the Device and the LIS,
for example for a teleworker, then the IP address seen by a LIS for example for a teleworker, then the IP address seen by a LIS
inside the enterprise network might not be the right address to inside the enterprise network might not be the right address to
identify the location of the Device. Section 4.1.2 provides identify the location of the Device. Section 4.1.2 provides
recommendations to address this issue. recommendations to address this issue.
4.1.1. Devices and VPNs 4.1.1. Devices and VPNs
To minimize the impact of VPNs, Devices should perform their HELD To minimize the impact of connections or tunnels setup for security
query prior to establishing a VPN tunnel. It is RECOMMENDED that purposes or to traverse middleboxes, Devices that connect to servers
discovery [I-D.ietf-geopriv-lis-discovery] and an initial query are such as VPN servers, SOCKS servers and HTTP proxy servers should
performed before establishing the VPN. If a Device performs the HELD perform their HELD query to the LIS prior to establishing a
query after establishing the VPN tunnel the Device may receive connection to other servers. It is RECOMMENDED that discovery
inaccurate location information. [I-D.ietf-geopriv-lis-discovery] and an initial query are performed
before establishing any connections to other servers. If a Device
performs the HELD query after establishing a connection to another
server, the Device may receive inaccurate location information.
Devices that establish VPN connections for use by other devices Devices that establish VPN connections for use by other devices
inside a LAN or other closed network could serve as a LIS, that inside a LAN or other closed network could serve as a LIS, that
implements the HELD protocol, for those other Devices. Devices implements the HELD protocol, for those other Devices. Devices
within the closed network are not necessarily able to detect the within the closed network are not necessarily able to detect the
presence of the VPN and rely on the VPN device. To this end, a VPN presence of the VPN. In this case, a VPN device should provide the
device should provide the address of the LIS server it provides, in address of the LIS server it provides, in response to discovery
response to discovery queries, rather than passing such queries queries, rather than passing such queries through the VPN tunnel.
through the VPN tunnel. Otherwise, the other devices would be Otherwise, the other devices would be totally unaware that they could
totally unaware that they could receive inaccurate location receive inaccurate location information.
information.
It could also be useful for a VPN device to serve as a LIS for other It could also be useful for a VPN device to serve as a LIS for other
location configuration options such as Dynamic Host Configuration location configuration options such as Dynamic Host Configuration
Protocol (DHCP)[RFC3825] or Link Layer Discovery Protocol - Media Protocol (DHCP)[RFC3825] or Link Layer Discovery Protocol - Media
Endpoint Discovery (LLDP-MED) [LLDP-MED]. For this case, the VPN Endpoint Discovery (LLDP-MED) [LLDP-MED]. For this case, the VPN
device that serves as a LIS may first acquire its own location using device that serves as a LIS may first acquire its own location using
HELD. HELD.
4.1.2. LIS Handling of NATs and VPNs 4.1.2. LIS Handling of NATs and VPNs
skipping to change at page 12, line 47 skipping to change at page 13, line 5
locationURI: The LIS SHOULD return a set of location URIs for the locationURI: The LIS SHOULD return a set of location URIs for the
Target. Target.
The LIS SHOULD return the requested location type or types. The The LIS SHOULD return the requested location type or types. The
location types the LIS returns also depend on the setting of the location types the LIS returns also depend on the setting of the
optional "exact" attribute. If the "exact" attribute is set to optional "exact" attribute. If the "exact" attribute is set to
"true" then the LIS MUST return either the requested location type or "true" then the LIS MUST return either the requested location type or
provide an error response. The "exact" attribute does not apply (is provide an error response. The "exact" attribute does not apply (is
ignored) for a request for a location type of "any". Further detail ignored) for a request for a location type of "any". Further detail
of the "exact" attribute processing is provided in the following of the "exact" attribute processing is provided in the following
section Section 6.2.1. Section 6.2.1.
In the case of a request for specific locationType(s) and the "exact" In the case of a request for specific locationType(s) and the "exact"
attribute is false, the LIS MAY provide additional location types, or attribute is false, the LIS MAY provide additional location types, or
it MAY provide alternative types if the request cannot be satisfied it MAY provide alternative types if the request cannot be satisfied
for a requested location type. The "SHOULD"-strength requirements on for a requested location type. The "SHOULD"-strength requirements on
this parameter for specific location types are included to allow for this parameter for specific location types are included to allow for
soft-failover. This enables a fixed client configuration that soft-failover. This enables a fixed client configuration that
prefers a specific location type without causing location requests to prefers a specific location type without causing location requests to
fail when that location type is unavailable. For example, a notebook fail when that location type is unavailable. For example, a notebook
computer could be configured to retrieve civic addresses, which is computer could be configured to retrieve civic addresses, which is
skipping to change at page 16, line 5 skipping to change at page 16, line 16
device that is requesting it. At the time the location URI is device that is requesting it. At the time the location URI is
provided in the response, there is no binding to a specific location provided in the response, there is no binding to a specific location
type and the location URI is totally independent of the specific type type and the location URI is totally independent of the specific type
of location it might reference. The specific location type is of location it might reference. The specific location type is
determined at the time of dereference. determined at the time of dereference.
A "locationURI" SHOULD NOT contain any information that could be used A "locationURI" SHOULD NOT contain any information that could be used
to identify the Device or Target. Thus, it is RECOMMENDED that the to identify the Device or Target. Thus, it is RECOMMENDED that the
"locationURI" element contain a public address for the LIS and an "locationURI" element contain a public address for the LIS and an
anonymous identifier, such as a local identifier or unlinked anonymous identifier, such as a local identifier or unlinked
pseudonym. Further guidelines to ensure the the privacy and pseudonym. Further guidelines to ensure the privacy and
confidentiality of the information contained in the confidentiality of the information contained in the
"locationResponse" message, including the "locationURI", are included "locationResponse" message, including the "locationURI", are included
in Section 9.3. in Section 9.3.
6.5.2. "expires" Parameter 6.5.2. "expires" Parameter
The "expires" attribute is only included in a "locationResponse" The "expires" attribute is only included in a "locationResponse"
message when a "locationUriSet" element is included. The "expires" message when a "locationUriSet" element is included. The "expires"
attribute indicates the date/time at which the Location URIs provided attribute indicates the date/time at which the Location URIs provided
by the LIS will expire. The "expires" attribute does not define the by the LIS will expire. The "expires" attribute does not define the
skipping to change at page 16, line 49 skipping to change at page 17, line 12
separately. Thus, the "##other" namespace serves as a placeholder separately. Thus, the "##other" namespace serves as a placeholder
for the presence parameter in the schema. for the presence parameter in the schema.
7. XML Schema 7. XML Schema
This section gives the XML Schema Definition This section gives the XML Schema Definition
[W3C.REC-xmlschema-1-20041028], [W3C.REC-xmlschema-2-20041028] of the [W3C.REC-xmlschema-1-20041028], [W3C.REC-xmlschema-2-20041028] of the
"application/held+xml" format. This is presented as a formal "application/held+xml" format. This is presented as a formal
definition of the "application/held+xml" format. Note that the XML definition of the "application/held+xml" format. Note that the XML
Schema definition is not intended to be used with on-the-fly Schema definition is not intended to be used with on-the-fly
validation of the presence XML document. validation of the presence XML document. Whitespaces are included in
the schema to conform to the line length restrictions of the RFC
format without having a negative impact on the readability of the
document. Any conforming processor should remove leading and
trailing white spaces.
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held" targetNamespace="urn:ietf:params:xml:ns:geopriv:held"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:held="urn:ietf:params:xml:ns:geopriv:held" xmlns:held="urn:ietf:params:xml:ns:geopriv:held"
xmlns:xml="http://www.w3.org/XML/1998/namespace" xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
skipping to change at page 22, line 29 skipping to change at page 22, line 43
When the transaction is being conducted over TLS (a required feature When the transaction is being conducted over TLS (a required feature
per Section 9.1), the channel will be integrity protected by per Section 9.1), the channel will be integrity protected by
appropriate ciphersuites. When TLS is not used, this protection will appropriate ciphersuites. When TLS is not used, this protection will
vary depending on the binding; in most cases, without protection from vary depending on the binding; in most cases, without protection from
TLS, the response will not be protected from modification en route. TLS, the response will not be protected from modification en route.
9.3. Privacy and Confidentiality 9.3. Privacy and Confidentiality
Location information returned by the LIS must be protected from Location information returned by the LIS must be protected from
access by unauthorized parties, whether those parties request the access by unauthorized parties, whether those parties request the
location from the LIS or intercept it en route. As in section location from the LIS or intercept it en route. As in Section 9.2,
Section 9.2, transactions conducted over TLS with appropriate transactions conducted over TLS with appropriate ciphersuites are
ciphersuites are protected from access by unauthorized parties en protected from access by unauthorized parties en route. Conversely,
route. Conversely, in most cases, when not conducted over TLS, the in most cases, when not conducted over TLS, the response will be
response will be accessible while en route from the LIS to the accessible while en route from the LIS to the requestor.
requestor.
Because HELD is an LCP and identifies clients and targets by IP Because HELD is an LCP and identifies clients and targets by IP
addresses, a requestor is authorized to access location for an IP addresses, a requestor is authorized to access location for an IP
address only if it is the holder of that IP address. The LIS MUST address only if it is the holder of that IP address. The LIS MUST
verify that the client is the target of the returned location, i.e., verify that the client is the target of the returned location, i.e.,
the LIS MUST NOT provide location to other entities than the target. the LIS MUST NOT provide location to other entities than the target.
Note that this is a necessary, but not sufficient criterion for Note that this is a necessary, but not sufficient criterion for
authorization. A LIS MAY deny requests according to any local authorization. A LIS MAY deny requests according to any local
policy. policy.
skipping to change at page 23, line 17 skipping to change at page 23, line 30
information is vulnerable to exposure through IP address spoofing information is vulnerable to exposure through IP address spoofing
attacks. A temporary spoofing of IP address could mean that a device attacks. A temporary spoofing of IP address could mean that a device
could request a Location Object or Location URI that would result in could request a Location Object or Location URI that would result in
another Device's location. In addition, in cases where a Device another Device's location. In addition, in cases where a Device
drops off the network for various reasons, the re-use of the Device's drops off the network for various reasons, the re-use of the Device's
IP address could result in another Device receiving the original IP address could result in another Device receiving the original
Device's location rather than its own location. These exposures are Device's location rather than its own location. These exposures are
limited by the following: limited by the following:
o Location URIs MUST have a limited lifetime, as reflected by the o Location URIs MUST have a limited lifetime, as reflected by the
value for the expires element in Section Section 6.5.2. The value for the expires element in Section 6.5.2. The lifetime of
lifetime of location URIs necessarily depends on the nature of the location URIs necessarily depends on the nature of the access.
access.
o The network SHOULD have mechanisms that protect against IP address o The network SHOULD have mechanisms that protect against IP address
spoofing, such as those defined in [RFC3704]. spoofing, such as those defined in [RFC3704].
o The LIS and network SHOULD be configured so that the LIS is made o The LIS and network SHOULD be configured so that the LIS is made
aware of Device movement within the network and addressing aware of Device movement within the network and addressing
changes. If the LIS detects a change in the network that results changes. If the LIS detects a change in the network that results
in it no longer being able to determine the location of the in it no longer being able to determine the location of the
Device, then all location URIs for that Device SHOULD be Device, then all location URIs for that Device SHOULD be
invalidated. invalidated.
The above measures are dependent on network configuration, which The above measures are dependent on network configuration, which
skipping to change at page 24, line 8 skipping to change at page 24, line 18
with comments. with comments.
10.1. HTTPS Example Messages 10.1. HTTPS Example Messages
The examples in this section show a complete HTTPS message that The examples in this section show a complete HTTPS message that
includes the HELD request or response document. includes the HELD request or response document.
This example shows the most basic request for a LO. This uses the This example shows the most basic request for a LO. This uses the
GET feature described by the HTTP binding. GET feature described by the HTTP binding.
GET https://lis.example.com:49152/location HTTP/1.1 GET /location HTTP/1.1
Accept:application/held+xml, Host: lis.example.com:49152
application/xml;q=0.8,
text/xml;q=0.7
Accept-Charset: UTF-8,*
The GET request is exactly identical to a minimal POST request that The GET request is exactly identical to a minimal POST request that
includes an empty "locationRequest" element. includes an empty "locationRequest" element.
POST https://lis.example.com:49152/location HTTP/1.1 POST /location HTTP/1.1
Accept: application/held+xml, Host: lis.example.com:49152
application/xml;q=0.8,
text/xml;q=0.7
Accept-Charset: UTF-8,*
Content-Type: application/held+xml Content-Type: application/held+xml
Content-Length: 87 Content-Length: 87
<?xml version="1.0"?> <?xml version="1.0"?>
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
Since neither of these requests includes a "locationType" element, Since neither of these requests includes a "locationType" element,
the successful response to either of these requests may contain any the successful response to either of these requests may contain any
type of location. The following shows a response containing a type of location. The following shows a response containing a
minimal PIDF-LO. minimal PIDF-LO.
HTTP/1.x 200 OK HTTP/1.1 200 OK
Server: Example LIS Server: Example LIS
Date: Tue, 10 Jan 2006 03:42:29 GMT Date: Tue, 10 Jan 2006 03:42:29 GMT
Expires: Tue, 10 Jan 2006 03:42:29 GMT Expires: Tue, 10 Jan 2006 03:42:29 GMT
Cache-control: private Cache-control: private
Content-Type: application/held+xml Content-Type: application/held+xml
Content-Length: 594 Content-Length: 594
<?xml version="1.0"?> <?xml version="1.0"?>
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"> <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
skipping to change at page 31, line 50 skipping to change at page 31, line 50
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 13. Acknowledgements
The author/contributors would like to thank the participants in the The author/contributors would like to thank the participants in the
GEOPRIV WG and the following people for their constructive input and GEOPRIV WG and the following people for their constructive input and
feedback on this document (in alphabetical order): Nadine Abbott, feedback on this document (in alphabetical order): Nadine Abbott,
Eric Arolick, Richard Barnes (in particular the security section), Eric Arolick, Richard Barnes (in particular the security section),
Peter Blatherwick, Ben Campbell, Guy Caron, Martin Dawson, Lisa Peter Blatherwick, Ben Campbell, Guy Caron, Eddy Corbett, Martin
Dusseault, Jerome Grenier, Ted Hardie, Cullen Jennings, Neil Dawson, Lisa Dusseault, Jerome Grenier, Ted Hardie, Cullen Jennings,
Justusson, Tat Lam, Marc Linsner, Patti McCalmont, Roger Marshall, Neil Justusson, Tat Lam, Marc Linsner, Patti McCalmont, Roger
Perry Prozeniuk, Carl Reed, Julian Reschke, Eric Rescorla, Brian Marshall, Perry Prozeniuk, Carl Reed, Julian Reschke, Eric Rescorla,
Rosen, John Schnizlein, Shida Schubert, Henning Schulzrinne, Ed Brian Rosen, John Schnizlein, Shida Schubert, Henning Schulzrinne, Ed
Shrum, Doug Stuard, Hannes Tschofenig and Karl Heinz Wolf. Shrum, Doug Stuard, Hannes Tschofenig and Karl Heinz Wolf.
14. Changes since last Version 14. 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 09 to 10 (2nd WGLC):
1) Updated text for Devices and VPNs (section 4.1.1) to include
servers such as HTTP and SOCKs, thus changed the text to be generic
in terms of locating LIS before connecting to one of these servers,
etc.
2) Fixed (still buggy) HTTP examples.
3) Added text explaining the whitespaces in XML schema are for
readability/document format limitations and that they should be
handled via parser/schema validation.
4) Miscellaneous editorial nits
Changes from WG 08 to 09 (Post-IETF LC: continued resolution of sec- Changes from WG 08 to 09 (Post-IETF LC: continued resolution of sec-
dir and gen-art review comments, along with apps-area feedback): dir and gen-art review comments, along with apps-area feedback):
1) Removed heldref/heldrefs URIs, including fixing examples (which 1) Removed heldref/heldrefs URIs, including fixing examples (which
were buggy anyways). were buggy anyways).
2) Clarified text for locationURI - specifying that the deref 2) Clarified text for locationURI - specifying that the deref
protocol must define or appropriately restrict and clarifying that protocol must define or appropriately restrict and clarifying that
requirements for deref must be met and that deref details are out of requirements for deref must be met and that deref details are out of
scope for this document. scope for this document.
skipping to change at page 37, line 36 skipping to change at page 38, line 4
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[I-D.ietf-geopriv-pdif-lo-profile] [I-D.ietf-geopriv-pdif-lo-profile]
Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations and PIDF-LO Usage Clarification, Considerations and
Recommendations", draft-ietf-geopriv-pdif-lo-profile-11 Recommendations", draft-ietf-geopriv-pdif-lo-profile-13
(work in progress), February 2008. (work in progress), September 2008.
[W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-1-20041028]
Maloney, M., Thompson, H., Mendelsohn, N., and D. Beech, Thompson, H., Mendelsohn, N., Beech, D., and M. Maloney,
"XML Schema Part 1: Structures Second Edition", World Wide "XML Schema Part 1: Structures Second Edition", World Wide
Web Consortium Recommendation REC-xmlschema-1-20041028, Web Consortium Recommendation REC-xmlschema-1-20041028,
October 2004, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[W3C.REC-xmlschema-2-20041028] [W3C.REC-xmlschema-2-20041028]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium Second Edition", World Wide Web Consortium
Recommendation REC-xmlschema-2-20041028, October 2004, Recommendation REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[I-D.ietf-geopriv-lis-discovery] [I-D.ietf-geopriv-lis-discovery]
Thomson, M. and J. Winterbottom, "Discovering the Local Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", Location Information Server (LIS)",
draft-ietf-geopriv-lis-discovery-02 (work in progress), draft-ietf-geopriv-lis-discovery-03 (work in progress),
July 2008. September 2008.
15.2. Informative References 15.2. Informative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
skipping to change at page 39, line 9 skipping to change at page 39, line 24
[I-D.ietf-geopriv-lbyr-requirements] [I-D.ietf-geopriv-lbyr-requirements]
Marshall, R., "Requirements for a Location-by-Reference Marshall, R., "Requirements for a Location-by-Reference
Mechanism", draft-ietf-geopriv-lbyr-requirements-03 (work Mechanism", draft-ietf-geopriv-lbyr-requirements-03 (work
in progress), July 2008. in progress), July 2008.
[I-D.ietf-sip-location-conveyance] [I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol", Session Initiation Protocol",
draft-ietf-sip-location-conveyance-10 (work in progress), draft-ietf-sip-location-conveyance-10 (work in progress),
February 2008. September 2008.
[I-D.winterbottom-geopriv-deref-protocol] [I-D.winterbottom-geopriv-deref-protocol]
Winterbottom, J., Tschofenig, H., Schulzrinne, H., Winterbottom, J., Tschofenig, H., Schulzrinne, H.,
Thomson, M., and M. Dawson, "An HTTPS Location Thomson, M., and M. Dawson, "An HTTPS Location
Dereferencing Protocol Using HELD", Dereferencing Protocol Using HELD",
draft-winterbottom-geopriv-deref-protocol-02 (work in draft-winterbottom-geopriv-deref-protocol-02 (work in
progress), July 2008. progress), July 2008.
Appendix A. HELD Compliance to IETF LCP requirements Appendix A. HELD Compliance to IETF LCP requirements
skipping to change at page 40, line 47 skipping to change at page 41, line 19
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."
COMPLY COMPLY
HELD was specifically designed with this model in mind and readily HELD was specifically designed with this model in mind and readily
allows itself to chaining requests between operators without a change allows itself to chaining requests between operators without a change
in protocol being required. HELD is a webservices protocol it can be in protocol being required. HELD is a webservices protocol which can
bound to transports other than HTTP. Using o offers the option of be bound to transports other than HTTP, such as BEEP. Using a
high request throughput over a dedicated connection between an L3 protocol such as BEEP offers the option of high request throughput
provider and an L2 provider without incurring the serial restriction over a dedicated connection between an L3 provider and an L2 provider
imposed by HTTP. This is less easy to do with protocols that do not without incurring the serial restriction imposed by HTTP. This is
decouple themselves from the transport. less easy to do with protocols that do not decouple themselves from
the transport.
A.5. L7-5: Legacy Device Considerations A.5. L7-5: Legacy Device Considerations
"The design of the GEOPRIV Layer 7 Location Configuration Protocol "The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST consider legacy residential NAT devices and NTEs in an DSL MUST consider legacy residential NAT devices and NTEs in an DSL
environment that cannot be upgraded to support additional protocols, environment that cannot be upgraded to support additional protocols,
for example to pass additional information through DHCP." for example to pass additional information through DHCP."
COMPLY COMPLY
 End of changes. 31 change blocks. 
67 lines changed or deleted 81 lines changed or added

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