GEOPRIV WG M. Barnes, Ed.
Internet-Draft Nortel
Intended status: Standards Track
Expires: July 17, 2008
January 14, 2008
HTTP Enabled Location Delivery (HELD)
draft-ietf-geopriv-http-location-delivery-04.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 17, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
A Layer 7 Location Configuration Protocol (L7 LCP) is described that
is used for retrieving location information from a server within an
access network. The protocol includes options for retrieving
location information in two forms: by-value and by-reference. The
protocol is an extensible application-layer protocol that is
independent of session-layer. This document describes the use of
Barnes, et al. Expires July 17, 2008 [Page 1]
Internet-Draft HELD January 2008
Hypertext Transfer Protocol (HTTP) as a transport for the protocol.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4
3. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Location by Value . . . . . . . . . . . . . . . . . . . . 7
4.2. Location by Reference . . . . . . . . . . . . . . . . . . 7
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.1. Delivery Protocol . . . . . . . . . . . . . . . . . . . . 9
5.2. Location Request . . . . . . . . . . . . . . . . . . . . . 9
5.3. Location Response . . . . . . . . . . . . . . . . . . . . 10
5.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 10
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10
6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11
6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 11
6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 12
6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 12
6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 13
6.5. "locationURI" Parameter . . . . . . . . . . . . . . . . . 13
6.5.1. "expires" Parameter . . . . . . . . . . . . . . . . . 14
6.6. "pidf-LO" Parameter . . . . . . . . . . . . . . . . . . . 15
7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9.1. Return Routability . . . . . . . . . . . . . . . . . . . . 20
9.2. Transaction Layer Security . . . . . . . . . . . . . . . . 21
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. HTTP Example Messages . . . . . . . . . . . . . . . . . . 21
10.2. Simple Location Request Example . . . . . . . . . . . . . 24
10.3. Location Request Example for Multiple Location Types . . . 25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
11.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 26
11.1.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . 26
11.1.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:http . . . . . . . 27
11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 28
11.3. MIME Media Type Registration for 'application/held+xml' . 28
11.4. Error code Registry . . . . . . . . . . . . . . . . . . . 29
11.5. URI Registration . . . . . . . . . . . . . . . . . . . . . 29
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30
Barnes, et al. Expires July 17, 2008 [Page 2]
Internet-Draft HELD January 2008
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
14. Changes since last Version . . . . . . . . . . . . . . . . . . 31
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
15.1. Normative References . . . . . . . . . . . . . . . . . . . 33
15.2. Informative References . . . . . . . . . . . . . . . . . . 35
Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 36
A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 36
A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 36
A.3. L7-3: ASP and Access Network Provider Relationship . . . . 37
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 37
A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 37
A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 38
A.7. L7-7: Network Access Authentication . . . . . . . . . . . 38
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
Barnes, et al. Expires July 17, 2008 [Page 3]
Internet-Draft HELD January 2008
1. Introduction
The location of a Device is information that is useful for a number
of applications. The L7 Location Configuration Protocol (LCP)
problem statement and requirements document [11] provides some
scenarios in which the Device might rely on its access network to
provide location information. The LIS service applies to access
networks employing both wired technology (e.g. DSL, Cable) and
wireless technology (e.g. WiMAX) with varying degrees of Device
mobility. This document describes a protocol that can be used to
acquire Location Information (LI) from a Location Information Server
(LIS) within an access network.
This specification identifies two types of location information that
may be retrieved from the LIS. Location may be retrieved from the
LIS by-value, that is, the Device may acquire a literal location
object describing the location of the Device. The Device may also
request that the LIS provide a location 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 methods can be
provided concurrently from the same LIS to accommodate application
requirements for different types of location information.
This specification defines an extensible XML-based protocol that
enables the retrieval of LI from a LIS by a Device. This protocol
can be bound to any session-layer protocol, particularly those
capable of MIME transport. This document describes the use of
Hypertext Transfer Protocol (HTTP) as a transport for the protocol.
2. Conventions & Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].
This document uses the terms (and their acronym forms) Access
Provider (AP), Location Information (LI), Location Object (LO),
Device, Target, Location Generator (LG), Location Recipient (LR),
Rule Maker (RM) and Rule Holder (RH) as defined in RFC 3693, GEOPRIV
Requirements [7] . The terms Location Information Server (LIS),
Access Network, Access Provider (AP) and Access Network Provider are
used in the same context as defined in the L7 LCP Problem statement
and Requirements document [11]. The usage of the terms, Civic
Location/Address and Geodetic Location follows the usage in many of
the referenced documents.
In describing the protocol, the terms "attribute" and "element" are
Barnes, et al. Expires July 17, 2008 [Page 4]
Internet-Draft HELD January 2008
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
This document describes an interface between a Device and a Location
Information Server (LIS). This document assumes that the LIS is
present within the same administrative domain as the Device (e.g.,
the access network). An Access Provider (AP) operates the LIS so
that Devices (and Targets) can retrieve LI. The LIS exists because
not all Devices are capable of determining LI, and because, even if a
device is able to determine its own LI, it may be more efficient with
assistance. This document does not specify how LI is determined.
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
that location determination technologies are generally designed to
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
for the end user's LI. Since revealing the location of the device
almost invariably reveals some information about the location of the
user of the device, the same level of privacy protection demanded by
a user is required for the device. This approach may require either
some additional assurances about the link between device and target,
or an acceptance of the limitation that unless the device requires
active user authentication, there is no guarantee that any particular
individual is using the device at that instant.
Barnes, et al. Expires July 17, 2008 [Page 5]
Internet-Draft HELD January 2008
The following diagram shows the logical configuration of some of the
functional elements identified in [7] and the LIS defined in [11] and
where this protocol applies, with the Rule Maker and Target
represented by the role of the Device.
+---------------------------------------------+
| Access Network Provider |
| |
| +--------------------------------------+ |
| | Location Information Server | |
| | | |
| | | |
| | | |
| | | |
| +------|---------------------'---------+ |
+----------|---------------------'------------+
| '
| '
HELD APP
| '
Rule Maker - _ +-----------+ +-----------+
o - - | Device | | Location |
<U\ | | - - - - | Recipient |
/ \ _ - - | | APP | |
Target - - +-----------+ +-----------+
Figure 1: Significant Roles
The interface between the Location Recipient (LR) and the Device
and/or LIS is application specific, as indicated by the APP
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
be found in the SIP Location Conveyance document [23].
4. Protocol Overview
The HELD protocol facilitates retrieval of location directly in the
form of a PIDF-LO document (by-value) and indirectly as a Location
URI (by-reference). The policy that describes to whom, and how, LI
is granted is outside the scope of this document and may be specified
in separate specifications as required. The Device must first
discover the URI for the LIS for sending the HELD protocol requests
as identified by the requirement in the L7 LCP problem statement and
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
Barnes, et al. Expires July 17, 2008 [Page 6]
Internet-Draft HELD January 2008
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
create a PIDF-LO document. This approach fits well with a
configuration whereby the device directly makes use of the provided
PIDF-LO document. 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]. Further detail is included in the detailed protocol
section of this document Section 6
4.2. Location by Reference
Requesting location directly does not always address the requirements
of an application. A Device can request a location URI instead of
literal location. A Location URI is a URI [20] of any scheme, which
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,
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
associated with the location URI. This issue is deemed out of scope
for this document. The merits and drawbacks of using a Location URI
approach are discussed in [15].
4.3. 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. 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.
Not all cases of NATs introduce inaccuracies in the returned
location. 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, 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,
for example for a teleworker, then the IP address seen by the LIS
might not be the right address to identify the location of the
Device.
Barnes, et al. Expires July 17, 2008 [Page 7]
Internet-Draft HELD January 2008
4.3.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. 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
inside a LAN or other closed network may serve as a LIS, that
implements the HELD protocol, for those other Devices. Devices
within the closed network are not necessarily able to detect the
presence of the VPN and rely on the VPN device. To this end, a VPN
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 serve as a LIS for other
location configuration options such as Dynamic Host Configuration
Protocol (DHCP)[21] or Link Layer Discovery Protocol - Media Endpoint
Discovery (LLDP-MED) [25]. VPN devices that serve as a LIS may
acquire their own location using HELD.
4.3.2. LIS Handling of NATs and VPNs
In the cases 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 may not be able to return
an accurate LI. If the LIS cannot determine an accurate LI, it
should not provide location information to the requesting device.
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
As discussed in Section 4, this protocol provides for the retrieval
of location in the form of a PIDF-LO document and/or Location URI(s)
from a LIS. Three messages are defined to support the location
retrieval: locationRequest, locationResponse and error. Messages are
defined as XML documents.
Barnes, et al. Expires July 17, 2008 [Page 8]
Internet-Draft HELD January 2008
The Location Request (locationRequest) message is described in
Section 5.2. A Location Request message from a Device indicates
whether location in the form of a PIDF-LO document (with specific
type(s) of location) and/or Location URI(s) should be returned. The
LIS replies with a response (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 error.
A MIME type "application/held+xml" is registered in Section 11.3 to
distinguish HELD messages from other XML document bodies. This
specification follows the recommendations and conventions described
in [18], including the naming convention of the type ('+xml' suffix)
and the usage of the 'charset' parameter.
Section 6 contains a more thorough description of the protocol
parameters, valid values, and how each should be handled. Section 7
contains a more specific definition of the structure of these
messages in the form of an XML Schema [12].
5.1. Delivery Protocol
The HELD protocol is an application-layer protocol that is defined
independently of any lower layers. This means that any protocol can
be used to transport this protocol providing that it can provide a
few basic features:
o The protocol must have acknowledged delivery.
o The protocol must be able to correlate a response with a request.
o The protocol must provide authentication, privacy and protection
against modification.
This document describes the use of a combination of HTTP [3], TLS [2]
and TCP [16] in Section 8 .
5.2. Location Request
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
the type of LI that is included in the "locationType" element.
The location request is made by sending a document formed of a
"locationRequest" element. The LIS uses the source IP address of the
location request message as the primary source of identity for the
requesting device or target. It is anticipated that other Device
identities may be provided through schema extensions. The successful
response to a location request message is a document formed of a
"locationResponse" element, unless the request fails, in which case
the LIS MUST provide an error indication document.
The LIS MUST ignore any part of a location request message that it
Barnes, et al. Expires July 17, 2008 [Page 9]
Internet-Draft HELD January 2008
does not understand.
5.3. Location Response
The response to a Location request MUST contain a PIDF-LO and/or
Location URI(s), depending upon the requested "locationType".
5.4. Indicating Errors
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
MUST also be sent in response to any unrecognized request.
An error indication document consists of an "error" element. The
"error" element MUST include a "code" attribute that indicates the
type of error. A set of predefined error codes are included in
Section 6.3.
Error responses MAY also include a "message" attribute that can
include additional information. This information SHOULD be for
diagnostic purposes only, and MAY be in any language. The language
of the message SHOULD be indicated with an "xml:lang" attribute.
6. Protocol Parameters
This section describes, in detail the parameters that are used for
this protocol. Table 1 lists the top-level components used within
the protocol and where they are mandatory or optional for each of the
messages.
+------------------------+----------------+-----------------+-------+
| Parameter | Location | Location | Error |
| | Request | Response | |
+------------------------+----------------+-----------------+-------+
| responseTime | o | | |
| (Section 6.1) | | | |
| locationType | o | | |
| (Section 6.2) | | | |
| code (Section 6.3) | | | m |
| message (Section 6.4) | | | o |
| locationURI | | o | |
| (Section 6.5) | | | |
| PIDF-LO (Section 6.6) | | o | |
+------------------------+----------------+-----------------+-------+
Table 1: Message Parameter Usage
Barnes, et al. Expires July 17, 2008 [Page 10]
Internet-Draft HELD January 2008
6.1. "responseTime" Parameter
The "responseTime" attribute MAY be included in a location request
message. The "responseTime" attribute includes a time value
indicating to the LIS how long the Device is prepared to wait for a
response and/or a purpose for which the Device needs the location.
In the case of emergency services, the purpose of obtaining the LI
could be either for routing a call to the appropriate PSAP or
indicating the location to which responders should be dispatched.
The values defined for the purpose, emergencyRouting and
emergencyDispatch, will likely be governed by jurisdictional
policies, and should be configurable on the LIS.
The time value in the "responseTime" attribute is expressed as a non-
negative integer in units of milliseconds. The time value is
indicative only and the LIS is under no obligation to strictly adhere
to the time limit implied; any enforcement of the time limit is left
to the requesting Device. The LIS should provide the most accurate
LI that can be determined within the specified interval for the
specific service.
The LIS may use the value of the time in the "responseTime" attribute
as input when selecting the method of location determination, where
multiple such methods exist. If the "responseTime" attribute is
absent, then the LIS should return the most precise LI it is capable
of determining, with the time interval being implementation
dependent.
6.2. "locationType" Parameter
The "locationType" element MAY be included in a location request
message. It contains a list of LI types that are requested by the
Device. The following list describes the possible values:
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.
civic: The LIS SHOULD return a civic address for the Target. Any
type of civic address may be returned.
locationURI: The LIS SHOULD return a location URI for the Target.
The LIS SHOULD return the requested location type or types. The LIS
MAY provide additional location types, or it MAY provide alternative
types if the request cannot be satisfied for a requested location
Barnes, et al. Expires July 17, 2008 [Page 11]
Internet-Draft HELD January 2008
type. A location URI provided by the LIS is a reference to the most
current available LI, and the Target Device should understand that it
is not a stable reference to a specific location. The location types
the LIS returns also depends on the setting of the optional "exact"
attribute, as described in the following section.
The "SHOULD"-strength requirement on this parameter is included to
allow for soft-failover. This enables a fixed client configuration
that prefers a specific location type without causing location
requests to fail when that location type is unavailable. 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
unable to provide a civic address and thus provides a geodetic
address.
6.2.1. "exact" Attribute
The "exact" attribute MAY be included in a location request message
when the "locationType" element is included. When the "exact"
attribute is set to "true", it indicates to the LIS that the contents
of the "locationType" parameter MUST be strictly followed. The
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
the requested type or types or MUST provide an error. The LIS MUST
provide the requested types only. The LIS MUST handle an exact
request that includes a "locationType" element set to "any" as if the
"exact" attribute were set to "false".
6.3. "code" Parameter
All "error" responses MUST contain a response code. All errors are
application-level errors, and MUST only be provided in successfully
processed transport-level responses. For example where HTTP is used
as the transport, HELD error messages MUST be accompanied by a 200 OK
HTTP response.
HELD error responses may be one of the following tokens:
requestError: This code indicates that the request was badly formed
in some fashion.
Barnes, et al. Expires July 17, 2008 [Page 12]
Internet-Draft HELD January 2008
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".
6.4. "message" Parameter
The "error" message MAY include a "message" attribute to convey some
additional, human-readable information about the result of the
request. This message MAY be included in any language, which SHOULD
be indicated by the "xml:lang", attribute. The default language is
assumed to be English.
6.5. "locationURI" Parameter
The "locationURI" element includes a single Location URI. Each
Location URI that is allocated by the LIS is unique to the device
that is requesting it. A "locationResponse" message MAY contain any
number of "locationURI" elements.
The "locationURI" elements MUST be in the form of a HELD: URI, which
is defined following RFC3986 [20] and the associated URI Guidelines
[22] recommendations, per the following ABNF syntax:
HELD-URI = "held" ":" "//" [ location-id "@" ] host [ ":" port ]
[ path-absolute ] [ uri-extensions ]
location-id = token
uri-extensions = "?" extension *(COMMA extension)
extension = generic-param
generic-param = token [ EQUAL gen-value ]
gen-value = token / host / quoted-string
token = 1*(alphanum / "-" / "." / "!" / "%" / "*"
Barnes, et al. Expires July 17, 2008 [Page 13]
Internet-Draft HELD January 2008
/ "_" / "+" / "`" / "'" / "~" )
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
to identify the Device or Target. It is recommended that a
"locationURI" contain a public address for the LIS in the "host"
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
The "expires" attribute is only included in a "locationResponse"
message when a Location URI is included. The "expires" attribute
indicates the time at which the Location URI provided by the LIS will
Barnes, et al. Expires July 17, 2008 [Page 14]
Internet-Draft HELD January 2008
expire.
Responses to Location requests for Location URIs MUST include the
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
This section gives the XML Schema Definition [12] of the
"application/held+xml" format. This is presented as a formal
definition of the "application/held+xml" format. Note that the XML
Schema definition is not intended to be used with on-the-fly
validation of the presence XML document.
<?xml version="1.0"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:held="urn:ietf:params:xml:ns:geopriv:held"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
Barnes, et al. Expires July 17, 2008 [Page 15]
Internet-Draft HELD January 2008
<xs:annotation>
<xs:documentation source="https://www.ietf.org/rfc/rfcXXXX.txt">
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
published RFC and remove this note.]] -->
This document defines HELD messages.
</xs:documentation>
</xs:annotation>
<xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
<!-- Return Location -->
<xs:complexType name="returnLocationType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="locationURI" type="xs:anyURI"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="expires" type="xs:dateTime"
use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- responseTime Type -->
<xs:simpleType name="responseTimeType">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="emergencyRouting"/>
<xs:enumeration value="emergencyDispatch"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="xs:nonNegativeInteger">
<xs:minInclusive value="0"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<!-- Location Type -->
<xs:simpleType name="locationTypeBase">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="any"/>
</xs:restriction>
Barnes, et al. Expires July 17, 2008 [Page 16]
Internet-Draft HELD January 2008
</xs:simpleType>
<xs:simpleType>
<xs:list>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="civic"/>
<xs:enumeration value="geodetic"/>
<xs:enumeration value="locationURI"/>
</xs:restriction>
</xs:simpleType>
</xs:list>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:complexType name="locationTypeType">
<xs:simpleContent>
<xs:extension base="held:locationTypeBase">
<xs:attribute name="exact" type="xs:boolean"
use="optional" default="false"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<!-- Response code -->
<xs:simpleType name="codeType">
<xs:restriction base="xs:token">
<xs:enumeration value="requestError"/>
<xs:enumeration value="xmlError"/>
<xs:enumeration value="generalLisError"/>
<xs:enumeration value="locationUnknown"/>
<xs:enumeration value="unsupportedMessage"/>
<xs:enumeration value="timeout"/>
<xs:enumeration value="cannotProvideLiType"/>
</xs:restriction>
</xs:simpleType>
<!-- Message Definitions -->
<xs:complexType name="baseRequestType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence/>
<xs:attribute name="responseTime" type="held:responseTimeType"
use="optional"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
Barnes, et al. Expires July 17, 2008 [Page 17]
Internet-Draft HELD January 2008
</xs:complexContent>
</xs:complexType>
<xs:complexType name="errorType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence/>
<xs:attribute name="code" type="held:codeType"
use="required"/>
<xs:attribute name="message" type="xs:token"
use="optional"/>
<xs:attribute ref="xml:lang" use="optional"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="error" type="held:errorType"/>
<!-- Location Response -->
<xs:complexType name="locationResponseType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="locationUriSet"
type="held:returnLocationType"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="locationResponse"
type="held:locationResponseType"/>
<!-- Location Request -->
<xs:complexType name="locationRequestType">
<xs:complexContent>
<xs:extension base="held:baseRequestType">
<xs:sequence>
<xs:element name="locationType"
type="held:locationTypeType"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
Barnes, et al. Expires July 17, 2008 [Page 18]
Internet-Draft HELD January 2008
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="locationRequest"
type="held:locationRequestType"/>
</xs:schema>
8. HTTP Binding
This section describes the use of HTTP [3] as a transport mechanism
for this protocol, which all conforming implementations MUST support.
The request is carried in the body of an HTTP POST request. The MIME
type of both request and response bodies should be
"application/held+xml".
The LIS populates the HTTP headers so that they are consistent with
the contents of the message. In particular, the "expires" and cache
control headers are used to control the caching of any PIDF-LO
document or Location URIs. The HTTP status code SHOULD indicate a
2xx series response when a PIDF-LO document or Location URI is
included.
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
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
request.
The implementation of HTTP as a transport mechanism MUST implement
TLS as described in [4]. TLS provides message integrity and privacy
between Device and LIS. The LIS MUST use the server authentication
method described in [4]; the Device MUST fail a request if server
authentication fails, except in the event of an emergency.
9. Security Considerations
The Security Requirements for the Geopriv Location System [Editor's
note: need to add explicit reference to this doc, BUT xml2rfc not
happy with that doc not having an abbreviated title] identifies the
threat model for the protocols that interface with a LIS. The threat
Barnes, et al. Expires July 17, 2008 [Page 19]
Internet-Draft HELD January 2008
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
acquisition protocols are provided in [11] including that the LCP
MUST NOT assume prior network access authentication, which is
addressed in Section 9.2
An in-depth discussion of the security considerations applicable to
the use of Location URIs and by-reference provision of LI is included
in [15].
9.1. Return Routability
It is RECOMMENDED that Location Information Servers use return
routability rather than requiring Device authentication. Device
authentication SHOULD NOT be required due to the administrative
challenge of issuing and managing of client credentials, particularly
when networks allow visiting users to attach devices. However, the
LIS MAY require any form of authentication as long as these factors
are considered.
Addressing information used in a request to the LIS is used to
determine the identity of the Device, and to address a response.
This ensures that a Device can only request its own LI.
A temporary spoofing of IP address could mean that a device could
request a Location URI that would result in another Device's
location. One or more of the follow approaches are RECOMMENDED to
limit this exposure:
o Location URIs SHOULD have a limited lifetime, as reflected by the
value for the expires element (Section 6.5.1).
o The network SHOULD have mechanisms that protect against IP address
spoofing.
o The LIS SHOULD ensure that requests can only originate from within
its administrative domain.
o The LIS and network SHOULD be configured so that the LIS is made
aware of Device movement within the network and addressing
changes. If the LIS detects a change in the network, then all
location URIs MUST be invalidated.
The above measures are dependent on network configuration and SHOULD
be considered with circumstances in mind. For instance, in a fixed
internet access, providers may be able to restrict the allocation of
IP addresses to a single physical line, ensuring that spoofing is not
Barnes, et al. Expires July 17, 2008 [Page 20]
Internet-Draft HELD January 2008
possible; in such an environment, other measures may not be
necessary.
9.2. Transaction Layer Security
All bindings for this protocol MUST ensure that messages are
adequately protected against eavesdropping and modification.
Bindings MUST also provide a means of authenticating the LIS.
It is RECOMMENDED that all bindings also use TLS [2].
For the HTTP binding, TLS MUST be used. TLS provides protection
against eavesdropping and modification. The server authentication
methods described in HTTP on TLS [4] MUST be used.
10. Examples
10.1. HTTP Example Messages
The examples in this section show a complete HTTP message that
includes the HELD request or response document.
This example shows the most basic request for a LO. This uses the
GET feature described by the HTTP binding. This example assumes that
the LIS service exists at the URL "https://lis.example.com/location".
GET /location HTTP/1.1
Host: lis.example.com
Accept:application/held+xml,
application/xml;q=0.8,
text/xml;q=0.7
Accept-Charset: UTF-8,*
Barnes, et al. Expires July 17, 2008 [Page 21]
Internet-Draft HELD January 2008
The GET request is exactly identical to a minimal POST request that
includes an empty "locationRequest" element.
POST /location HTTP/1.1
Host: lis.example.com
Accept: application/held+xml,
application/xml;q=0.8,
text/xml;q=0.7
Accept-Charset: UTF-8,*
Content-Type: application/held+xml
Content-Length: 87
<?xml version="1.0"?>
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
Barnes, et al. Expires July 17, 2008 [Page 22]
Internet-Draft HELD January 2008
The successful response to either of these requests is a PIDF-LO
document. The following response shows a minimal PIDF-LO response.
HTTP/1.x 200 OK
Server: Example LIS
Date: Tue, 10 Jan 2006 03:42:29 GMT
Expires: Tue, 10 Jan 2006 03:42:29 GMT
Cache-control: private
Content-Type: application/held+xml
Content-Length: 594
<?xml version="1.0"?>
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:3650n87934c@ls.example.com">
<tuple id="3b650sf789nd">
<status>
<geopriv xmlns="urn:ietf:params:xml:ns:pidf:geopriv10">
<location-info>
<Point xmlns="http://www.opengis.net/gml"
srsName="urn:ogc:def:crs:EPSG::4326">
<pos>-34.407 150.88001</pos>
</Point>
</location-info>
<usage-rules>
<retention-expiry>
2006-01-11T03:42:28+00:00</retention-expiry>
</usage-rules>
</geopriv>
</status>
<timestamp>2006-01-10T03:42:28+00:00</timestamp>
</tuple>
</presence>
</locationResponse>
Barnes, et al. Expires July 17, 2008 [Page 23]
Internet-Draft HELD January 2008
The error response to either of these requests is an error document.
The following response shows an example error response.
HTTP/1.x 200 OK
Server: Example LIS
Expires: Tue, 10 Jan 2006 03:49:20 GMT
Cache-control: private
Content-Type: application/held+xml
Content-Length: 135
<?xml version="1.0"?>
<error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="locationUnknown"
message="Unable to determine location"/>
Note: To focus on important portions of messages, all examples
following this note do not show HTTP headers or the XML prologue.
In addition, sections of XML not relevant to the example are
replaced with comments.
10.2. Simple Location Request Example
The location request shown below doesn't specify any location types
or response time.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
The response to this location request is a list of Location URIs.
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2006-01-01T13:00:00">
<locationURI>held://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI>
<locationURI>held://9769+357yc6s64ceyoiuy5ax3o@ls.example.com
</locationURI>
</locationUriSet>
</locationResponse>
An error response to this location request is shown below:
<error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="locationUnknown"
message="Location not available"/>
Barnes, et al. Expires July 17, 2008 [Page 24]
Internet-Draft HELD January 2008
10.3. Location Request Example for Multiple Location Types
The following Location Request message includes a request for
geodetic, civic and any Location URIs.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="true">
geodetic
civic
locationURI
</locationType>
</locationRequest>
The corresponding Location Response message includes the requested
location information, including two location URIs.
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2006-01-01T13:00:00">
<locationURI>held://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI>
<locationURI>held://9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
</locationURI>
</locationUriSet>
<presence xmlns="urn:ietf:params:xml:ns:pidf:geopriv10"
entity="pres:ae3be8585902e2253ce2@10.102.23.9">
<tuple id="lisLocation">
<status>
<geopriv>
<location-info>
<gs:Circle
xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.407242 150.882518</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">30
</gs:radius>
</gs:Circle>
<ca:civicAddress
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xml:lang="en-au">
<ca:country>AU</ca:country>
<ca:A1>NSW</ca:A1>
<ca:A3>Wollongong</ca:A3>
<ca:A4>Gwynneville</ca:A4>
<ca:STS>Northfield Avenue</ca:STS>
Barnes, et al. Expires July 17, 2008 [Page 25]
Internet-Draft HELD January 2008
<ca:LMK>University of Wollongong</ca:LMK>
<ca:FLR>2</ca:FLR>
<ca:NAM>Andrew Corporation</ca:NAM>
<ca:PC>2500</ca:PC>
<ca:BLD>39</ca:BLD>
<ca:SEAT>WS-183</ca:SEAT>
<ca:POBOX>U40</ca:POBOX>
</ca:civicAddress>
</location-info>
<usage-rules>
<retransmission-allowed>false</retransmission-allowed>
<retention-expiry>2007-05-25T12:35:02+10:00
</retention-expiry>
</usage-rules>
<method>Wiremap</method>
</geopriv>
</status>
<timestamp>2007-05-24T12:35:02+10:00</timestamp>
</tuple>
</presence>
</locationResponse>
11. IANA Considerations
This document requires several IANA registrations detailed in the
following sections.
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
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:held".
URI: urn:ietf:params:xml:ns:geopriv:held
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com).
XML:
Barnes, et al. Expires July 17, 2008 [Page 26]
Internet-Draft HELD January 2008
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>HELD Messages</title>
</head>
<body>
<h1>Namespace for HELD Messages</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body>
</html>
END
11.1.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:http
TThis section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:held:http."
URI: urn:ietf:params:xml:ns:geopriv:held:http
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>HELD HTTP Binding WS</title>
</head>
<body>
<h1>Namespace for HELD HTTP Binding WS</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:http</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body>
</html>
END
Barnes, et al. Expires July 17, 2008 [Page 27]
Internet-Draft HELD January 2008
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.
To: ietf-types@iana.org
Subject: Registration of MIME media type application/held+xml
MIME media type name: application
MIME subtype name: held+xml
Required parameters: (none)
Optional parameters: charset
Indicates the character encoding of enclosed XML. Default is
UTF-8.
Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See RFC
3023 [18], section 3.2.
Security considerations: This content type is designed to carry
protocol data related to the location of an entity, which could
include information that is considered private. Appropriate
precautions should be taken to limit disclosure of this
information.
Interoperability considerations: This content type provides a basis
for a protocol
Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number for this specification.]]
Applications which use this media type: Location information
providers and consumers.
Additional Information: Magic Number(s): (none)
File extension(s): .xml
Macintosh File Type Code(s): (none)
Person & email address to contact for further information: Mary
Barnes <mary.barnes@nortel.com>
Intended usage: LIMITED USE
Author/Change controller: The IETF
Other information: This media type is a specialization of
application/xml [18], and many of the considerations described
there also apply to application/held+xml.
Barnes, et al. Expires July 17, 2008 [Page 28]
Internet-Draft HELD January 2008
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.]
Barnes, et al. Expires July 17, 2008 [Page 29]
Internet-Draft HELD January 2008
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
James Winterbottom, Martin Thomson and Barbara Stark are the authors
of the original document, from which this WG document was derived.
Their contact information is included in the Author's address
section. In addition, they also contributed to the WG document,
including the XML schema.
13. Acknowledgements
The author/contributors would like to thank the participants in the
GEOPRIV WG and the following people for their constructive input and
feedback on this document (in alphabetical order): Nadine Abbott,
Eric Arolick, Richard Barnes, Peter Blatherwick, Guy Caron, Martin
Barnes, et al. Expires July 17, 2008 [Page 30]
Internet-Draft HELD January 2008
Dawson, Lisa Dusseault, Jerome Grenier, Ted Hardie, Neil Justusson,
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
NOTE TO THE RFC-Editor: Please remove this section prior to
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:
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).
Barnes, et al. Expires July 17, 2008 [Page 31]
Internet-Draft HELD January 2008
2) Removed WSDL (section 8 updated, section 8.1 and 10.4 removed)
3) Added extensibility to baseRequestType in the schema (an oversight
from previous edits), along with fixing some other nits in schema
(section 7)
4) Moved discussion of Location URI from section 5.3 (Location
Response) to where it rightly belonged in Section 6.5 (Location URI
Parameter).
5) Clarified text for "expires" parameter (6.5.1) - it's an optional
parm, but required for LocationURIs
6) Clarified responseTime parameter: when missing, then the LCS
provides most precise LI, with the time required being implementation
specific.
7) Clarified that the MUST use in section 8 (HTTP binding) is a MUST
implement.
8) Updated references (removed unused/added new).
Changes from WG 01 to 02:
1) Updated Terminology to be consistent with WG agreements and other
documents (e.g., LCS -> LIS and removed duplicate terms). In the
end, there are no new terms defined in this document.
2) Modified definition of responseTime to reflect WG consensus.
3) Removed jurisdictionalCivic and postalCivic locationTypes (leaving
just "civic").
4) Clarified text that locationType is optional. Fixed table 1 and
text in section 5.2 (locationRequest description). Text in section
6.2 (description of locationType element) already defined the default
to be "any".
5) Simplified error responses. Separated the definition of error
response type from the locationResponse type thus no need for
defining an error code of "success". This simplifies the schema and
processing.
6) Updated schema/examples for the above.
7) Updated Appendix A based on updates to requirements document,
specifically changes to A.1, A.3 and adding A.10.
Barnes, et al. Expires July 17, 2008 [Page 32]
Internet-Draft HELD January 2008
8) Miscellaneous editorial clarifications.
Changes from WG 00 to 01:
1) heldResponse renamed to locationResponse.
2) Changed namespace references for the PIDF-LO geoShape in the
schema to match the agreed GML PIDF-LO Geometry Shape Application
Schema.
3) Removed "options" element - leaving optionality/extensibility to
XML mechanisms.
4) Changed error codes to be enumerations and not redefinitions of
HTTP response codes.
5) Updated schema/examples for the above and removed some remnants of
the context element.
6) Clarified the definition of "Location Information (LI)" to include
a reference to the location (to match the XML schema and provide
consistency of usage throughout the document). Added an additional
statement in section 7.2 (locationType) to clarify that LCS MAY also
return a Location URI.
7) Modifed the definition of "Location Configuration Server (LCS)" to
be consistent with the current definiton in the requirements
document.
8) Updated Location Response (section 6.3) to remove reference to
context and discuss the used of a local identifier or unlinked
pseudonym in providing privacy/security.
9) Clarified that the source IP address in the request is used as the
identifier for the target/device for the HELD protocol as defined in
this document.
10) Miscellaneous editorial clarifications.
15. References
15.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
Barnes, et al. Expires July 17, 2008 [Page 33]
Internet-Draft HELD January 2008
RFC 2246, January 1999.
[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[5] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
Language) XML-Signature Syntax and Processing", RFC 3275,
March 2002.
[6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[7] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
Polk, "Geopriv Requirements", RFC 3693, February 2004.
[8] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[9] Thomson, M. and J. Winterbottom, "Revised Civic Location Format
for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-07 (work in
progress), December 2007.
[10] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations and
Recommendations", draft-ietf-geopriv-pdif-lo-profile-10 (work
in progress), October 2007.
[11] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location
Configuration Protocol; Problem Statement and Requirements",
draft-ietf-geopriv-l7-lcp-ps-06 (work in progress),
November 2007.
[12] Thompson, H., Maloney, M., Beech, D., and N. Mendelsohn, "XML
Schema Part 1: Structures Second Edition", World Wide Web
Consortium Recommendation REC-xmlschema-1-20041028,
October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[13] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second
Edition", World Wide Web Consortium Recommendation REC-
xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[14] Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)",
Barnes, et al. Expires July 17, 2008 [Page 34]
Internet-Draft HELD January 2008
draft-thomson-geopriv-lis-discovery-03 (work in progress),
September 2007.
[15] Marshall, R., "Requirements for a Location-by-Reference
Mechanism", draft-ietf-geopriv-lbyr-requirements-01 (work in
progress), October 2007.
15.2. Informative References
[16] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[17] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
and Instant Messaging", RFC 2778, February 2000.
[18] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[19] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[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 Information", RFC 3825, July 2004.
[22] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 115,
RFC 4395, February 2006.
[23] Polk, J. and B. Rosen, "Location Conveyance for the Session
Initiation Protocol", draft-ietf-sip-location-conveyance-09
(work in progress), November 2007.
[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".
Barnes, et al. Expires July 17, 2008 [Page 35]
Internet-Draft HELD January 2008
Appendix A. HELD Compliance to IETF LCP requirements
This appendix describes HELD's compliance to the requirements
specified in the [11].
A.1. L7-1: Identifier Choice
"The L7 LCP MUST be able to carry different identifiers or MUST
define an identifier that is mandatory to implement. Regarding the
latter aspect, such an identifier is only appropriate if it is from
the same realm as the one for which the location information service
maintains identifier to location mapping."
COMPLY
HELD uses the IP address of the location request message as the
primary source of identity for the requesting device or target. This
identity can be used with other contextual network information to
provide a physical location for the Target for many network
deployments. There may be network deployments where an IP address
alone is insufficient to identify a Target in a network. However,
any necessary identity extensions for these networks is beyond the
scope of this document.
A.2. L7-2: Mobility Support
"The GEOPRIV Layer 7 Location Configuration Protocol MUST support a
broad range of mobility from devices that can only move between
reboots, to devices that can change attachment points with the impact
that their IP address is changed, to devices that do not change their
IP address while roaming, to devices that continuously move by being
attached to the same network attachment point."
COMPLY
Mobility support is inherently a characteristic of the access network
technology and HELD is designed to be access network agnostic.
Consequently HELD complies with this requirement. In addition HELD
provides specific support for mobile environments by providing an
optional responseTime attribute in location request messages.
Wireless networks often have several different mechanisms at their
disposal for position determination (e.g. Assisted GPS versus
location based on serving base station identity), each providing
different degrees of accuracy and taking different amounts of time to
yield a result. The responseTime parameter provides the LIS with a
criterion which it can use to select a location determination
technique.
Barnes, et al. Expires July 17, 2008 [Page 36]
Internet-Draft HELD January 2008
A.3. L7-3: ASP and Access Network Provider Relationship
"The design of the L7 LCP MUST NOT assume a business or trust
relationship between the Application Service Provider (ASP) and the
Access Network Provider. Requirements for resolving a reference to
location information are not discussed in this document."
COMPLY
HELD describes a location acquisition protocol and has no
dependencies on the business or trust relationship between the ASP
and the Access Network Provider. Location acquisition using HELD is
subject to the restrictions described in Section 9.
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship
"The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST assume that there is a trust and business relationship between
the L2 and the L3 provider. The L3 provider operates the LIS and
needs to obtain location information from the L2 provider since this
one is closest to the end host. If the L2 and L3 provider for the
same host are different entities, they cooperate for the purposes
needed to determine end system locations."
COMPLY
HELD was specifically designed with this model in mind and readily
allows itself to chaining requests between operators without a change
in protocol being required. HELD is a webservices protocol it can be
bound to transports other than HTTP. Using o offers the option of
high request throughput over a dedicated connection between an L3
provider and an L2 provider without incurring the serial restriction
imposed by HTTP. This is less easy to do with protocols that do not
decouple themselves from the transport.
A.5. L7-5: Legacy Device Considerations
"The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST consider legacy residential NAT devices and NTEs in an DSL
environment that cannot be upgraded to support additional protocols,
for example to pass additional information through DHCP."
COMPLY
HELD is an application protocol and operates on top of IP. A HELD
request from a host behind a residential NAT will traverse the NAT
acquiring the external address of the home router. The location
provided to the host therefore will be the address of the home router
Barnes, et al. Expires July 17, 2008 [Page 37]
Internet-Draft HELD January 2008
in this circumstance. No changes are required to the home router in
order to support this function, HELD was designed specifically to
address this deployment scenario.
A.6. L7-6: VPN Awareness
"The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST assume that at least one end of a VPN is aware of the VPN
functionality. In an enterprise scenario, the enterprise side will
provide the LIS used by the client and can thereby detect whether the
LIS request was initiated through a VPN tunnel."
COMPLY
HELD does not preclude a LIS on the far end of a VPN tunnel being
aware that the client request is occurring over that tunnel. It also
does not preclude a client device from accessing a LIS serving the
local physical network and subsequently using the location
information with an application that is accessed over a VPN tunnel.
A.7. L7-7: Network Access Authentication
"The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST NOT assume prior network access authentication."
COMPLY
HELD makes no assumptions about prior network access authentication.
HELD strongly recommends the use of TLS with server-side certificates
for communication between the end-point and the LIS. There is no
requirement for the end-point to authenticate with the LIS.
A.8. L7-8: Network Topology Unawareness
"The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST NOT assume end systems being aware of the access network
topology. End systems are, however, able to determine their public
IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP."
COMPLY
HELD makes no assumption about the network topology. HELD doesn't
require that the device know its external IP address, except where
that is required for discovery of the LIS.
Barnes, et al. Expires July 17, 2008 [Page 38]
Internet-Draft HELD January 2008
A.9. L7-9: Discovery Mechanism
"The L7 LCP MUST define a single mandatory to implement discovery
mechanism."
COMPLY
HELD uses the discovery mechanism in [14].
A.10. L7-10: PIDF-LO Creation
"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
(see RFC 4479). This ensures that the resulting PIDF-LO document,
which is subsequently distributed to other entities, conforms to the
rules outlined in ". [10]
COMPLY
HELD protocol overview (Section 4 ) describes the requirements on the
LIS in creating the PIDF-LO and prescribes that the PIDF-LO generated
by the LIS MUST conform to [10].
Authors' Addresses
Mary Barnes (editor)
Nortel
2201 Lakeside Blvd
Richardson, TX
Email: mary.barnes@nortel.com
James Winterbottom
Andrew
PO Box U40
Wollongong University Campus, NSW 2500
AU
Phone: +61 2 4221 2938
Email: james.winterbottom@andrew.com
URI: http://www.andrew.com/
Barnes, et al. Expires July 17, 2008 [Page 39]
Internet-Draft HELD January 2008
Martin Thomson
Andrew
PO Box U40
Wollongong University Campus, NSW 2500
AU
Phone: +61 2 4221 2915
Email: martin.thomson@andrew.com
URI: http://www.andrew.com/
Barbara Stark
BellSouth
Room 7A41
725 W Peachtree St.
Atlanta, GA 30308
US
Email: barbara.stark@bellsouth.com
Barnes, et al. Expires July 17, 2008 [Page 40]
Internet-Draft HELD January 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Barnes, et al. Expires July 17, 2008 [Page 41]
