draft-ietf-geopriv-http-location-delivery-03.txt   draft-ietf-geopriv-http-location-delivery-04.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: May 20, 2008 Expires: July 17, 2008
November 17, 2007 January 14, 2008
HTTP Enabled Location Delivery (HELD) HTTP Enabled Location Delivery (HELD)
draft-ietf-geopriv-http-location-delivery-03.txt draft-ietf-geopriv-http-location-delivery-04.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 May 20, 2008. This Internet-Draft will expire on July 17, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). 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 either by-value or by-reference. The protocol location information in two forms: by-value and by-reference. The
is an application-layer protocol that is independent of session- protocol is an extensible application-layer protocol that is
layer. This document describes the use of Hypertext Transfer independent of session-layer. This document describes the use of
Protocol (HTTP) as a delivery mechanism 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. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 7 4.1. Location by Value . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 8 4.2. Location by Reference . . . . . . . . . . . . . . . . . . 7
4.1.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 8 4.3. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 7
4.3.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 8
4.3.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 8
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8
5.1. Delivery Protocol . . . . . . . . . . . . . . . . . . . . 9 5.1. Delivery Protocol . . . . . . . . . . . . . . . . . . . . 9
5.2. Location Request . . . . . . . . . . . . . . . . . . . . . 9 5.2. Location Request . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . 11
6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 12 6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 12
6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 12 6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 12
6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 13 6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 13
6.5. "locationURI" Parameter . . . . . . . . . . . . . . . . . 13 6.5. "locationURI" Parameter . . . . . . . . . . . . . . . . . 13
6.5.1. "expires" Parameter . . . . . . . . . . . . . . . . . 13 6.5.1. "expires" Parameter . . . . . . . . . . . . . . . . . 14
7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.6. "pidf-LO" Parameter . . . . . . . . . . . . . . . . . . . 15
8. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Return Routability . . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9.2. Transaction Layer Security . . . . . . . . . . . . . . . . 19 9.1. Return Routability . . . . . . . . . . . . . . . . . . . . 20
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.2. Transaction Layer Security . . . . . . . . . . . . . . . . 21
10.1. HTTP Example Messages . . . . . . . . . . . . . . . . . . 19 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.2. Simple Location Request Example . . . . . . . . . . . . . 22 10.1. HTTP Example Messages . . . . . . . . . . . . . . . . . . 21
10.3. Location Request Example for Multiple Location Types . . . 23 10.2. Simple Location Request Example . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 10.3. Location Request Example for Multiple Location Types . . . 25
11.1. URN Sub-Namespace Registration for 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 24 11.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 26
11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 25 11.1.1. URN Sub-Namespace Registration for
11.3. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . 26
urn:ietf:params:xml:ns:geopriv:held:http . . . . . . . . . 25 11.1.2. URN Sub-Namespace Registration for
11.4. MIME Media Type Registration for 'application/held+xml' . 26 urn:ietf:params:xml:ns:geopriv:held:http . . . . . . . 27
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 28
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 11.3. MIME Media Type Registration for 'application/held+xml' . 28
14. Changes since last Version . . . . . . . . . . . . . . . . . . 27 11.4. Error code Registry . . . . . . . . . . . . . . . . . . . 29
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 11.5. URI Registration . . . . . . . . . . . . . . . . . . . . . 29
15.1. Normative References . . . . . . . . . . . . . . . . . . . 29 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30
15.2. Informative References . . . . . . . . . . . . . . . . . . 31 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 31 14. Changes since last Version . . . . . . . . . . . . . . . . . . 31
A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 31 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 32 15.1. Normative References . . . . . . . . . . . . . . . . . . . 33
A.3. L7-3: ASP and Access Network Provider Relationship . . . . 32 15.2. Informative References . . . . . . . . . . . . . . . . . . 35
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 33 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 36
A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 33 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 36
A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 33 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 36
A.7. L7-7: Network Access Authentication . . . . . . . . . . . 34 A.3. L7-3: ASP and Access Network Provider Relationship . . . . 37
A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 34 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 37
A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 34 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 37
A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 34 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . . . . 37 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 38
A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 39
A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . . . . 41
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 [11] provides some
scenarios in which a Device might rely on its access network to scenarios in which the Device might rely on its access network to
provide the location information, such as fixed environments (e.g., provide location information. The LIS service applies to access
DSL/Cable), mobile networks and wireless access networks. This networks employing both wired technology (e.g. DSL, Cable) and
document describes a protocol that can be used to acquire Location wireless technology (e.g. WiMAX) with varying degrees of Device
Information (LI) from a Location Information Server (LIS) within an mobility. This document describes a protocol that can be used to
access network. acquire Location Information (LI) from a Location Information Server
(LIS) within an access network.
This specification identifies two methods for acquiring LI. Location This specification identifies two types of location information that
may be retrieved from a LIS by-value, that is, the Device may acquire may be retrieved from the LIS. Location may be retrieved from the
a literal location object describing the location of the Device. LIS by-value, that is, the Device may acquire a literal location
Alternatively, the Device may request that the LIS provide a location object describing the location of the Device. The Device may also
reference in the form of a location URI or set of location URIs, request that the LIS provide a location reference in the form of a
allowing the Device to distribute its LI by-reference. Both of these location URI or set of location URIs, allowing the Device to
methods are compatible, and both can be provided concurrently from distribute its LI by-reference. Both of these methods can be
the same LIS so that application needs can be addressed individually. provided concurrently from the same LIS to accommodate application
requirements for different types of location information.
This specification defines an XML-based protocol that enables the This specification defines an extensible XML-based protocol that
retrieval of LI from a LIS by a Device. This protocol can be bound enables the retrieval of LI from a LIS by a Device. This protocol
to any session-layer protocol, particularly those capable of MIME can be bound to any session-layer protocol, particularly those
transport. This document describes the use of Hypertext Transfer capable of MIME transport. This document describes the use of
Protocol (HTTP) as a delivery mechanism 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 [7] . 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 [11]. 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
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
"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). The LIS is present within the same Information Server (LIS). This document assumes that the LIS is
administrative domain as the Device (the access network). An Access present within the same administrative domain as the Device (e.g.,
Provider (AP) operates the LIS so that Devices (and Targets) can the access network). An Access Provider (AP) operates the LIS so
retrieve LI. The LIS exists because not all Devices are capable of that Devices (and Targets) can retrieve LI. The LIS exists because
determining LI, and because, even if a device is able to determine not all Devices are capable of determining LI, and because, even if a
its own LI, it may be more efficient with assistance. This document device is able to determine its own LI, it may be more efficient with
does not specify how LI is derived. 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
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 [22]. be found in the SIP Location Conveyance document [23].
The HELD protocol uses the IP address of the Device as an identifier
in determining the location of the device. This identifier is
revealed to the LIS through the source address in requests sent by
the Device. The use of additional identifiers for the HELD protocol
is outside the scope of this document.
4. Protocol Overview 4. Protocol Overview
The HELD protocol facilitates retrieval of LI either by-value, as a The HELD protocol facilitates retrieval of location directly in the
PIDF-LO document, or by-reference, as a Location URI. The policy form of a PIDF-LO document (by-value) and indirectly as a Location
that describes to whom, and how, LI is granted is outside the scope URI (by-reference). The policy that describes to whom, and how, LI
of this document and may be specified in separate specifications as is granted is outside the scope of this document and may be specified
required. The Device must first discover the URI for the LIS for in separate specifications as required. The Device must first
sending the HELD protocol requests as identified by the requirement discover the URI for the LIS for sending the HELD protocol requests
in the L7 LCP problem statement and requirements [11]. The discovery as identified by the requirement in the L7 LCP problem statement and
methods are specified in [14]. requirements [11]. The discovery methods are specified in [14]. The
LIS uses the source IP address of 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
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]. The LIS MUST follow those rules in generating the document [10]. Further detail is included in the detailed protocol
PIDF-LO in this case. Per the GEOPRIV Location Object format section of this document Section 6
specified in [8], the "entity" element MUST reflect the Target of the
Location Information. In addition, the default values for 4.2. Location by Reference
<retransmission-allowed> and <retention-expiry> as specified in [8]
MUST be applied. A default value of "no" SHALL be used for the
<retransmission-allowed> element. A default value of 24 hours SHALL
be used for <retention-expiry> value of any generated PIDF-LO
documents. A LIS MAY provide a shorter value for <retention-expiry>
but MUST NOT provide a value longer than 24 hours.
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 [21] of any scheme, which literal location. A Location URI is a URI [20] 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. This does not in
any way suggest that the LIS is bound to reveal the location any way suggest that the LIS is bound to reveal the location
associated with the location URI. This issue is deemed out of scope associated with the location URI. This issue is deemed out of scope
for this document. The merits and drawbacks of using a Location URI for this document. The merits and drawbacks of using a Location URI
approach are discussed in [15]. approach are discussed in [15].
4.1. 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. As described in identifier used by the LIS to determine location. This document
Section 3, this document describes the use of the IP address of the describes the use of the IP address of the Device as the identifier.
Device as the identifier. When Network Address Translation (NAT), a When Network Address Translation (NAT), a Virtual Private Network
Virtual Private Network (VPN) or other forms of address modification (VPN) or other forms of address modification occur between the Device
occur between the Device and the LIS, the location returned could be and the LIS, the location returned could be inaccurate.
inaccurate.
This is not always the case. For example, a NAT used in a Not all cases of NATs introduce inaccuracies in the returned
residential Local Area Network (LAN) is typically not a problem. The location. For example, a NAT used in a residential Local Area
external IP address used on the Wide Area Network (WAN) side of the Network (LAN) is typically not a problem. The external IP address
NAT is an acceptable identifier for all of the devices in the used on the Wide Area Network (WAN) side of the NAT is an acceptable
residence since the covered geographical area is small. identifier for all of the devices in the residence, on the LAN side
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 address seen by the LIS might for example for a teleworker, then the IP address seen by the LIS
not be the right address to identify the location of the Device. might not be the right address to identify the location of the
Device.
4.1.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 [14] and an initial query are performed before establishing
the VPN. the VPN. If a Device performs the HELD query after establishing the
VPN tunnel, the Device may receive inaccurate location information.
Devices that establish VPN connections for use by other devices Devices that establish VPN connections for use by other devices
inside a LAN or other closed network MAY act as a HELD LIS for those inside a LAN or other closed network may serve as a LIS, that
other devices. Devices within the closed network are not necessarily implements the HELD protocol, for those other Devices. Devices
able to detect the presence of the VPN and are reliant on the VPN within the closed network are not necessarily able to detect the
device. To this end, a VPN device SHOULD provide the address, of the presence of the VPN and rely on the VPN device. To this end, a VPN
LIS server it provides, in response to discovery queries. device should provide the address, of the LIS server it provides, in
response to discovery queries.
It could also be useful for a VPN device to act 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)[20] or Link Layer Discovery Protocol - Media Endpoint Protocol (DHCP)[21] or Link Layer Discovery Protocol - Media Endpoint
Discovery (LLDP-MED) [23]. VPN devices that act as a LIS MAY acquire Discovery (LLDP-MED) [25]. VPN devices that serve as a LIS may
their own location using HELD. acquire their own location using HELD.
4.1.2. LIS Handling of NATs and VPNs 4.3.2. LIS Handling of NATs and VPNs
A LIS MUST NOT provide location information to a Device if it cannot In the cases where the Device uses a VPN connection or is behind a
provide accurate information. This applies where the Device uses a NAT that serves a large geographic area or multiple geographic
VPN connection or is behind a NAT that serves a large geographic area locations (for example, a NAT used by an enterprise to connect their
or multiple geographic locations (for example, a NAT used by an private network to the Internet), the LIS may not be able to return
enterprise to connect their private network to the Internet). The an accurate LI. If the LIS cannot determine an accurate LI, it
LIS needs to be configured to recognize identifiers that represent should not provide location information to the requesting device.
these conditions. The LIS needs to be configured to recognize identifiers that
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 a Location or a Location URI from a LIS. Three messages are of location in the form of a PIDF-LO document and/or Location URI(s)
defined to support the location retrieval: locationRequest, from a LIS. Three messages are defined to support the location
locationResponse and error. Messages are defined as XML documents. retrieval: locationRequest, locationResponse and error. 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 a Location (and the specific type of location) and/or a whether location in the form of a PIDF-LO document (with specific
Location URI should be returned. The LIS replies with a response type(s) of location) and/or Location URI(s) should be returned. The
(locationResponse), including a PIDF-LO document and/or one or more LIS replies with a response (locationResponse), including a PIDF-LO
Location URIs in case of success, or an error message in case of an document and/or one or more Location URIs in case of success, or an
error. error message in case of an error.
A MIME type "application/held+xml" is registered in Section 11.4 to A MIME type "application/held+xml" is registered in Section 11.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 [18], 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 [12].
skipping to change at page 9, line 49 skipping to change at page 9, line 47
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 it
requires LI. The type of LI that a Device requests is determined by requires LI. The type of LI that a Device requests is determined by
the type of LI that is included in the "locationType" element. 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 either a PIDF-LO The response to a Location request MUST contain a PIDF-LO and/or
and/or Location URI(s), depending upon the requested "locationType". Location URI(s), depending upon the requested "locationType".
5.4. Indicating Errors 5.4. Indicating Errors
In the event of an error, the LIS MUST respond to the Device with an In the event of an error, the LIS MUST respond to the Device with an
error document. The error response applies to all request types and error document. The error response applies to all request types and
MUST also be sent in response to any unrecognized request. MUST also be sent in response to any unrecognized request.
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
skipping to change at page 10, line 45 skipping to change at page 10, line 42
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) | | | |
| exact (Section 6.2.1) | o | | | | code (Section 6.3) | | | m |
| code (Section 6.3) | | m | m |
| message (Section 6.4) | | | o | | message (Section 6.4) | | | o |
| locationURI | | o | | | locationURI | | o | |
| (Section 6.5) | | | | | (Section 6.5) | | | |
| expires | | m | | | PIDF-LO (Section 6.6) | | o | |
| (Section 6.5.1) | | | |
+------------------------+----------------+-----------------+-------+ +------------------------+----------------+-----------------+-------+
Table 1: Message Parameter Usage Table 1: Message Parameter Usage
6.1. "responseTime" Parameter 6.1. "responseTime" Parameter
The "responseTime" parameter is optional and indicates to the LIS how The "responseTime" attribute MAY be included in a location request
long the Device is prepared to wait for a response and/or the purpose message. The "responseTime" attribute includes a time value
for which the Device needs the location. In the case of emergency indicating to the LIS how long the Device is prepared to wait for a
services, the purpose of obtaining the LI could be either for routing response and/or a purpose for which the Device needs the location.
a call to the appropriate PSAP or indicating the location to which In the case of emergency services, the purpose of obtaining the LI
responders should be dispatched. The time values defined for those could be either for routing a call to the appropriate PSAP or
purposes, emergencyRouting and emergencyDispatch, will likely be indicating the location to which responders should be dispatched.
governed by jurisdictional policies, and SHOULD be configurable on The values defined for the purpose, emergencyRouting and
the LIS. emergencyDispatch, will likely be governed by jurisdictional
policies, and should be configurable on the LIS.
The value of the "responseTime" parameter is indicative only and the The time value in the "responseTime" attribute is expressed as a non-
LIS is under no obligation to strictly adhere to the time limit negative integer in units of milliseconds. The time value is
implied; any enforcement of the time limit is left to the requesting indicative only and the LIS is under no obligation to strictly adhere
Device. The "responseTime" parameter is expressed with a decimal to the time limit implied; any enforcement of the time limit is left
seconds value, which may include a decimal point. It is RECOMMENDED to the requesting Device. The LIS should provide the most accurate
that systems support millisecond precision for this parameter. The LI that can be determined within the specified interval for the
LIS SHOULD provide the most accurate LI that can be determined within specific service.
the specified interval for the specific service.
The LIS MAY use the value of the "responseTime" parameter as input The LIS may use the value of the time in the "responseTime" attribute
when selecting the method of location determination, where multiple as input when selecting the method of location determination, where
such methods exist. If this parameter is absent, then the LIS MUST multiple such methods exist. If the "responseTime" attribute is
return the most precise LI it is capable of determining, with the absent, then the LIS should return the most precise LI it is capable
time interval being implementation dependent. of determining, with the time interval being implementation
dependent.
6.2. "locationType" Parameter 6.2. "locationType" Parameter
The "locationType" element MAY be included in a location request The "locationType" element MAY be included in a location request
message. It contains a list of LI types that are requested by the message. It contains a list of LI types that are requested by the
Device. The following list describes the possible values: Device. The following list describes the possible values:
any: The LIS SHOULD attempt to provide LI in all forms available to
it. This value MUST be assumed as the default if no
"locationType" is specified. The LIS SHOULD return location
information in a form that is suited for routing and responding to
an emergency call in its jurisdiction. The LIS MAY alternatively
or additionally return a location URI.
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
suited for routing and responding to an emergency call in its
jurisdiction. The LIS MAY alternatively or additionally return a
location URI. If the "locationType" element is absent, this value
MUST be assumed as the default.
geodetic: The LIS SHOULD return a geodetic location for the Target. geodetic: The LIS SHOULD return a geodetic location for the Target.
civic: The LIS SHOULD return a civic address for the Target. Any civic: The LIS SHOULD return a civic address for the Target. 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 location URI 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. If the "exact" attribute is present and set to "true" in a type. A location URI provided by the LIS is a reference to the most
location request, then a successful LIS response MUST provide the current available LI, and the Target Device should understand that it
requested location type only, with no additional location is not a stable reference to a specific location. The location types
information. The "exact" attribute has no effect when this element the LIS returns also depends on the setting of the optional "exact"
is set to "any". attribute, as described in the following section.
The "SHOULD"-strength requirement on this parameter is included to The "SHOULD"-strength requirement on this parameter is 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. Unless the requests to fail when that location type is unavailable. For
"exact" attribute is set, the LIS MUST provide LI in any available example, a notebook computer could be configured to retrieve civic
form if it is unable to comply with the request. addresses, which is usually available from typical home or work
For example, a notebook computer could be configured to retrieve
civic addresses, which is usually available from typical home or work
situations. However, when using a wireless modem, the LIS might be 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
When the "exact" attribute is set to "true", it indicates to the LIS The "exact" attribute MAY be included in a location request message
that the contents of the "locationType" parameter MUST be strictly when the "locationType" element is included. When the "exact"
followed. The default value of "false" allows the LIS the option of attribute is set to "true", it indicates to the LIS that the contents
returning something beyond what is specified, such as a location URI of the "locationType" parameter MUST be strictly followed. The
when only a civic location was requested. default value of "false" allows the LIS the option of returning
something beyond what is specified, such as a location URI 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
skipping to change at page 13, line 35 skipping to change at page 13, line 32
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. "locationURI" Parameter
The "locationURI" element includes a single Location URI. Each The "locationURI" element includes a single Location URI. Each
Location URI that is allocated by the LIS is unique to the device Location URI that is allocated by the LIS is unique to the device
that is requesting it. that is requesting it. A "locationResponse" message MAY contain any
number of "locationURI" elements.
A "locationResponse" message MAY contain any number of "locationURI" The "locationURI" elements MUST be in the form of a HELD: URI, which
elements. It is RECOMMENDED that the LIS allocate a Location URI for is defined following RFC3986 [20] and the associated URI Guidelines
each scheme that it supports and that each scheme is present only [22] recommendations, per the following ABNF syntax:
once. URI schemes and their secure variants such as http and https
MUST be regarded as two separate schemes. 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
is encoded entirely in US-ASCII. The following are examples of HELD:
URIs:
held://5432+379xyziou@ls.example.com
held://thislocation@ls.example.com
held://ls.example.com/thislocation
held://9876abcde@ls.example.com/civic
The 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.
A "locationURI" MUST NOT contain any information that could be used A "locationURI" MUST NOT contain any information that could be used
to identify the Device or Target. It is RECOMMENDED that a to identify the Device or Target. It is recommended that a
"locationURI" contain a public address for the LIS and an anonymous "locationURI" contain a public address for the LIS in the "host"
identifier, such as a local identifer or unlinked pseudonym. 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
then deference the location to obtain a PIDF-LO in a subsequent
request to a LIS, as described in [24]. The following section
discusses the "expires" attribute, which defines the length of time
for which a specific HELD-URI is valid.
6.5.1. "expires" Parameter 6.5.1. "expires" Parameter
The "expires" attribute is optional and is only included in a The "expires" attribute is only included in a "locationResponse"
"locationResponse" message when a Location URI is included. The message when a Location URI is included. The "expires" attribute
"expires" attribute indicates the time at which the Location URI indicates the time at which the Location URI provided by the LIS will
provided by the LIS will expire. expire.
Responses to Locations requests for Location URIs MUST include the Responses to Location requests for Location URIs MUST include the
expiry time of the Location URI. expiry time of the Location URI. If a Device dereferences the
location URI after the expiry time, it would be possible to get an
entirely invalid location for that Device.
6.6. "pidf-LO" Parameter
A "pidf-LO" may be included in the "locationResponse" message when
specific locationTypes (e.g., "geodetic" or "civic") are requested or
a "locationType" of "any" is requested. The details on the
information that may be included in the PIDF-LO MUST follow the
subset of those rules relating to the construction of the
"location-info" element in the PIDF-LO Usage Clarification,
Considerations and Recommendations document [10]. The LIS MUST
follow those rules in generating the PIDF-LO in this case. Per the
GEOPRIV Location Object format specified in [8], the "entity" element
MUST reflect the Target of the Location Information. In addition,
the default values for <retransmission-allowed> and <retention-
expiry> as specified in [8] MUST be applied. A default value of "no"
SHALL be used for the <retransmission-allowed> element. A default
value of 24 hours SHALL be used for <retention-expiry> value of any
generated PIDF-LO documents. A LIS MAY provide a shorter value for
<retention-expiry> but MUST NOT provide a value longer than 24 hours.
Note that the PIDF-LO is not explicitly shown in the XML schema
Section 7 for a location response message due to XML schema
constraints.
7. XML Schema 7. XML Schema
This section gives the XML Schema Definition [12] of the This section gives the XML Schema Definition [12] 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"?>
skipping to change at page 15, line 13 skipping to change at page 16, line 38
<!-- responseTime Type --> <!-- responseTime Type -->
<xs:simpleType name="responseTimeType"> <xs:simpleType name="responseTimeType">
<xs:union> <xs:union>
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:enumeration value="emergencyRouting"/> <xs:enumeration value="emergencyRouting"/>
<xs:enumeration value="emergencyDispatch"/> <xs:enumeration value="emergencyDispatch"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:decimal"> <xs:restriction base="xs:nonNegativeInteger">
<xs:minInclusive value="0.0"/> <xs:minInclusive value="0"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:union> </xs:union>
</xs:simpleType> </xs:simpleType>
<!-- Location Type --> <!-- Location Type -->
<xs:simpleType name="locationTypeBase"> <xs:simpleType name="locationTypeBase">
<xs:union> <xs:union>
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
skipping to change at page 17, line 39 skipping to change at page 19, line 17
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:element name="locationRequest" <xs:element name="locationRequest"
type="held:locationRequestType"/> type="held:locationRequestType"/>
</xs:schema> </xs:schema>
8. HTTP Binding 8. HTTP Binding
This section describes the use of HTTP [3] as a delivery 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".
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 "expires" and cache
control headers are used to control the caching of any PIDF-LO control headers are used to control the caching of any PIDF-LO
document or Location URIs. The HTTP status code SHOULD indicate a document or Location URIs. The HTTP status code SHOULD indicate a
2xx series response when a PIDF-LO document or Location URI is 2xx series response when a PIDF-LO document or Location URI is
included. included.
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 delivery mechanism MUST implement TLS The implementation of HTTP as a transport mechanism MUST implement
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 9. Security Considerations
The threat model for this protocol assumes that the LIS exists within The Security Requirements for the Geopriv Location System [Editor's
the same administrative domain as the Device. The LIS requires note: need to add explicit reference to this doc, BUT xml2rfc not
access to network information so that it can determine Location. happy with that doc not having an abbreviated title] identifies the
Therefore, the LIS can use network information to protect against a threat model for the protocols that interface with a LIS. The threat
number of the possible attacks. model for the HELD protocol assumes that the LIS exists within the
same administrative domain as the Device. The LIS requires access to
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 Specific requirements and security considerations for location
acquisition protocols are provided in [11] including that the LCP acquisition protocols are provided in [11] including that the LCP
MUST NOT assume prior network access authentication, which is MUST NOT assume prior network access authentication, which is
addressed in Section 9.2 addressed in Section 9.2
An in-depth discussion of the security considerations applicable to An in-depth discussion of the security considerations applicable to
the use of Location URIs and by-reference provision of LI is included the use of Location URIs and by-reference provision of LI is included
in [15]. in [15].
skipping to change at page 22, line 35 skipping to change at page 24, line 35
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>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o <locationURI>held://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI> </locationURI>
<locationURI>sips:9769+357yc6s64ceyoiuy5ax3o@ls.example.com <locationURI>held://9769+357yc6s64ceyoiuy5ax3o@ls.example.com
</locationURI> </locationURI>
</locationUriSet> </locationUriSet>
</locationResponse> </locationResponse>
An error response to this location request is shown below: An error response to this location request is shown below:
<error xmlns="urn:ietf:params:xml:ns:geopriv:held" <error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="locationUnknown" code="locationUnknown"
message="Location not available"/> message="Location not available"/>
skipping to change at page 23, line 23 skipping to change at page 25, line 23
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>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o <locationURI>held://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI> </locationURI>
<locationURI>sips:9769+357yc6s64ceyoiuy5ax3o@ls.example.com: <locationURI>held://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 24, line 28 skipping to change at page 26, line 28
<method>Wiremap</method> <method>Wiremap</method>
</geopriv> </geopriv>
</status> </status>
<timestamp>2007-05-24T12:35:02+10:00</timestamp> <timestamp>2007-05-24T12:35:02+10:00</timestamp>
</tuple> </tuple>
</presence> </presence>
</locationResponse> </locationResponse>
11. IANA Considerations 11. IANA Considerations
This document registers an XML namespace and schema and the This document requires several IANA registrations detailed in the
"application/held+xml" MIME type. following sections.
11.1. URN Sub-Namespace Registration for 11.1. URN Sub-Namespace Registration
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", as per the guidelines in [6]. "urn:ietf:params:xml:ns:geopriv:held".
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">
skipping to change at page 25, line 23 skipping to change at page 27, line 23
<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.2. XML Schema Registration 11.1.2. URN Sub-Namespace Registration for
This section registers an XML schema as per the guidelines in [6].
URI: urn:ietf:params:xml:schema:geopriv:held
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Mary Barnes (mary.barnes@nortel.com).
Schema: The XML for this schema can be found as the entirety of
Section 7 of this document.
11.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:http urn:ietf:params:xml:ns:geopriv:held:http
This section registers a new XML namespace, TThis section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:held:http", as per the guidelines in "urn:ietf:params:xml:ns:geopriv:held:http."
[6].
URI: urn:ietf:params:xml:ns:geopriv:held:http URI: urn:ietf:params:xml:ns:geopriv:held:http
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">
skipping to change at page 26, line 23 skipping to change at page 28, line 5
<body> <body>
<h1>Namespace for HELD HTTP Binding WS</h1> <h1>Namespace for HELD HTTP Binding WS</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:http</h2> <h2>urn:ietf:params:xml:ns:geopriv:held:http</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.4. MIME Media Type Registration for 'application/held+xml' 11.2. XML Schema Registration
This section registers an XML schema as per the guidelines in [6].
URI: urn:ietf:params:xml:schema:geopriv:held
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Mary Barnes (mary.barnes@nortel.com).
Schema: The XML for this schema can be found as the entirety of
Section 7 of this document.
11.3. MIME Media Type Registration for 'application/held+xml'
This section registers the "application/held+xml" MIME type. This section registers the "application/held+xml" MIME type.
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type application/held+xml Subject: Registration of MIME media type application/held+xml
MIME media type name: application MIME media type name: application
MIME subtype name: held+xml MIME subtype name: held+xml
Required parameters: (none) Required parameters: (none)
Optional parameters: charset Optional parameters: charset
Indicates the character encoding of enclosed XML. Default is Indicates the character encoding of enclosed XML. Default is
UTF-8. UTF-8.
skipping to change at page 27, line 7 skipping to change at page 28, line 45
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: This specification is TBD 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 [18], 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
This document requests that the IANA create a new registry the HELD
protocol including an initial registry for error codes. The error
codes are included in HELD error messages as described in Section 6.3
and defined in the schema in the 'codeType' token in the XML schema
in (Section 7)
The following summarizes the requested registry:
Related Registry: Geopriv HELD Registries, Error codes for HELD
Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.]
Registration/Assignment Procedures: New error codes are allocated on
a first-come/first-serve basis with specification recommended.
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Mary Barnes (mary.barnes@nortel.com).
This section pre-registers the following seven initial error codes as
described above in Section 6.3:
requestError: This code indicates that the request was badly formed
in some fashion.
xmlError: This code indicates that the XML content of the request
was either badly formed or invalid.
generalLisError: This code indicates that an unspecified error
occurred at the LIS.
locationUnknown: This code indicates that the LIS could not
determine the location of the Device.
unsupportedMessage: This code indicates that the request was not
supported or understood by the LIS.
timeout: This code indicates that the LIS could not satisfy the
request within the time specified in the "responseTime" parameter.
cannotProvideLiType: This code indicates that the LIS was unable to
provide LI of the type or types requested. This code is used when
the "exact" attribute on the "locationType" parameter is set to
"true".
11.5. URI Registration
The following summarizes the information necessary to register the
held: URI. [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the
RFC number for this specification in the following list.]
URI Scheme Name: held
Status: permanent
URI Scheme syntax: See section
URI Scheme Semantics: The held: URI is intended to be used as a
reference to a location object. Further detail is provided in
Section 6.5 of RFCXXXX.
Encoding Considerations: The HELD: URI is not intended to be human-
readable text, therefore they are encoded entirely in US-ASCII.
Applications/protocols that use this URI scheme: The HELD protocol
described in RFCXXXX and the GEOPRIV Location De-reference
Protocol [24]
Interoperability considerations: This URI is intended for use as a
parameter for the HELD protocol and this URI is also used as an
input parameter for the GEOPRIV Location De-reference Protocol
[24]. Refer to Section 6.5 in RFXXXX for further detail, in
particular on the lack of permanence of a specific HELD: URI and
thus the importance of using these URIs only within the specific
contexts outlined in the references.
Security considerations: Section 9 in RFXXXX addresses the necessary
security associated with the transport of location information
between a Device and the LIS to ensure the privacy and integrity
of the held: URI. The schema for the held: URI allows for a
random identifier in the form of a token in the URI Section 6.5 in
RFCXXXX also recommends that the token be allocated such that it
does not reveal any detail at all about the content of the PIDF-LO
that it may indirectly reference.
Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary
Barnes (mary.barnes@nortel.com).
Author/Change controller: This scheme is registered under the IETF
tree. As such, IETF maintains change control.
References: RFC XXXX, GEOPRIV Location De-reference Protocol [24]
12. Contributors 12. Contributors
James Winterbottom, Martin Thomson and Barbara Stark are the authors James Winterbottom, Martin Thomson and Barbara Stark are the authors
of the original document, from which this WG document was derived. of the original document, from which this WG document was derived.
Their contact information is included in the Author's address Their contact information is included 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, Peter Blatherwick, Guy Caron, Martin Eric Arolick, Richard Barnes, Peter Blatherwick, Guy Caron, Martin
Dawson, Lisa Dusseault, Jerome Grenier, Ted Hardie, Neil Justusson, Dawson, Lisa Dusseault, Jerome Grenier, Ted Hardie, Neil Justusson,
Tat Lam, Marc Linsner, Patti McCalmont, Roger Marshall, Perry Tat Lam, Marc Linsner, Patti McCalmont, Roger Marshall, Perry
Prozeniuk, Carl Reed, Brian Rosen, John Schnizlein, Shida Schubert, Prozeniuk, Carl Reed, Brian Rosen, John Schnizlein, Shida Schubert,
Henning Schulzrinne, Ed Shrum, Doug Stuard, and Hannes Tschofenig. Henning Schulzrinne, Ed Shrum, Doug Stuard and Hannes Tschofenig.
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 03 to 04:
1) Terminology: clarified in terminology section that "attribute" and
"element" are used in the strict XML sense and "parameter" is used as
a general protocol term Replaced term "HTTP delivery" with "HTTP
transport". Still have two terms "HTTP transport" and "HTTP
binding", but those are consistent with general uses of HTTP.
2) Editorial changes and clarifications: per Roger Marshall's and
Eric Arolick's comments and subsequent WG mailing list discussion.
3) Changed normative language for describing expected and recommended
LIS behaviors to be non-normative recommendations in cases where the
protocol parameters were not the target of the discussion (e.g., we
can't prescribe to the LIS how it determines location or what it
defines to be an "accurate" location).
4) Clarified responseTime attribute (section 6.1). Changed type from
"decimal" to "nonNegativeInteger" in XML schema (section 7)
5) Updated Table 1 in section 6 to only include top-level parameters
and fixed some errors in that table (i.e., code for locationResponse)
and adding PIDF-LO to the table. Added a detailed section describing
PIDF-LO (section 6.6), moving some of the normative text in the
Protocol Overview to this section.
6) Added schema and description for locationURI to section 6.5.
Added IANA registration for HELD: URI schema.
7) Added IANA registry for error codes.
Changes from WG 02 to 03: Changes from WG 02 to 03:
1) Added text to address concern over use of IP address as device 1) Added text to address concern over use of IP address as device
identifier, per long email thread - changes to section 3 (overview) identifier, per long email thread - changes to section 3 (overview)
and section 4 (protocol overview). and section 4 (protocol overview).
2) Removed WSDL (section 8 updated, section 8.1 and 10.4 removed) 2) Removed WSDL (section 8 updated, section 8.1 and 10.4 removed)
3) Added extensibility to baseRequestType in the schema (an oversight 3) Added extensibility to baseRequestType in the schema (an oversight
from previous edits), along with fixing some other nits in schema from previous edits), along with fixing some other nits in schema
skipping to change at page 30, line 19 skipping to change at page 34, line 26
[6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [6] 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. [7] 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 [8] 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 [9] Thomson, M. and J. Winterbottom, "Revised Civic Location Format
for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-06 (work in for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-07 (work in
progress), October 2007. progress), December 2007.
[10] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [10] 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-10 (work
in progress), October 2007. in progress), October 2007.
[11] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location [11] 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-05 (work in progress), draft-ietf-geopriv-l7-lcp-ps-06 (work in progress),
September 2007. November 2007.
[12] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML [12] 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] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second [13] 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 [14] 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-thomson-geopriv-lis-discovery-03 (work in progress),
September 2007. September 2007.
[15] Marshall, R., "Requirements for a Location-by-Reference [15] Marshall, R., "Requirements for a Location-by-Reference
skipping to change at page 31, line 20 skipping to change at page 35, line 26
[17] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence [17] 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", [18] 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., [19] 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] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host [20] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[21] 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.
[21] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [22] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, Registration Procedures for New URI Schemes", BCP 115,
January 2005. RFC 4395, February 2006.
[22] Polk, J. and B. Rosen, "Location Conveyance for the Session [23] Polk, J. and B. Rosen, "Location Conveyance for the Session
Initiation Protocol", draft-ietf-sip-location-conveyance-08 Initiation Protocol", draft-ietf-sip-location-conveyance-09
(work in progress), July 2007. (work in progress), November 2007.
[23] TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media [24] Winterbottom, J., Tschofenig, H., Schulzrinne, H., Thomson, M.,
and M. Dawson, "An HTTPS Location Dereferencing Protocol Using
HELD", draft-winterbottom-geopriv-deref-protocol-00 (work in
progress), November 2007.
[25] 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 [11].
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
skipping to change at page 37, line 7 skipping to change at page 41, line 7
BellSouth BellSouth
Room 7A41 Room 7A41
725 W Peachtree St. 725 W Peachtree St.
Atlanta, GA 30308 Atlanta, GA 30308
US US
Email: barbara.stark@bellsouth.com Email: barbara.stark@bellsouth.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 76 change blocks. 
258 lines changed or deleted 466 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/