draft-ietf-geopriv-http-location-delivery-02.txt   draft-ietf-geopriv-http-location-delivery-03.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 30, 2008 Expires: May 20, 2008
September 27, 2007 November 17, 2007
HTTP Enabled Location Delivery (HELD) HTTP Enabled Location Delivery (HELD)
draft-ietf-geopriv-http-location-delivery-02.txt draft-ietf-geopriv-http-location-delivery-03.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 30, 2008. This Internet-Draft will expire on May 20, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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 either by-value or by-reference. The protocol
is an application-layer protocol that is independent of session- is an application-layer protocol that is independent of session-
layer; an HTTP, web services binding is specified. layer. This document describes the use of Hypertext Transfer
Protocol (HTTP) as a delivery mechanism 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 . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 7 4.1. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 7
5.1. Protocol Binding . . . . . . . . . . . . . . . . . . . . . 7 4.1.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 8
5.2. Location Request . . . . . . . . . . . . . . . . . . . . . 8 4.1.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 8
5.3. Location Response . . . . . . . . . . . . . . . . . . . . 8 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8
5.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 8 5.1. Delivery Protocol . . . . . . . . . . . . . . . . . . . . 9
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 8 5.2. Location Request . . . . . . . . . . . . . . . . . . . . . 9
6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 9 5.3. Location Response . . . . . . . . . . . . . . . . . . . . 10
6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 10 5.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 10
6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 10 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10
6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 11 6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11
6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 11 6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 11
6.5. "locationURI" Parameter . . . . . . . . . . . . . . . . . 11 6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 12
6.5.1. "expires" Parameter . . . . . . . . . . . . . . . . . 12 6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 12
7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 13
8. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.5. "locationURI" Parameter . . . . . . . . . . . . . . . . . 13
8.1. HTTP Binding WSDL . . . . . . . . . . . . . . . . . . . . 16 6.5.1. "expires" Parameter . . . . . . . . . . . . . . . . . 13
7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9.1. Return Routability . . . . . . . . . . . . . . . . . . . . 18 9.1. Return Routability . . . . . . . . . . . . . . . . . . . . 18
9.2. Transaction Layer Security . . . . . . . . . . . . . . . . 19 9.2. Transaction Layer Security . . . . . . . . . . . . . . . . 19
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Simple HTTP Binding Example Messages . . . . . . . . . . . 19 10.1. HTTP Example Messages . . . . . . . . . . . . . . . . . . 19
10.2. Simple Location Request Example . . . . . . . . . . . . . 22 10.2. Simple Location Request Example . . . . . . . . . . . . . 22
10.3. Location Request Example for Multiple Location Types . . . 23 10.3. Location Request Example for Multiple Location Types . . . 23
10.4. Sample LIS WSDL Document . . . . . . . . . . . . . . . . 24 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11.1. URN Sub-Namespace Registration for 11.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 25 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 24
11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 25 11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 25
11.3. URN Sub-Namespace Registration for 11.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:http . . . . . . . . . 25 urn:ietf:params:xml:ns:geopriv:held:http . . . . . . . . . 25
11.4. MIME Media Type Registration for 'application/held+xml' . 26 11.4. MIME Media Type Registration for 'application/held+xml' . 26
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
14. Changes since last Version . . . . . . . . . . . . . . . . . . 27 14. Changes since last Version . . . . . . . . . . . . . . . . . . 27
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
15.1. Normative References . . . . . . . . . . . . . . . . . . . 29 15.1. Normative References . . . . . . . . . . . . . . . . . . . 29
15.2. Informative References . . . . . . . . . . . . . . . . . . 30 15.2. Informative References . . . . . . . . . . . . . . . . . . 31
Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 31 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 31
A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 31 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 31
A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 31 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 32
A.3. L7-3: ASP and Access Network Provider Relationship . . . . 32 A.3. L7-3: ASP and Access Network Provider Relationship . . . . 32
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 32 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 33
A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 32 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 33
A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 33 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 33
A.7. L7-7: Network Access Authentication . . . . . . . . . . . 33 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 34
A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 33 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 34
A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 34 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 34
A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 34 A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . . . . 37
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 a Device might rely on its access network to
provide the location information, such as fixed environments (e.g., provide the location information, such as fixed environments (e.g.,
DSL/Cable), mobile networks and wireless access networks. This DSL/Cable), mobile networks and wireless access networks. This
document describes a protocol that can be used to acquire Location document describes a protocol that can be used to acquire Location
skipping to change at page 4, line 29 skipping to change at page 4, line 29
a literal location object describing the location of the Device. a literal location object describing the location of the Device.
Alternatively, the Device may request that the LIS provide a location Alternatively, the Device may request that the LIS provide a location
reference in the form of a location URI or set of location URIs, reference in the form of a location URI or set of location URIs,
allowing the Device to distribute its LI by-reference. Both of these allowing the Device to distribute its LI by-reference. Both of these
methods are compatible, and both can be provided concurrently from methods are compatible, and both can be provided concurrently from
the same LIS so that application needs can be addressed individually. the same LIS so that application needs can be addressed individually.
This specification defines an XML-based protocol that enables the This specification defines an XML-based protocol that enables the
retrieval of LI from a LIS by a Device. This protocol can be bound retrieval of LI from a LIS by a Device. This protocol can be bound
to any session-layer protocol, particularly those capable of MIME to any session-layer protocol, particularly those capable of MIME
transport; an HTTP binding is included as a minimum requirement. transport. This document describes the use of Hypertext Transfer
Protocol (HTTP) as a delivery mechanism 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),
skipping to change at page 6, line 4 skipping to change at page 6, line 30
+----------|---------------------'------------+ +----------|---------------------'------------+
| ' | '
| ' | '
HELD APP HELD APP
| ' | '
Rule Maker - _ +-----------+ +-----------+ Rule Maker - _ +-----------+ +-----------+
o - - | Device | | Location | o - - | Device | | Location |
<U\ | | - - - - | Recipient | <U\ | | - - - - | Recipient |
/ \ _ - - | | APP | | / \ _ - - | | APP | |
Target - - +-----------+ +-----------+ Target - - +-----------+ +-----------+
Figure 1: Significant Roles Figure 1: Significant Roles
The interface between the Location Recipient (LR) and the Device The interface between the Location Recipient (LR) and the Device
and/or LIS is application specific, as indicated by the APP and/or LIS is application specific, as indicated by the APP
annotation in the diagram and it is outside the scope of the annotation in the diagram and it is outside the scope of the
document. An example of an APP interface between a device and LR can document. An example of an APP interface between a device and LR can
be found in the SIP Location Conveyance document [22]. be found in the SIP Location Conveyance document [22].
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 LI either by-value, as a
PIDF-LO document, or by-reference, as a Location URI. The policy PIDF-LO document, or by-reference, as a Location URI. The policy
that describes to whom, and how, LI is granted is outside the scope that describes to whom, and how, LI is granted is outside the scope
of this document and may be specified in separate specifications as of this document and may be specified in separate specifications as
required. The Device must first discover the URI for the LIS for required. The Device must first discover the URI for the LIS for
sending the HELD protocol requests as identified by the requirement sending the HELD protocol requests as identified by the requirement
in the L7 LCP problem statement and requirements [11]. The discovery in the L7 LCP problem statement and requirements [11]. The discovery
methods are specified in [15]. methods are specified in [14].
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. With this approach, the LIS needs to uniquely PIDF-LO document. The details on the information that may be
identify the Device within the access network. The source IP address included in the PIDF-LO MUST follow the subset of those rules
of the request message is sufficient in most cases. Once the Device relating to the construction of the "location-info" element in the
is identified, the LIS uses network domain-specific information to PIDF-LO Usage Clarification, Considerations and Recommendations
determine the location of the Device. document [10]. The LIS MUST follow those rules in generating the
PIDF-LO in this case. Per the GEOPRIV Location Object format
The details on the information that may be included in the PIDF-LO specified in [8], the "entity" element MUST reflect the Target of the
MUST follow the subset of those rules relating to the construction of Location Information. In addition, the default values for
the "location-info" element in the PIDF-LO Usage Clarification, <retransmission-allowed> and <retention-expiry> as specified in [8]
Considerations and Recommendations document [10]. The LIS MUST MUST be applied. A default value of "no" SHALL be used for the
follow those rules in generating the PIDF-LO in this case. Per the <retransmission-allowed> element. A default value of 24 hours SHALL
GEOPRIV Location Object format specified in [8], the "entity" element be used for <retention-expiry> value of any generated PIDF-LO
MUST reflect the Target of the Location Information. In addition, documents. A LIS MAY provide a shorter value for <retention-expiry>
the default values for <retransmission-allowed> and <retention- but MUST NOT provide a value longer than 24 hours.
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 [21] 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 [16]. approach are discussed in [15].
4.1. Device Identifiers, NAT and VPNs
Use of the HELD protocol is subject to the viability of the
identifier used by the LIS to determine location. As described in
Section 3, this document describes the use of the IP address of the
Device as the identifier. When Network Address Translation (NAT), a
Virtual Private Network (VPN) or other forms of address modification
occur between the Device and the LIS, the location returned could be
inaccurate.
This is not always the case. For example, a NAT used in a
residential Local Area Network (LAN) is typically not a problem. The
external IP address used on the Wide Area Network (WAN) side of the
NAT is an acceptable identifier for all of the devices in the
residence since the covered geographical area is small.
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
not be the right address to identify the location of the Device.
4.1.1. Devices and VPNs
To minimize the impact of VPNs, Devices SHOULD perform their HELD
query prior to establishing a VPN tunnel. It is RECOMMENDED that
discovery [14] and an initial query are performed before establishing
the VPN.
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
other devices. Devices within the closed network are not necessarily
able to detect the presence of the VPN and are reliant on the VPN
device. To this end, a VPN 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
location configuration options such as Dynamic Host Configuration
Protocol (DHCP)[20] or Link Layer Discovery Protocol - Media Endpoint
Discovery (LLDP-MED) [23]. VPN devices that act as a LIS MAY acquire
their own location using HELD.
4.1.2. LIS Handling of NATs and VPNs
A LIS MUST NOT provide location information to a Device if it cannot
provide accurate information. This applies where the Device uses a
VPN connection or is behind a NAT that serves a large geographic area
or multiple geographic locations (for example, a NAT used by an
enterprise to connect their private network to the Internet). The
LIS needs to be configured to recognize identifiers that represent
these conditions.
LIS operators have a large role in ensuring the best possible
environment for location determination. The LIS operator needs to
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
a NAT or VPN a LIS needs to have a presence on the side of the NAT or
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 a Location or a Location URI from a LIS. Three messages are
defined to support the location retrieval: locationRequest, defined to support the location retrieval: locationRequest,
locationResponse and error. Messages are defined as XML documents. 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 a Location (and the specific type of location) and/or a
Location URI should be returned. The LIS replies with a response Location URI should be returned. The LIS replies with a response
(locationResponse), including a PIDF-LO document and/or one or more (locationResponse), including a PIDF-LO document and/or one or more
Location URIs in case of success, or an error message in case of an Location URIs in case of success, or an error message in case of an
error. 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.4 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 [19], 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].
5.1. Protocol Binding 5.1. Delivery Protocol
The HELD protocol is an application-layer protocol that is defined The HELD protocol is an application-layer protocol that is defined
independently of any lower layers. This means that any protocol can independently of any lower layers. This means that any protocol can
be used to transport this protocol providing that it can provide a be used to transport this protocol providing that it can provide a
few basic features: few basic features:
o The protocol must have acknowledged delivery. o The protocol must have acknowledged delivery.
o The protocol must be able to correlate a response with a request. o The protocol must be able to correlate a response with a request.
o The protocol must provide authentication, privacy and protection o The protocol must provide authentication, privacy and protection
against modification. against modification.
This document includes a binding that uses a combination of HTTP [3], This document describes the use of a combination of HTTP [3], TLS [2]
TLS [2] and TCP [17] in Section 8. and TCP [16] in Section 8 .
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
skipping to change at page 8, line 28 skipping to change at page 10, line 14
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 either a PIDF-LO
and/or Location URI(s), depending upon the requested "locationType". and/or Location URI(s), depending upon the requested "locationType".
A Location URI MUST NOT contain any information that could be used to
identify the Device or Target. It is RECOMMENDED that a Location URI
contain a public address for the LIS and an anonymous identifier,
such as a local identifer or unlinked pseudonym.
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
Section 6.3. Section 6.3.
skipping to change at page 9, line 29 skipping to change at page 11, line 12
| locationURI | | o | | | locationURI | | o | |
| (Section 6.5) | | | | | (Section 6.5) | | | |
| expires | | m | | | expires | | m | |
| (Section 6.5.1) | | | | | (Section 6.5.1) | | | |
+------------------------+----------------+-----------------+-------+ +------------------------+----------------+-----------------+-------+
Table 1: Message Parameter Usage Table 1: Message Parameter Usage
6.1. "responseTime" Parameter 6.1. "responseTime" Parameter
The "responseTime" attribute is optional and indicates to the LIS how The "responseTime" parameter is optional and indicates to the LIS how
long the Device is prepared to wait for a response and/or the purpose long the Device is prepared to wait for a response and/or the purpose
for which the Device needs the location. In the case of emergency for which the Device needs the location. In the case of emergency
services, the purpose of obtaining the LI could be either for routing services, the purpose of obtaining the LI could be either for routing
a call to the appropriate PSAP or indicating the location to which a call to the appropriate PSAP or indicating the location to which
responders should be dispatched. The time values defined for those responders should be dispatched. The time values defined for those
purposes, emergencyRouting and emergencyDispatch, will likely be purposes, emergencyRouting and emergencyDispatch, will likely be
governed by jurisdictional policies, and SHOULD be configurable on governed by jurisdictional policies, and SHOULD be configurable on
the LIS. the LIS.
The value of the time attribute is indicative only and the LIS is The value of the "responseTime" parameter is indicative only and the
under no obligation to strictly adhere to the time limit implied; any LIS is under no obligation to strictly adhere to the time limit
enforcement of the time limit is left to the requesting Device. The implied; any enforcement of the time limit is left to the requesting
time attribute is expressed with a decimal seconds value, which may Device. The "responseTime" parameter is expressed with a decimal
include a decimal point. It is RECOMMENDED that systems support seconds value, which may include a decimal point. It is RECOMMENDED
millisecond precision for this parameter. The LIS SHOULD provide the that systems support millisecond precision for this parameter. The
most accurate LI that can be determined within the specified interval LIS SHOULD provide the most accurate LI that can be determined within
for the specific service. the specified interval for the specific service.
The LIS MAY use the value of the "responseTime" attribute as input The LIS MAY use the value of the "responseTime" parameter as input
when selecting the method of location determination, where multiple when selecting the method of location determination, where multiple
such methods exist. If this parameter is absent, then the LIS MUST such methods exist. If this parameter is absent, then the LIS MUST
return the most precise LI it is capable of determining. return the most precise LI it is capable 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 any: The LIS SHOULD attempt to provide LI in all forms available to
it. This value MUST be assumed as the default if no it. This value MUST be assumed as the default if no
"locationType" is specified. The LIS SHOULD return location "locationType" is specified. The LIS SHOULD return location
information in a form that is suited for routing and responding to information in a form that is suited for routing and responding to
skipping to change at page 12, line 6 skipping to change at page 13, line 43
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" A "locationResponse" message MAY contain any number of "locationURI"
elements. It is RECOMMENDED that the LIS allocate a Location URI for elements. It is RECOMMENDED that the LIS allocate a Location URI for
each scheme that it supports and that each scheme is present only each scheme that it supports and that each scheme is present only
once. URI schemes and their secure variants such as http and https once. URI schemes and their secure variants such as http and https
MUST be regarded as two separate schemes. MUST be regarded as two separate schemes.
A "locationURI" MUST NOT contain any information that could be used
to identify the Device or Target. It is RECOMMENDED that a
"locationURI" contain a public address for the LIS and an anonymous
identifier, such as a local identifer or unlinked pseudonym.
6.5.1. "expires" Parameter 6.5.1. "expires" Parameter
The "expires" attribute indicates the time at which the Location URI The "expires" attribute is optional and is only included in a
provided by the LIS will expire. This attribute is included in the "locationResponse" message when a Location URI is included. The
"locationResponse" message only. "expires" attribute indicates the time at which the Location URI
provided by the LIS will expire.
Responses to Locations requests for Location URIs MUST include the Responses to Locations requests for Location URIs MUST include the
expiry time of the Location URI. expiry time of the Location URI.
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"?>
<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:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:cp="urn:ietf:params:xml:ns:common-policy"
xmlns:gml="http://www.opengis.net/gml"
xmlns:xml="http://www.w3.org/XML/1998/namespace" xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xs:annotation> <xs:annotation>
<xs:documentation source="https://www.ietf.org/rfc/rfcXXXX.txt"> <xs:documentation source="https://www.ietf.org/rfc/rfcXXXX.txt">
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of <!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
published RFC and remove this note.]] --> published RFC and remove this note.]] -->
This document defines HELD messages. This document defines HELD messages.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:import namespace="http://www.w3.org/XML/1998/namespace" <xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
schemaLocation="xml.xsd"/>
<xs:import namespace="urn:ietf:params:xml:ns:pidf:geopriv10"
schemaLocation="geopriv10.xsd"/>
<xs:import
namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
schemaLocation="civicAddress.xsd"/>
<xs:import namespace="http://www.opengis.net/gml"
schemaLocation="GML-3.1.1/base/geometryBasic2d.xsd"/>
<!-- Return Location --> <!-- Return Location -->
<xs:complexType name="returnLocationType"> <xs:complexType name="returnLocationType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence> <xs:sequence>
<xs:element name="locationURI" type="xs:anyURI" <xs:element name="locationURI" type="xs:anyURI"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="expires" type="xs:dateTime" <xs:attribute name="expires" type="xs:dateTime"
skipping to change at page 14, line 41 skipping to change at page 16, line 24
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<!-- Message Definitions --> <!-- Message Definitions -->
<xs:complexType name="baseRequestType"> <xs:complexType name="baseRequestType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence/> <xs:sequence/>
<xs:attribute name="responseTime" type="held:responseTimeType" <xs:attribute name="responseTime" type="held:responseTimeType"
use="optional"/> use="optional"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:complexType name="errorType"> <xs:complexType name="errorType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence/> <xs:sequence/>
<xs:attribute name="code" type="held:codeType" <xs:attribute name="code" type="held:codeType"
use="required"/> use="required"/>
skipping to change at page 15, line 31 skipping to change at page 17, line 16
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:element name="locationResponse" <xs:element name="locationResponse"
type="held:locationResponseType"/> type="held:locationResponseType"/>
<!-- Location Request -->
<xs:complexType name="locationRequestType"> <xs:complexType name="locationRequestType">
<xs:complexContent> <xs:complexContent>
<xs:extension base="held:baseRequestType"> <xs:extension base="held:baseRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="locationType" <xs:element name="locationType"
type="held:locationTypeType" type="held:locationTypeType"
minOccurs="0"/> minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
skipping to change at page 16, line 7 skipping to change at page 17, line 39
</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 defines an HTTP [3] binding for this protocol, which all This section describes the use of HTTP [3] as a delivery mechanism
conforming implementations MUST support. This binding takes the form for this protocol, which all conforming implementations MUST support.
of a Web Service (WS) that can be described by the Web Services
Description Language (WSDL) document in Section 8.1.
The request is carried in this binding as the body of an HTTP POST The request is carried in the body of an HTTP POST request. The MIME
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.
This binding also includes a default behaviour, which is triggered by The use of HTTP also includes a default behaviour, which is triggered
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.
This binding MUST use TLS as described in [4]. TLS provides message The implementation of HTTP as a delivery mechanism MUST implement TLS
integrity and privacy between Device and LIS. The LIS MUST use the as described in [4]. TLS provides message integrity and privacy
server authentication method described in [4]; the Device MUST fail a between Device and LIS. The LIS MUST use the server authentication
request if server authentication fails, except in the event of an method described in [4]; the Device MUST fail a request if server
emergency. authentication fails, except in the event of an emergency.
8.1. HTTP Binding WSDL
The following WSDL 2.0 [23] document describes the HTTP binding for
this protocol. Actual service instances MUST provide a "service"
with at least one "endpoint" that implements the "heldHTTP" binding.
A service description document MAY include this schema directly or by
using the "import" or "include" directives.
<?xml version="1.0"?>
<wsdl:definitions
xmlns:wsdl="http://www.w3.org/2005/05/wsdl"
xmlns:whttp="http://www.w3.org/2005/05/wsdl/http"
xmlns:held="urn:ietf:params:xml:ns:geopriv:held"
xmlns:pidf="urn:ietf:params:xml:ns:pidf"
xmlns:heldhttp="urn:ietf:params:xml:ns:geopriv:held:http"
targetNamespace="urn:ietf:params:xml:ns:geopriv:held:http"
type="http://www.w3.org/2005/05/wsdl/http">
<wsdl:documentation>
This document describes the basic HELD sighting web service.
Please refer to RFCXXXX for details.
[[NOTE TO RFC-EDITOR: Please replace XXXX with the RFC number
for this specification and remove this note.]]
</wsdl:documentation>
<wsdl:types>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:import namespace="urn:ietf:params:xml:ns:geopriv:held"
schemaLocation="held.xsd"/>
<xsd:import namespace="urn:ietf:params:xml:ns:pidf"/>
</xsd:schema>
</wsdl:types>
<wsdl:interface name="held">
<wsdl:operation name="locationRequest" method="POST">
<wsdl:input message="held:locationRequest"/>
<wsdl:output message="held:locationResponse"/>
<wsdl:fault message="held:error"/>
</wsdl:operation>
<wsdl:operation
name="getLocation" method="GET"
pattern="http://www.w3.org/2004/08/wsdl/out-only">
<wsdl:output message="held:locationResponse"/>
<wsdl:fault message="held:error"/>
</wsdl:operation>
</wsdl:interface>
<wsdl:binding name="heldHTTP" whttp:defaultMethod="POST">
<wsdl:operation
whttp:inputSerialization="application/held+xml"
whttp:outputSerializatiom="application/held+xml"
whttp:faultSerialization="application/held+xml"
ref="heldhttp:locationRequest"/>
<wsdl:operation
whttp:inputSerialization="application/held+xml"
whttp:outputSerializatiom="application/held+xml"
whttp:faultSerialization="application/held+xml"
ref="heldhttp:getLocation" whttp:method="GET"/>
</wsdl:binding>
</wsdl:definitions>
9. Security Considerations 9. Security Considerations
The threat model for this protocol assumes that the LIS exists within The threat model for this protocol assumes that the LIS exists within
the same administrative domain as the Device. The LIS requires the same administrative domain as the Device. The LIS requires
access to network information so that it can determine Location. access to network information so that it can determine Location.
Therefore, the LIS can use network information to protect against a Therefore, the LIS can use network information to protect against a
number of the possible attacks. 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 [16]. in [15].
9.1. Return Routability 9.1. Return Routability
It is RECOMMENDED that Location Information Servers use return It is RECOMMENDED that Location Information Servers use return
routability rather than requiring Device authentication. Device routability rather than requiring Device authentication. Device
authentication SHOULD NOT be required due to the administrative authentication SHOULD NOT be required due to the administrative
challenge of issuing and managing of client credentials, particularly challenge of issuing and managing of client credentials, particularly
when networks allow visiting users to attach devices. However, the when networks allow visiting users to attach devices. However, the
LIS MAY require any form of authentication as long as these factors LIS MAY require any form of authentication as long as these factors
are considered. are considered.
skipping to change at page 19, line 23 skipping to change at page 19, line 41
Bindings MUST also provide a means of authenticating the LIS. Bindings MUST also provide a means of authenticating the LIS.
It is RECOMMENDED that all bindings also use TLS [2]. It is RECOMMENDED that all bindings also use TLS [2].
For the HTTP binding, TLS MUST be used. TLS provides protection For the HTTP binding, TLS MUST be used. TLS provides protection
against eavesdropping and modification. The server authentication against eavesdropping and modification. The server authentication
methods described in HTTP on TLS [4] MUST be used. methods described in HTTP on TLS [4] MUST be used.
10. Examples 10. Examples
10.1. Simple HTTP Binding Example Messages 10.1. HTTP Example Messages
The examples in this section show a complete HTTP message that The examples in this section show a complete HTTP message that
includes the HELD request or response document. includes the HELD request or response document.
This example shows the most basic request for a LO. This uses the This example shows the most basic request for a LO. This uses the
GET feature described by the HTTP binding. This example assumes that GET feature described by the HTTP binding. This example assumes that
the LIS service exists at the URL "https://lis.example.com/location". the LIS service exists at the URL "https://lis.example.com/location".
GET /location HTTP/1.1 GET /location HTTP/1.1
Host: lis.example.com Host: lis.example.com
skipping to change at page 24, line 26 skipping to change at page 24, line 26
</retention-expiry> </retention-expiry>
</usage-rules> </usage-rules>
<method>Wiremap</method> <method>Wiremap</method>
</geopriv> </geopriv>
</status> </status>
<timestamp>2007-05-24T12:35:02+10:00</timestamp> <timestamp>2007-05-24T12:35:02+10:00</timestamp>
</tuple> </tuple>
</presence> </presence>
</locationResponse> </locationResponse>
10.4. Sample LIS WSDL Document
The following WSDL document demonstrates how a WSDL document can be
created for a specific service, in this case, a service at the URI
"https://lis.example.com/location".
<?xml version="1.0"?>
<wsdl:definitions
xmlns:wsdl="http://www.w3.org/2005/05/wsdl"
xmlns:heldhttp="urn:ietf:params:xml:ns:geopriv:held:http"
targetNamespace="http://lis.example.com/ws/held">
<wsdl:import
namespace="urn:ietf:params:xml:ns:geopriv:held:http"/>
<wsdl:service name="sample-held-svc" interface="heldhttp:held">
<wsdl:endpoint name="sample-held-ep"
binding="heldhttp:heldHTTP"
address="https://lis.example.com/location"/>
</wsdl:service>
</wsdl:definitions>
11. IANA Considerations 11. IANA Considerations
This document registers an XML namespace and schema and the This document registers an XML namespace and schema and the
"application/held+xml" MIME type. "application/held+xml" MIME type.
11.1. URN Sub-Namespace Registration for 11.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held urn:ietf:params:xml:ns:geopriv:held
This section registers a new XML namespace, This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:held", as per the guidelines in [6]. "urn:ietf:params:xml:ns:geopriv:held", as per the guidelines in [6].
skipping to change at page 26, line 41 skipping to change at page 26, line 36
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type application/held+xml Subject: Registration of MIME media type application/held+xml
MIME media type name: application MIME media type name: application
MIME subtype name: held+xml MIME subtype name: held+xml
Required parameters: (none) Required parameters: (none)
Optional parameters: charset Optional parameters: charset
Indicates the character encoding of enclosed XML. Default is Indicates the character encoding of enclosed XML. Default is
UTF-8. UTF-8.
Encoding considerations: Uses XML, which can employ 8-bit Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See RFC characters, depending on the character encoding used. See RFC
3023 [19], section 3.2. 3023 [18], section 3.2.
Security considerations: This content type is designed to carry Security considerations: This content type is designed to carry
protocol data related to the location of an entity, which could protocol data related to the location of an entity, which could
include information that is considered private. Appropriate include information that is considered private. Appropriate
precautions should be taken to limit disclosure of this precautions should be taken to limit disclosure of this
information. information.
Interoperability considerations: This content type provides a basis Interoperability considerations: This content type provides a basis
for a protocol for a protocol
Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number for this specification.]] replace XXXX with the RFC number for this specification.]]
Applications which use this media type: Location information Applications which use this media type: Location information
providers and consumers. providers and consumers.
Additional Information: Magic Number(s): (none) Additional Information: Magic Number(s): (none)
File extension(s): .xml File extension(s): .xml
Macintosh File Type Code(s): (none) Macintosh File Type Code(s): (none)
Person & email address to contact for further information: Mary Person & email address to contact for further information: Mary
Barnes <mary.barnes@nortel.com> Barnes <mary.barnes@nortel.com>
Intended usage: LIMITED USE Intended usage: LIMITED USE
Author/Change controller: This specification is TBD Author/Change controller: This specification is TBD
Other information: This media type is a specialization of Other information: This media type is a specialization of
application/xml [19], 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.
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, in section. In addition, they also contributed to the WG document,
particular the schema and WSDL. including the XML schema.
13. Acknowledgements 13. Acknowledgements
The author/contributors would like to thank the following people for The author/contributors would like to thank the participants in the
their constructive input to this document (in alphabetical order): GEOPRIV WG and the following people for their constructive input and
Nadine Abbott, Eric Arolick, Guy Caron, Martin Dawson, Jerome feedback on this document (in alphabetical order): Nadine Abbott,
Grenier, Neil Justusson, Tat Lam, Patti McCalmont, Perry Prozeniuk, Eric Arolick, Richard Barnes, Peter Blatherwick, Guy Caron, Martin
Carl Reed, John Schnizlein, Shida Schubert, Henning Schulzrinne, Ed Dawson, Lisa Dusseault, Jerome Grenier, Ted Hardie, Neil Justusson,
Shrum, and Hannes Tschofenig. Tat Lam, Marc Linsner, Patti McCalmont, Roger Marshall, Perry
Prozeniuk, Carl Reed, Brian Rosen, John Schnizlein, Shida Schubert,
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 02 to 03:
1) Added text to address concern over use of IP address as device
identifier, per long email thread - changes to section 3 (overview)
and section 4 (protocol overview).
2) Removed WSDL (section 8 updated, section 8.1 and 10.4 removed)
3) Added extensibility to baseRequestType in the schema (an oversight
from previous edits), along with fixing some other nits in schema
(section 7)
4) Moved discussion of Location URI from section 5.3 (Location
Response) to where it rightly belonged in Section 6.5 (Location URI
Parameter).
5) Clarified text for "expires" parameter (6.5.1) - it's an optional
parm, but required for LocationURIs
6) Clarified responseTime parameter: when missing, then the LCS
provides most precise LI, with the time required being implementation
specific.
7) Clarified that the MUST use in section 8 (HTTP binding) is a MUST
implement.
8) Updated references (removed unused/added new).
Changes from WG 01 to 02: Changes from WG 01 to 02:
1) Updated Terminology to be consistent with WG agreements and other 1) Updated Terminology to be consistent with WG agreements and other
documents (e.g., LCS -> LIS and removed duplicate terms). In the documents (e.g., LCS -> LIS and removed duplicate terms). In the
end, there are no new terms defined in this document. end, there are no new terms defined in this document.
2) Modified definition of responseTime to reflect WG consensus. 2) Modified definition of responseTime to reflect WG consensus.
3) Removed jurisdictionalCivic and postalCivic locationTypes (leaving 3) Removed jurisdictionalCivic and postalCivic locationTypes (leaving
just "civic"). just "civic").
skipping to change at page 29, line 43 skipping to change at page 30, line 19
[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-05 (work in for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-06 (work in
progress), February 2007. progress), October 2007.
[10] Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification, [10] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Considerations and Recommendations", PIDF-LO Usage Clarification, Considerations and
draft-ietf-geopriv-pdif-lo-profile-08 (work in progress), Recommendations", draft-ietf-geopriv-pdif-lo-profile-10 (work
July 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-05 (work in progress),
September 2007. September 2007.
[12] Thompson, H., Mendelsohn, N., Maloney, M., and D. Beech, "XML [12] Thompson, H., Beech, D., Maloney, M., 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] Malhotra, A. and P. Biron, "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] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, [14] Thomson, M. and J. Winterbottom, "Discovering the Local
"Geographic information - Geography Markup Language (GML)",
OpenGIS 03-105r1, April 2004,
<http://portal.opengeospatial.org/files/?artifact_id=4700>.
[15] 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.
[16] Marshall, R., "Requirements for a Location-by-Reference [15] Marshall, R., "Requirements for a Location-by-Reference
Mechanism", draft-ietf-geopriv-lbyr-requirements-00 (work in Mechanism", draft-ietf-geopriv-lbyr-requirements-01 (work in
progress), September 2007. progress), October 2007.
15.2. Informative References 15.2. Informative References
[17] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [16] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
[18] 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.
[19] 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.
[20] 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
Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004.
[21] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [21] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005. January 2005.
[22] Polk, J. and B. Rosen, "Location Conveyance for the Session [22] 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-08
(work in progress), July 2007. (work in progress), July 2007.
[23] Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, "Web [23] TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
Services Description Language (WSDL) Version 2.0 Part 1: Core Endpoint Discovery".
Language", W3C CR CR-wsdl20-20060106, January 2006.
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
define an identifier that is mandatory to implement. Regarding the define an identifier that is mandatory to implement. Regarding the
skipping to change at page 34, line 17 skipping to change at page 34, line 42
require that the device know its external IP address, except where require that the device know its external IP address, except where
that is required for discovery of the LIS. that is required for discovery of the LIS.
A.9. L7-9: Discovery Mechanism A.9. L7-9: Discovery Mechanism
"The L7 LCP MUST define a single mandatory to implement discovery "The L7 LCP MUST define a single mandatory to implement discovery
mechanism." mechanism."
COMPLY COMPLY
HELD uses the discovery mechanism in [15]. HELD uses the discovery mechanism in [14].
A.10. L7-10: PIDF-LO Creation A.10. L7-10: PIDF-LO Creation
"When a LIS creates a PIDF-LO per RFC 4119 then it MUST put the "When a LIS creates a PIDF-LO per RFC 4119 then it MUST put the
<geopriv> element into the <device> element of the presence document <geopriv> element into the <device> element of the presence document
(see RFC 4479). This ensures that the resulting PIDF-LO document, (see RFC 4479). This ensures that the resulting PIDF-LO document,
which is subsequently distributed to other entities, conforms to the which is subsequently distributed to other entities, conforms to the
rules outlined in ". [10] rules outlined in ". [10]
COMPLY COMPLY
HELD protocol overview (Section 4 ) describes the requirements on the HELD protocol overview (Section 4 ) describes the requirements on the
LIS in creating the PIDF-LO and prescribes that the PIDF-LO generated LIS in creating the PIDF-LO and prescribes that the PIDF-LO generated
by the LIS MUST conform to [10]. by the LIS MUST conform to [10].
Authors' Addresses Authors' Addresses
Mary Barnes (editor) Mary Barnes (editor)
Nortel Nortel
 End of changes. 60 change blocks. 
229 lines changed or deleted 222 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/