GEOPRIV WG M. Barnes, Ed.
Internet-Draft Nortel
Intended status: Standards Track
Expires: December 9, 2007
June 7, 2007
HTTP Enabled Location Delivery (HELD)
draft-ietf-geopriv-http-location-delivery-00.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 December 9, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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 either by-value or by-reference. The protocol
supports mobile and nomadic devices through Location URIs. The
protocol is an application-layer protocol that is independent of
Barnes, et al. Expires December 9, 2007 [Page 1]
Internet-Draft HELD June 2007
session-layer; an HTTP, web services binding is specified.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 6
5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
6. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9
6.1. Protocol Binding . . . . . . . . . . . . . . . . . . . . . 9
6.2. Location Request . . . . . . . . . . . . . . . . . . . . . 9
6.3. Held Response . . . . . . . . . . . . . . . . . . . . . . 10
6.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 10
7. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10
7.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11
7.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 11
7.2.1. "exact" Parameter . . . . . . . . . . . . . . . . . . 12
7.3. "options" Parameter . . . . . . . . . . . . . . . . . . . 13
7.4. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 13
7.5. "message" Parameter . . . . . . . . . . . . . . . . . . . 13
7.6. "locationURI" Parameter . . . . . . . . . . . . . . . . . 14
7.6.1. "expires" Parameter . . . . . . . . . . . . . . . . . 14
8. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. HTTP Binding WSDL . . . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10.1. Return Routability . . . . . . . . . . . . . . . . . . . . 20
10.2. Transaction Layer Security . . . . . . . . . . . . . . . . 21
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Simple HTTP Binding Example Messages . . . . . . . . . . . 21
11.2. Simple Location Request Example . . . . . . . . . . . . . 24
11.3. Location Request Example with options . . . . . . . . . . 25
11.4. Location Request Example for Multiple Location Types . . . 27
11.5. Sample LCS WSDL Document . . . . . . . . . . . . . . . . 29
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
12.1. IANA Registry for HELD Result Codes . . . . . . . . . . . 29
12.2. IANA Registry for HELD Location Request Options . . . . . 30
12.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 30
12.4. XML Schema Registration . . . . . . . . . . . . . . . . . 31
12.5. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:http . . . . . . . . . 31
12.6. MIME Media Type Registration for 'application/held+xml' . 32
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Barnes, et al. Expires December 9, 2007 [Page 2]
Internet-Draft HELD June 2007
15.1. Normative References . . . . . . . . . . . . . . . . . . . 33
15.2. Informative References . . . . . . . . . . . . . . . . . . 35
Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 35
A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 36
A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 36
A.3. L7-3: Layer 7 and Layer 2/3 Provider Relationship . . . . 36
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 . . . . . . . . . . . . . . . . . . . 37
A.7. L7-7: Network Access Authentication . . . . . . . . . . . 38
A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 38
A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . . . . 40
Barnes, et al. Expires December 9, 2007 [Page 3]
Internet-Draft HELD June 2007
1. Introduction
The location of a Device is information that is useful for a number
of applications. The L7 LCP problem statement and requirements
document [11] provides some scenarios in which a Device might rely on
its access network to provide the location information, such as such
as fixed environments (e.g., DSL/Cable), mobile networks and wireless
access networks. This document describes a protocol that can be used
to acquire Location Information (LI) from a service within an access
network. The service within an access network is assumed to be
provided by a Location Configuration Server (LCS), as introduced in
the L7 LCP problem statement and requirements document.
This specification identifies two methods for acquiring LI. Location
may be retrieved from a Location Configuration Server (LCS) by-value,
that is, the Device may acquire LI directly. Alternatively, the
Device may request that the LCS provide a location URI so that LI can
be distributed by-reference. Both of these methods are compatible,
and both can be provided concurrently from the same LCS so that
application needs can be addressed individually.
This specification defines an XML-based protocol that enables the
retrieval of LI from a LCS by a Device. This protocol can be bound
to any session-layer protocol, particularly those capable of MIME
transport; an HTTP binding is included as a minimum requirement.
2. Conventions
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].
3. Terminology
This document uses the terms (and their acronym forms) Access
Provider (AP), Location Information (LI), Location Object (LO),
Device, Target, Location Server (LS), Location Generator (LG),
Location Recipient (LR), Rule Maker (RM) and Rule Holder (RH) as
defined in [7]. This document also includes definitions for the
terms, Civic Location/Address, Geodetic Location, and Location
Configuration Server, used within this document. These definitions
may differ slightly from those used in other GEOPRIV documents, but
the concepts are the same.
For convenience, abbreviated versions of RFC 3693 [7] definitions are
included. Notes are included following some of the definitions to
Barnes, et al. Expires December 9, 2007 [Page 4]
Internet-Draft HELD June 2007
clarify the context in which these terms are used in this document:
Access Network Provider: See Access Provider (AP).
Access Provider (AP): An organization that provides physical network
connectivity to its customers or users, e.g., through digital
subscriber lines, cable TV plants, Ethernet, leased lines or radio
frequencies. Examples of such organizations include
telecommunication carriers, municipal utilities, larger
enterprises with their own network infrastructure, and government
organizations such as the military.
Note: this definition differs from that in [7] by the use of the
more generic 'organization' rather than 'domain' - the general
concept is the same. This term is used interchangeably with
Access Network Provider in this document.
Civic Location/Address: A location expressed in a form that is
defined by civic demarcations. Civic addresses can be specialized
for jurisdictional (general use) or postal (message delivery)
purposes, or they can apply to either.
Device: The technical device whereby the location is tracked as a
proxy for the location of a Target.
Geodetic Location: A location expressed in coordinate form.
Location Configuration Server (LCS): The entity within the Access
Provider's network that provides location information to clients.
This term is introduced in [11] and it provides the location
information that is generated and maintained by the LG and LS
functional elements respectively. The details of the interactions
between an LG and LS and in particular how the LCS uses these to
obtain location information is outside the scope of this document
since it is very deployment specific.
Location Generator (LG): The entity that initially determines or
gathers the location of the Target and creates Location Objects
describing that location.
Location Information (LI): The data that describes the location of a
Device. The term LI does not include the representation of this
data.
Note: this terms is not officially defined in [7], but rather is
assumed from the general usage throughout that document and within
the GEOPRIV WG.
Barnes, et al. Expires December 9, 2007 [Page 5]
Internet-Draft HELD June 2007
Location Object (LO): An object conveying Location Information (and
possibly privacy rules) to which Geopriv security mechanisms and
privacy rules are to be applied.
Note: this is a specific by-value representation of Location
Information (LI). In this document, LO refers to PIDF-LO [8].
Location Server (LS): The LS is an element that receives
publications of Location Objects from Location Generators and may
receive subscriptions from Location Recipients. The LS applies
the rules (which it learns from the Rule Holder) to LOs it
receives from LGs, and then notifies LRs of resulting LOs as
necessary.
Note: This definition varies from that defined in [7] by defining
the roles of the functional elements more explicitly. In some
specifications the Location Server is referred to as a Location
Information Server or LIS. In this context, the Location Server
is distinct from what is alternatively referred to as a Registrar
in other contexts.
Location Recipient (LR): The entity that receives Location
Information (LI).
Rule Holder (RH): The entity that provides the rules associated with
a particular target for the distribution of Location Information
(LI).
Rule Maker (RM): The authority that creates rules governing access
to location information for a target (typically, this it the
Target themselves).
Target: A person or other entity whose location is communicated by a
GEOPRIV Location Object (LO).
4. Overview and Scope
This document describes an interface between a Device and a Location
Configuration Server (LCS). The LCS is a service present within the
same administrative domain as the Device (the access network). An
Access Provider (AP) operates the LCS service so that Devices (and
Targets) can retrieve LI. The LCS 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 derived.
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
Barnes, et al. Expires December 9, 2007 [Page 6]
Internet-Draft HELD June 2007
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.
This document identifies two methods for acquiring LI. Location may
be retrieved from a Location Configuration Server (LCS) by-value,
that is, the device may acquire LI directly. Alternatively, the
Device may request that the LCS provide a location URI so that LI can
be distributed by-reference. Providing LI by-reference implies that
a server is able to provide the device with a public, globally-
addressable URI.
The following diagram shows the logical configuration of some of the
functional elements identified in [7] and the LCS 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 Configuration Server | |
| | | |
| | | |
| | | |
| | | |
| +------|---------------------'---------+ |
+----------|---------------------'------------+
| '
| '
HELD APP
| '
Rule Maker - _ +-----------+ +-----------+
o - - | Device | | Location |
<U\ | | - - - - | Recipient |
/ \ _ - - | | APP | |
Target - - +-----------+ +-----------+
Figure 1: Significant Roles
Barnes, et al. Expires December 9, 2007 [Page 7]
Internet-Draft HELD June 2007
The interface between the Location Recipient (LR) and the Device
and/or LCS 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 [24].
5. Protocol Overview
The HELD protocol facilitates retrieval of LI either by-value, as a
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
of this document and and maybe specified in separate specifications
as required. The Device must first discover the URI for the LCS 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 [15].
Where a Device requires LI directly, it can request that the LCS
create a PIDF-LO document. This approach fits well with a
configuration whereby the device directly makes use of the provided
PIDF-LO document. With this approach, the LCS needs to uniquely
identify the Device within the access network. The source address of
the request message is sufficient in most cases. Once the Device is
identified, the LCS uses network domain-specific information to
determine the location of the Device.
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 [10]. The PIDF-LO generated by the
LCS in this case MUST follow the rules in [10]. In addition, the
default values for <retransmission allowed> and <retention expires>
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-expires> value of any generated
PDIF-LO documents.
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 [23] of any scheme, which
a Location Recipient (LR) can use to retrieve LI. A location URI
provided by an LCS can be assumed to be globally-addressable; that
is, anyone in possession of the URI can access the LCS. This does
not in any way suggest that the LCS 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 [16].
Barnes, et al. Expires December 9, 2007 [Page 8]
Internet-Draft HELD June 2007
6. Protocol Description
As discussed in Section 5, this protocol provides for the retrieval
of a Location or a Location URI from an LCS. Three messages are
defined to support the location retrieval: locationRequest,
heldResponse and error. Messages are defined as XML documents.
The Location Request (locationRequest) message is described in
Section 6.2. A Location Request from a Device indicates whether a
Location (and the specific type of location) and/or a Location URI
should be returned. The LCS replies with a response (heldResponse),
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 12.6 to
distinguish HELD messages from other XML document bodies. This
specification follows the recommendations and conventions described
in [20], including the naming convention of the type ('+xml' suffix)
and the usage of the 'charset' parameter.
Section 7 contains a more thorough description of the protocol
parameters, valid values, and how each should be handled. Section 8
contains a more specific definition of the structure of these
messages in the form of an XML Schema [12].
6.1. Protocol Binding
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.
Candidate protocols that could be used to address these purposes
include: TCP [17], TLS [2], SASL [18], HTTP [3], SIP [22], BEEP [21]
and SOAP [25] [26]. This document includes a binding that uses a
combination of HTTP, TLS and TCP in Section 9.
6.2. Location Request
A location request is sent from the Device to the LCS when it
requires LI. This request MUST include the type of location being
requested such as civic location, location URI, etc. The type of LI
that a Device requests is determined by the type of LI that is
included in the "locationType" element.
Barnes, et al. Expires December 9, 2007 [Page 9]
Internet-Draft HELD June 2007
The location request is made by sending a document formed of a
"locationRequest" element. The successful response to a location
request is a document formed of a "heldResponse" element, unless the
request fails, in which case the LCS SHOULD provide an error
indication document.
6.3. Held Response
The response to a Location request MUST contain either a PIDF-LO
and/or Location URI(s), depending upon the requested "locationType".
The "heldResponse" element MUST include a "code" attribute with a
value of 200. A set of predefined error codes are included in
Section 7.4. The response is in error if there is a value other than
200, since those MUST be sent using the error message Section 6.4.
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 LCS and a random sequence of
characters that the LCS can use to identify a particular context.
6.4. Indicating Errors
In the event of an error, the LCS SHOULD respond to the Device with
an error document. The error response applies to all request types
and SHOULD 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 7.4.
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.
7. 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.
Barnes, et al. Expires December 9, 2007 [Page 10]
Internet-Draft HELD June 2007
+-------------------------+-----------------+---------------+-------+
| Parameter | Location | HELD Response | Error |
| | Request | | |
+-------------------------+-----------------+---------------+-------+
| responseTime | o | | |
| (Section 7.1) | | | |
| locationType | m | | |
| (Section 7.2) | | | |
| exact (Section 7.2.1) | o | | |
| options (Section 7.3) | o | | |
| code (Section 7.4) | | m | m |
| message (Section 7.5) | | o | o |
| locationURI | | o | |
| (Section 7.6) | | | |
| expires (Section 7.6.1) | | m | |
+-------------------------+-----------------+---------------+-------+
Table 1: Message Parameter Usage
7.1. "responseTime" Parameter
The "responseTime" attribute indicates to the LCS how long the Device
is prepared to wait for a response. This attribute MAY be added to a
Location request message. The value of this attribute is indicative
only, the LCS is under no obligation to strictly adhere to the time
limit implied; any enforcement of the time limit is left to the
requesting Device.
This attribute is expressed with a decimal seconds value, which may
include a decimal point. It is RECOMMENDED that systems support
millisecond precision for this parameter.
The LCS MUST provide the most accurate LI that can be determined
within the specified interval. This parameter could be used as input
when selecting the method of location determination, where multiple
such methods exist. If this parameter is absent, then the LCS MUST
return the most precise LI it is capable of determining.
7.2. "locationType" Parameter
The "locationType" element is included in a location request. It
contains a list of LI types that are requested by the Device. The
following list describes the possible values:
any: The LCS SHOULD attempt to provide LI in all forms available to
it. This value MUST be assumed as the default if no
"locationType" is specified. The LCS SHOULD return location
information in a form that is suited for routing and responding to
an emergency call in its jurisdiction.
Barnes, et al. Expires December 9, 2007 [Page 11]
Internet-Draft HELD June 2007
geodetic: The LCS SHOULD return a geodetic location for the Target.
civic: The LCS SHOULD return a civic address for the Target. Any
type of civic address may be returned. The LCS SHOULD ignore this
value if a request for jurisdictional or postal civic address has
been made and can be satisfied.
jurisdictionalCivic: The LCS SHOULD return a jurisdictional civic
address for the Target.
postalCivic: The LCS SHOULD return a postal civic address for the
Target.
locationURI: The LCS SHOULD return a location URI for the Target.
The LCS SHOULD return the requested location type or types. The LCS
MAY provide additional location types, or it MAY provide alternative
types if the request cannot be satisfied for a requested location
type. If the "exact" attribute is present and set to "true" in a
location request, then a successful LCS response MUST provide the
requested location type only, with no additional location
information. The "exact" attribute has no effect when this element
is set to "any".
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. Unless the
"exact" attribute is set, the LCS MUST provide LI in any available
form if it is unable to comply with the request.
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 LCS might be
unable to provide a civic address.
7.2.1. "exact" Parameter
When the "exact" attribute is set to "true", it indicates to the LCS
that the contents of the "locationType" parameter MUST be strictly
followed. The default value of "false" allows the LCS 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 LCS MUST provide a location of
the requested type or types or MUST provide an error. The LCS MUST
provide the requested types only and these types SHOULD be specified
in the same order as they were requested. The LCS SHOULD handle an
exact request that includes a "locationType" element set to "any" as
if the "exact" attribute were set to "false".
Barnes, et al. Expires December 9, 2007 [Page 12]
Internet-Draft HELD June 2007
7.3. "options" Parameter
The "options" attribute provides for extensibility, allowing for the
definition of future optional extensions to the location request
message without the need to create a new namespace. If multiple
options are used, they MUST be separated by a semicolon (;), such as
"optionOne=1;optionTwo=2; Option3=3". Options MUST be registered
with IANA per Section 12.2.
7.4. "code" Parameter
All responses MUST contain a response code. The "code" attribute
applies to the "error" and "heldResponse" messages.
The following response codes follow a three decimal form similar to
that in HTTP [3] and SIP [22]:
200 (Success): This code indicates that the request was successful.
This code MUST not be used for an error response.
400 (Request Error): This code indicates that the request was badly
formed in some fashion.
401 (XML Error): This code indicates that the XML content of the
request was either badly formed or invalid.
402 (Authentication Error): This code indicates that the request
either did not contain authentication information, or the
authentication provided was not accepted.
500 (General LCS Error): This code indicates that an unspecified
error occurred at the LCS.
501 (Location Unknown): This code indicates that the LCS could not
determine the location of the Device.
502 (Unsupported Message): This code indicates that the request was
not supported or understood by the LCS.
503 (Timeout): This code indicates that the LCS could not satisfy
the request within the time specified in the "responseTime"
parameter.
504 (Cannot Provide LI Type): This code indicates that the LCS 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".
Additional response codes within the x00 to x79 range MUST be
specified in published RFCs; the range from x80 to x99 is reserved
for private usage.
7.5. "message" Parameter
The "heldResponse" and "error" messages 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.
Barnes, et al. Expires December 9, 2007 [Page 13]
Internet-Draft HELD June 2007
The default language is assumed to be English.
7.6. "locationURI" Parameter
The "locationURI" element includes a single Location URI. Each
Location URI that is allocated by the LCS is unique to the device
that is requesting it.
A "heldResponse" message MAY contain any number of "locationURI"
elements. It is RECOMMENDED that the LCS allocate a Location URI for
each scheme that it supports and that each scheme is present only
once. URI schemes and their secure variants such as http and https
should be regarded as two separate schemes.
7.6.1. "expires" Parameter
The "expires" attribute indicates the time at which the Location URI
provided by the LCS will expire. This attribute is included in the
"heldResponse" message only.
Responses to Locations requests for Location URIs MUST include the
expiry time of the Location URI.
8. 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: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"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
Barnes, et al. Expires December 9, 2007 [Page 14]
Internet-Draft HELD June 2007
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"
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="urn:ietf:params:xml:ns:common-policy"
schemaLocation="common-policy.xsd"/>
<xs:import namespace="http://www.opengis.net/gml"
schemaLocation="GML-3.1.1/base/geometryBasic2d.xsd"/>
<!-- Context Information -->
<xs:complexType name="returnContextType">
<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>
<!-- Duration Type -->
<xs:simpleType name="durationType">
<xs:restriction base="xs:decimal">
<xs:minInclusive value="0.0"/>
</xs:restriction>
</xs:simpleType>
<!-- Location Type -->
<xs:simpleType name="locationTypeBase">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="any"/>
</xs:restriction>
</xs:simpleType>
Barnes, et al. Expires December 9, 2007 [Page 15]
Internet-Draft HELD June 2007
<xs:simpleType>
<xs:list>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="civic"/>
<xs:enumeration value="geodetic"/>
<xs:enumeration value="postalCivic"/>
<xs:enumeration value="jurisdictionalCivic"/>
<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:nonNegativeInteger">
<xs:pattern value="[0-5][0-9][0-9]"/>
</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:durationType"
use="optional"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="baseResponseType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence/>
<xs:attribute name="code" type="held:codeType"
Barnes, et al. Expires December 9, 2007 [Page 16]
Internet-Draft HELD June 2007
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:baseResponseType"/>
<!-- Context Response -->
<xs:complexType name="contextResponseType">
<xs:complexContent>
<xs:extension base="held:baseResponseType">
<xs:sequence>
<xs:element name="locationUriSet"
type="held:returnContextType"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="heldResponse"
type="held:contextResponseType"/>
<!-- 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"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="options" type="xs:token"
use="optional"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="locationRequest"
Barnes, et al. Expires December 9, 2007 [Page 17]
Internet-Draft HELD June 2007
type="held:locationRequestType"/>
</xs:schema>
9. HTTP Binding
This section defines an HTTP [3] binding for this protocol, which all
conforming implementations MUST support. This binding takes the form
of a Web Service (WS) that can be described by the Web Services
Description Language (WSDL) document in Section 9.1.
The request is carried in this binding as the body of an HTTP POST
request. The MIME type of both request and response bodies should be
"application/held+xml".
The LCS 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 have the same
first digit as any "heldResponse" or "error" body included, and it
SHOULD indicate a 2xx series response when a PIDF-LO document or
Location URI is included.
This binding 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 LCS MUST attempt to provide either a
PIDF-LO document or a Location URI, as if the request was a location
request.
This binding MUST use TLS as described in [4]. TLS provides message
integrity and privacy between Device and LCS. The LCS 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.1. HTTP Binding WSDL
The following WSDL 2.0 [27] 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"
Barnes, et al. Expires December 9, 2007 [Page 18]
Internet-Draft HELD June 2007
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:heldResponse"/>
<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:heldResponse"/>
<wsdl:fault message="held:error"/>
</wsdl:operation>
</wsdl:interface>
<!-- Note that the by default the HTTP binding uses:
whttp:inputSerialization="application/xml"
whttp:outputSerializatiom="application/xml"
whttp:faultSerialization="application/xml"
whttp:location=""
-->
<wsdl:binding name="heldHTTP" whttp:defaultMethod="POST">
<wsdl:operation ref="heldhttp:locationRequest"/>
<wsdl:operation ref="heldhttp:getLocation" whttp:method="GET"/>
Barnes, et al. Expires December 9, 2007 [Page 19]
Internet-Draft HELD June 2007
</wsdl:binding>
</wsdl:definitions>
10. Security Considerations
The threat model for this protocol assumes that the LCS exists within
the same administrative domain as the Device. The LCS requires
access to network information so that it can determine Location.
Therefore, the LCS 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 10.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 [16].
10.1. Return Routability
It is RECOMMENDED that Location Configuration 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
LCS MAY require any form of authentication as long as these factors
are considered.
Addressing information used in a request to the LCS 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 7.6.1).
o The network SHOULD have mechanisms that protect against IP address
spoofing.
o The LCS SHOULD ensure that requests can only originate from within
its administrative domain.
Barnes, et al. Expires December 9, 2007 [Page 20]
Internet-Draft HELD June 2007
o The LCS and network SHOULD be configured so that the LCS is made
aware of Device movement within the network and addressing
changes. If the LCS 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
possible; in such an environment, other measures may not be
necessary.
10.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 LCS.
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.
11. Examples
11.1. Simple HTTP Binding 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 LCS service exists at the URL "https://lcs.example.com/location".
GET /location HTTP/1.1
Host: lcs.example.com
Accept: application/pidf+xml,application/held+xml,
application/xml;q=0.8,
text/xml;q=0.7
Accept-Charset: UTF-8,*
Barnes, et al. Expires December 9, 2007 [Page 21]
Internet-Draft HELD June 2007
The GET request is exactly identical to a minimal POST request that
includes an empty "locationRequest" element.
POST /location HTTP/1.1
Host: lcs.example.com
Accept: application/pidf+xml,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 December 9, 2007 [Page 22]
Internet-Draft HELD June 2007
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 LCS
Date: Tue, 10 Jan 2006 03:42:29 GMT
Expires: Tue, 10 Jan 2006 03:42:29 GMT
Cache-control: private
Content-Type: application/pidf+xml
Content-Length: 594
<?xml version="1.0"?>
<heldResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="200"
message="OK">
<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-expires>
2006-01-11T03:42:28+00:00</retention-expires>
</usage-rules>
</geopriv>
</status>
<timestamp>2006-01-10T03:42:28+00:00</timestamp>
</tuple>
</presence>
</heldResponse>
Barnes, et al. Expires December 9, 2007 [Page 23]
Internet-Draft HELD June 2007
The error response to either of these requests is an error document.
The following response shows an example error response.
HTTP/1.x 500 Server Error
Server: Example LCS
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="501"
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.
11.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.
<heldResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="200" message="OK">
<locationUriSet expires="2006-01-01T13:00:00">
<locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI>
<locationURI>sips:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
</locationURI>
</locationUriSet>
</heldResponse>
An error response to this location request is shown below:
<error xmlns="urn:ietf:params:xml:ns:geopriv:held" code="450"
message="Location not available"/>
Barnes, et al. Expires December 9, 2007 [Page 24]
Internet-Draft HELD June 2007
11.3. Location Request Example with options
The location request shown below specifies a response time and an
option, but doesn't specify any location type.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
responseTime="2"
options="optionOne=1;"/>
Barnes, et al. Expires December 9, 2007 [Page 25]
Internet-Draft HELD June 2007
The corresponding HELD response shown below includes a PIDF-LO.
<heldResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="200" message="OK">
<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="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
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>
<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-expires>2007-05-25T12:35:02+10:00
</retention-expires>
</usage-rules>
<method>Wiremap</method>
</geopriv>
</status>
<timestamp>2007-05-24T12:35:02+10:00</timestamp>
</tuple>
</presence>
</heldResponse>
Barnes, et al. Expires December 9, 2007 [Page 26]
Internet-Draft HELD June 2007
A corresponding HELD response with Location URIs.
<heldResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="200" message="OK">
<locationUriSet expires="2006-01-01T13:00:00">
<locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI>
<locationURI>sips:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
</locationURI>
</locationUriSet>
</heldResponse>
11.4. Location Request Example for Multiple Location Types
The following Location Request message includes a request for
geodetic, jurisdictional civic and any Location URIs.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="true">
geodetic
jurisdictionalCivic
locationURI
</locationType>
</locationRequest>
The corresponding HELD Response message includes the requested
location information, including two location URIs.
<heldResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="200" message="OK">
<locationUriSet expires="2006-01-01T13:00:00">
<locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI>
<locationURI>sips: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="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
Barnes, et al. Expires December 9, 2007 [Page 27]
Internet-Draft HELD June 2007
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>
<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-expires>2007-05-25T12:35:02+10:00
</retention-expires>
</usage-rules>
<method>Wiremap</method>
</geopriv>
</status>
<timestamp>2007-05-24T12:35:02+10:00</timestamp>
</tuple>
</presence>
</heldResponse>
Barnes, et al. Expires December 9, 2007 [Page 28]
Internet-Draft HELD June 2007
11.5. Sample LCS 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://lcs.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://lcs.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://lcs.example.com/location"/>
</wsdl:service>
</wsdl:definitions>
12. IANA Considerations
According to the guidelines in [6], this document calls for an IANA
registry for result codes and a registry for options in the
locationRequest. This document also registers an XML namespace and
schema and the "application/held+xml" MIME type.
12.1. IANA Registry for HELD Result Codes
IANA will establish and maintain a registry of HELD result codes.
Additional values are registered based on the "specification
required" option in [6].
Specifications MUST specify the following information when
registering new values in this registry:
Code Value: A three-digit value from 000 to 679. The last 20 codes
in each block of 100 (from x80 to x99) are reserved for private or
experimental use and cannot be registered.
Short Message: A brief message that describes the general reason for
the code.
Barnes, et al. Expires December 9, 2007 [Page 29]
Internet-Draft HELD June 2007
Publication: A reference to any relevant publication or
specification.
Description and Usage: A longer description of the code and the
circumstances where it applies. This description does not need to
be exhaustive.
The values in Section 7.4 are pre-registered in this registry.
12.2. IANA Registry for HELD Location Request Options
IANA will establish and maintain a registry of HELD Location Request
options to allow for extensibility of the request. Values are
registered based on the "specification required" option in [6].
Specifications MUST specify the following information when
registering new values in this registry:
Option: Name of the option.
Short Message: A brief message that describes the general reason for
the option and valid values and ranges.
Publication: A reference to any relevant publication or
specification.
Description and Usage: A longer description of the option and the
circumstances where it applies. This description does not need to
be exhaustive.
12.3. 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", as per the guidelines in [6].
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 December 9, 2007 [Page 30]
Internet-Draft HELD June 2007
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
12.4. 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 8 of this document.
12.5. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:http
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:held:http", as per the guidelines in
[6].
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:
Barnes, et al. Expires December 9, 2007 [Page 31]
Internet-Draft HELD June 2007
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
12.6. 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 [20], 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)
Barnes, et al. Expires December 9, 2007 [Page 32]
Internet-Draft HELD June 2007
Person & email address to contact for further information: Mary
Barnes <mary.barnes@nortel.com>
Intended usage: LIMITED USE
Author/Change controller: This specification is TBD
Other information: This media type is a specialization of
application/xml [20], and many of the considerations described
there also apply to application/held+xml.
13. 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.
14. Acknowledgements
The author/contributors would like to thank the following people for
their constructive input to this document (in alphabetical order):
Nadine Abbott, Guy Caron, Martin Dawson, Jerome Grenier, Neil
Justusson, Tat Lam, Patti McCalmont, Perry Prozeniuk, John
Schnizlein, Henning Schulzrinne, Ed Shrum, and Hannes Tschofenig.
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",
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.
Barnes, et al. Expires December 9, 2007 [Page 33]
Internet-Draft HELD June 2007
[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-05 (work in
progress), February 2007.
[10] Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification,
Considerations and Recommendations",
draft-ietf-geopriv-pdif-lo-profile-07 (work in progress),
April 2007.
[11] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location
Configuration Protocol; Problem Statement and Requirements",
draft-ietf-geopriv-l7-lcp-ps-02 (work in progress), April 2007.
[12] Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech, "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] Malhotra, A. and P. Biron, "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] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside,
"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)",
draft-thomson-geopriv-lis-discovery-00 (work in progress),
February 2007.
[16] Marshall, R., "Requirements for a Location-by-Reference
Mechanism used in Location Configuration and Conveyance",
draft-marshall-geopriv-lbyr-requirements-01 (work in progress),
March 2007.
Barnes, et al. Expires December 9, 2007 [Page 34]
Internet-Draft HELD June 2007
15.2. Informative References
[17] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[18] Myers, J., "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997.
[19] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
and Instant Messaging", RFC 2778, February 2000.
[20] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[21] Rose, M., "The Blocks Extensible Exchange Protocol Core",
RFC 3080, March 2001.
[22] 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.
[23] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[24] Polk, J. and B. Rosen, "Session Initiation Protocol Location
Conveyance", draft-ietf-sip-location-conveyance-07 (work in
progress), February 2007.
[25] Mendelsohn, N., Gudgin, M., Nielsen, H., Moreau, J., and M.
Hadley, "SOAP Version 1.2 Part 1: Messaging Framework", World
Wide Web Consortium FirstEdition REC-soap12-part1-20030624,
June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part1-20030624>.
[26] Nielsen, H., Mendelsohn, N., Gudgin, M., Hadley, M., and J.
Moreau, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Web
Consortium FirstEdition REC-soap12-part2-20030624, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part2-20030624>.
[27] Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, "Web
Services Description Language (WSDL) Version 2.0 Part 1: Core
Language", W3C CR CR-wsdl20-20060106, January 2006.
Appendix A. HELD Compliance to IETF LCP requirements
This appendix describes HELD's compliance to the requirements
Barnes, et al. Expires December 9, 2007 [Page 35]
Internet-Draft HELD June 2007
specified in the [11].
A.1. L7-1: Identifier Choice
"The LIS MUST be presented with a unique identifier of its own
addressing realm associated in some way with the physical location of
the end host."
COMPLY
The identifier used may be the source address of the request packet
and/or additional client identifier values relevant to the scope of
the access network provided within the request. Mapping an IP
address into lower-level attachment data is access network dependent
and is the responsibility the LIS.
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.
A.3. L7-3: Layer 7 and Layer 2/3 Provider Relationship
"The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST NOT assume a business or trust relationship between the provider
of application layer (e.g., SIP, XMPP, H.323) provider and the access
network provider operating the LIS."
COMPLY
Barnes, et al. Expires December 9, 2007 [Page 36]
Internet-Draft HELD June 2007
HELD describes a location acquisition protocol and has no
dependencies on how location is used once it has been acquired.
Location acquisition using HELD is subject to the restrictions
described in Section 10.
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, such as BEEP. Using a transport
like BEEP for HELD 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
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
Barnes, et al. Expires December 9, 2007 [Page 37]
Internet-Draft HELD June 2007
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 LCS.
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 [15].
Barnes, et al. Expires December 9, 2007 [Page 38]
Internet-Draft HELD June 2007
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/
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 December 9, 2007 [Page 39]
Internet-Draft HELD June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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 December 9, 2007 [Page 40]