Geopriv J. Winterbottom
Internet-Draft M. Thomson
Intended status: Standards Track Andrew Corporation
Expires: August 29, 2009 H. Tschofenig
Nokia Siemens Networks
R. Barnes
BBN Technologies
February 25, 2009
Use of Target Identity in HTTP-Enabled Location Delivery (HELD)
draft-winterbottom-geopriv-held-identity-extensions-09
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 August 29, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Winterbottom, et al. Expires August 29, 2009 [Page 1]
Internet-Draft HELD Identity February 2009
Abstract
When a Location Information Server receives a request for location
information (using the locationRequest message), described in the
base HTTP Enabled Location Delivery (HELD) specification, it uses the
source IP address of arriving message as a pointer to the location
determination process. This is sufficient in environments where a
Target's location can be determined based on its IP address.
Two additional use cases are addresses by this document. In the
first, location configuration requires additional or alternative
identifiers from the source IP address provided in the request. In
the second, an entity other than the Target requests the Target's
location.
This document extends the HELD protocol to allow the location request
message to carry Target identifiers. Privacy and security
considerations describe the conditions where requests containing
identifiers are permitted.
Winterbottom, et al. Expires August 29, 2009 [Page 2]
Internet-Draft HELD Identity February 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Applications . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Target Identity . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Identifier Format and Protocol Details . . . . . . . . . . 6
3.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. IP Address . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. MAC Address . . . . . . . . . . . . . . . . . . . . . 7
3.2.3. TCP or UDP Port Number . . . . . . . . . . . . . . . . 8
3.2.4. Network Access Identifier . . . . . . . . . . . . . . 8
3.2.5. URI . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.6. Hostname . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.7. Directory Number . . . . . . . . . . . . . . . . . . . 9
3.2.8. Cellular Telephony Identifiers . . . . . . . . . . . . 9
3.2.9. DHCP Unique Identifier . . . . . . . . . . . . . . . . 10
4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6.1. Location Configuration Protocol Requests . . . . . . . . . 14
6.2. Third Party Requests . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 14
7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 15
7.3. Registration of HELD 'badIdentifier' Error Code . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative references . . . . . . . . . . . . . . . . . . . 16
9.2. Informative references . . . . . . . . . . . . . . . . . . 17
Winterbottom, et al. Expires August 29, 2009 [Page 3]
Internet-Draft HELD Identity February 2009
1. Introduction
Protocols for requesting and providing location information require a
way for the requestor to specify the location that should be
returned. In a location configuration protocol (LCP), the location
being requested is the requestor's location. This fact can make the
problem of identifying the Device simpler for LCPs, since IP
datagrams that carry the request already carry an identifier for the
Device, namely the source IP address of an incoming request.
Existing LCPs, such as HELD [I-D.ietf-geopriv-http-location-delivery]
and DHCP ([RFC3825], [RFC4776]) rely on the source IP address, and
possibly lower-layer identifiers to identify a Device.
Aside from the datagrams that form a request, a location information
server (LIS) does not necessarily have access to information that
could further identify the Target. In some circumstances, as shown
in [I-D.ietf-geopriv-l7-lcp-ps], additional identification
information can be included in a request to identify a Target.
This document extends the HELD protocol to support the inclusion of
additional identifiers for the Target in HELD location requests. An
XML schema is defined that provides a structure for including these
identifiers in HELD requests.
An important characteristic of this addition to the HELD protocol is
that is also expands the potential scope of HELD beyond that of an
LCP. The scope of an LCP is limited to the interaction between a
Device and a LIS. That is, an LCP is limited to the Device
retrieving information about their own location. With this addition,
third party location recipients (LRs) are able to make requests that
include identifiers to retrieve location information about a
particular Target.
The usage of HELD for purposes beyond the Device-LIS interaction
obviously introduces a new set of privacy concerns. In an LCP, the
requester is implicitly authorized to access the requested location
information, because it is their own location. In contrast, when a
third party LR requests a Target's location, the LR MUST be
explicitly authorized. Establishing appropriate authorization and
other related privacy concerns are discussed in Section 5.
1.1. Applications
The use of additional identifiers in HELD falls into two categories.
A Device can use these parameters to provide additional
identification information to a LIS. Identification such as the
hardware address of the Device can be used to reduce the time
required to determine the location of the Device. In other cases, a
Winterbottom, et al. Expires August 29, 2009 [Page 4]
Internet-Draft HELD Identity February 2009
LIS might require Device identification before any location
information can be generated.
A third party LR can be granted authorization to make requests for a
given Target. In particular, network services can be permitted to
retrieve location for a Device that is unable to acquire location
information for itself (see Section 6.3 of
[I-D.ietf-ecrit-phonebcp]). This allows use of location-dependent
applications--particularly essential services like emergency
calling--where Devices do not support a location configuration
protocol (LCP) or they are unable to successfully retrieve location
information.
2. Terminology
This document uses the term Location Information Server (LIS) and
location configuration protocol (LCP) as described in
[I-D.ietf-geopriv-l7-lcp-ps].
This document reuses the term Target to refer to the subject of any
request for location information. The term Device is used
specifically as the subject of an LCP, consistent with
[I-D.ietf-geopriv-http-location-delivery]. Both these terms are
defined in [RFC3693].
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 [RFC2119].
3. Target Identity
Identifiers are used as the starting point in location determination.
They should not be confused with measurement information
([I-D.thomson-geopriv-held-measurements]). Measurement information
is information about a Device and the time varying details of its
network attachment. Identifiers might be associated with a different
Target over time, but the their purpose is to identify the Target,
not to describe its environment or network attachment.
Use of any identifier MUST only be allowed if it uniquely identifies
a single Target. In some circumstances, certain of these identifiers
are either temporary or could potentially identify multiple devices.
Identifiers that are transient or ambiguous could be exploited by an
attacker to either gain information about another device or to obtain
misleading information.
The identifiers described in this section SHOULD only be used where
that identifier is used as the basis for location determination. It
Winterbottom, et al. Expires August 29, 2009 [Page 5]
Internet-Draft HELD Identity February 2009
is tempting for a LIS implementation to allow alternative identifiers
for convenience or some other perceived benefit. However, care needs
to be taken to ensure that the binding between the indicated
identifier and the identifier that is used for location determination
is unique and not subject to attacks.
3.1. Identifier Format and Protocol Details
XML elements are used to express the Target identity. The "target"
element is used as a general container for identity information.
This document defines a basic set of identifiers. An example HELD
request, shown in Figure 1, includes an IP version 4 address.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
responseTime="8">
<locationType exact="true">geodetic</locationType>
<target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<ip v="4">192.0.2.5</ip>
</target>
</locationRequest>
Figure 1
A LIS that supports this specification echoes the "target" element in
a successful HELD response, including the identifiers that were used
as the basis for location determination. Absence of this indication
means that the location information was generated using the source IP
address in the request.
If an identifier is invalid, not supported by the LIS, or the
requester is not authorized to use that identifier, a HELD error
response of "badIdentifier". This code is registered in Section 7.3.
If the LIS requires an identifier that is not provided in the
request, the desired identifiers MAY be identified in the HELD error
response, using the "requiredIdentifiers" element. This element
contains a list of XML qualified names [W3C.REC-xml-names11-20060816]
that identify the identifier elements required by the LIS. Namespace
prefix bindings for the qualified names are taken from document
context. Figure 2 shows an example error indicating that the
requester needs to include a MAC address (Section 3.2.2) if the
request is to succeed.
Winterbottom, et al. Expires August 29, 2009 [Page 6]
Internet-Draft HELD Identity February 2009
<error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="badIdentifier" message="MAC address required"
xml:lang="en">
<requiredIdentifiers
xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
mac
</requiredIdentifiers>
</error>
Figure 2
3.2. Identifiers
A limited selection of identifiers are included in this document.
The basic Target identity schema allows for the inclusion of elements
from any namespace, therefore additional elements can be defined
using different XML namespaces.
3.2.1. IP Address
The "ip" element can express a Target identity as an IP address. An
optional "v" attribute identifies the IP version. The element uses
the textual format specific to the indicated IP version.
<target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<ip v="6">2001:DB8::1:ea7:fee1:d1e</ip>
</target>
In situations where location configuration does not require
additional identifiers, using IP address as an identifier enables
third party requests.
3.2.2. MAC Address
The media access control (MAC) address used by the IEEE 802 family of
access technologies is an identifier that is assigned to a particular
network device. A MAC address is a unique sequence that is either
assigned at the time of manufacture of a device, or assigned by a
local administrator. A MAC address rarely changes; therefore, a MAC
address is an appropriate identifier for a Device.
<target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<mac>A0-12-34-56-78-90</mac>
</target>
Winterbottom, et al. Expires August 29, 2009 [Page 7]
Internet-Draft HELD Identity February 2009
3.2.3. TCP or UDP Port Number
On its own, a TCP or UDP port number is insufficient to uniquely
identify a single host, but in combination with an IP address, it can
be used to identify a Target.
Use of a particular port number can be transient; often significantly
more than use of any given IP address. However, widespread use of
network address translation (NAT) means that some Targets cannot be
uniquely identified by IP address alone. An individual Target might
be identified by a flow of packets that it generates. Providing that
a LIS has sufficient knowledge of the mappings used by the NAT, an
individual target on the remote side of the NAT might be able to be
identified uniquely.
<target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<ip v="6">2001:DB8::1:ea7:fee1:d1e</ip>
<udpport>51393</udpport>
</target>
As with any identifier, use of port numbers is contingent on the
value remaining consistent over time. Use of port numbers is not
suitable if port numbers cannot be deterministically attributed to a
unique Target over a sufficient period of time.
3.2.4. Network Access Identifier
A Network Access Identifier (NAI) [RFC4282] is an identifier used in
network authentication in a range of networks. The identifier
establishes a user identity within a particular domain. Often,
network services use an NAI in relation to location records, tying
network access to user authentication and authorization.
<target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<nai>user@example.net</nai>
</target>
Note: The formal grammar for NAI permits invalid Unicode, which
cannot be expressed using XML. This is a known problem with that
grammar. Any NAI that contains invalid character sequences cannot
be used as a Target identifier.
3.2.5. URI
A Target can be identified by a URI. Any URI can be used providing
that the requester and LIS have a common understanding of the
semantics implied by use of the URI.
Winterbottom, et al. Expires August 29, 2009 [Page 8]
Internet-Draft HELD Identity February 2009
<target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<uri>sip:user@example.net;gr=kjh29x97us97d</uri>
</target>
3.2.6. Hostname
A domain name can be used as the basis for identification using the
"hostname" element.
<target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<hostname>host.example.net</hostname>
</target>
3.2.7. Directory Number
Telephony devices are typically identified by the number that is used
to reach them. Within enterprises, where globally accessible
telephone numbers might not be used, a directory number is the usual
form of identification.
<target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<dn>7515</dn>
</target>
3.2.8. Cellular Telephony Identifiers
A range of different forms of mobile station identifiers are used for
different cellular telephony systems. Elements are defined for these
identifiers. The following identifiers are defined:
msisdn: The Mobile Subscriber Integrated Services Digital Network
Number (MSISDN) is an E.164 number between 6 and 15 digits long.
imsi: The International Mobile Subscriber Identity (IMSI) an
identifier associated with all GSM and UMTS mobile subscribers.
imei: The International Mobile Equipment Identifier (IMEI) is a
unique device serial number up to 15 digits long.
min: The Mobile Identification Number (MIN) is a unique number
assigned to CDMA handsets.
mdn: The Mobile Directory Number (MDN) is an E.164 number, with
usage similar to MSISDN.
<target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<msisdn>11235550123</msisdn>
Winterbottom, et al. Expires August 29, 2009 [Page 9]
Internet-Draft HELD Identity February 2009
</target>
3.2.9. DHCP Unique Identifier
The Dynamic Host Configuration Protocol (DHCP) uses a binary
identifier for its clients. The DHCP Unique Identifier (DUID) is
expressed in Option 61 of DHCPv4 (see [RFC4361]) or Option 1 of
DHCPv6 and follows the format defined in Section 9 of [RFC3315]. The
"duid" element includes the binary value of the DUID expressed in
hexadecimal.
<target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<duid>1234567890AaBbCcDdEeFf</duid>
</target>
4. XML Schema
<?xml version="1.0"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held:id"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:id="urn:ietf:params:xml:ns:geopriv:held:id"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- Target Identity -->
<xs:element name="target" type="id:targetIdentity"/>
<xs:complexType name="targetIdentity">
<xs:sequence>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="requiredIdentifiers" type="id:qnameList"/>
<xs:simpleType name="qnameList">
<xs:list itemType="xs:QName"/>
</xs:simpleType>
<xs:element name="ip" type="id:ipAddress"/>
<xs:complexType name="ipAddress">
<xs:simpleContent>
<xs:extension base="xs:token">
<xs:attribute name="v" use="optional">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:pattern value="[\da-fA-F]"/>
</xs:restriction>
</xs:simpleType>
Winterbottom, et al. Expires August 29, 2009 [Page 10]
Internet-Draft HELD Identity February 2009
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="mac" type="id:macAddress"/>
<xs:simpleType name="macAddress">
<xs:restriction base="xs:token">
<xs:pattern value="[\da-fA-F]{2}(-[\da-fA-F]{2}){5}"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="udpport" type="id:portNumber"/>
<xs:element name="tcpport" type="id:portNumber"/>
<xs:simpleType name="portNumber">
<xs:restriction base="xs:nonNegativeInteger">
<xs:maxInclusive value="65535"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="nai" type="xs:token"/>
<xs:element name="uri" type="xs:anyURI"/>
<xs:element name="dn" type="id:digits"/>
<xs:simpleType name="digits">
<xs:restriction base="xs:token">
<xs:pattern value="[\d]+"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="hostname" type="id:domainName"/>
<xs:simpleType name="domainName">
<xs:restriction base="xs:token">
<!-- the following pattern does not include whitespace;
whitespace is added only to conform to document
formatting restrictions -->
<xs:pattern value="([A-Za-z\d]([A-Za-z\d-]*[A-Za-z\d])*\.)*
[A-Za-z\d]([A-Za-z\d-]*[A-Za-z\d])*"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="duid" type="xs:hexBinary"/>
<xs:element name="msisdn" type="id:e164"/>
<xs:element name="imsi" type="id:e164"/>
<xs:element name="imei" type="id:digit15"/>
<xs:element name="min" type="id:digit10"/>
Winterbottom, et al. Expires August 29, 2009 [Page 11]
Internet-Draft HELD Identity February 2009
<xs:element name="mdn" type="id:e164"/>
<xs:simpleType name="e164">
<xs:restriction base="id:digit15">
<xs:minLength value="6"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="digit15">
<xs:restriction base="id:digits">
<xs:maxLength value="15"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="digit10">
<xs:restriction base="id:digits">
<xs:length value="10"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
5. Privacy Considerations
A location configuration protocol has a very simple privacy model.
Because the requester is also the Target, it can be assumed that
providing that requester with location information is allowed. This
"LCP policy" makes the simple assumption that as the subject of the
location information, the Target is also permitted access to that
information. In effect, an LCP server (that is, the LIS) follows a
single rule policy that states that the Target is the only authorized
Location Recipient.
Note: HELD explicitly takes the position that the Target is a Device
and not a person. For the purpose of discussion related to
privacy, this distinction is not important. In this section,
Target refers equally to Device and person.
When Target identity is used, the "LCP policy" is only applicable if
the identity of requester and Target are identical. If the
authenticated identity of the requester and the Target are the same,
the security and privacy considerations of the base HELD protocol
[I-D.ietf-geopriv-http-location-delivery] MAY be applied by a LIS.
The LIS MUST NOT use LCP policy unless it can authenticate the
requester identity is the same as the requested identity. Requester
and target identities MUST be identical, related identities are not
sufficient.
For example, it is not appropriate to apply LCP policy where a
requester is authenticated by NAI and the supplied Target identity
is a MAC address, even if that MAC address is currently registered
Winterbottom, et al. Expires August 29, 2009 [Page 12]
Internet-Draft HELD Identity February 2009
with the network under the given NAI. In this case, the requester
might be requesting from a different MAC address registered under
the same NAI. The correct way of gaining authorization is to
establish a policy that permits this particular request as a third
party request.
The LCP policy does not allow requests made by third parties. If a
LIS permits requests from third parties using identity extensions, it
assumes the rule of a Location Server (LS). HELD becomes a more
general location request protocol--a "using protocol" by the
definitions in [RFC3693]--and the privacy considerations for using
protocols apply. As a Location Server, the LIS MUST explicitly
authorize requests according to the policies that are provided by
Rule Makers, including the Target. This includes authentication of
requesters where required by the authorization policies.
An organization that provides a LIS that allows third party requests
SHOULD provide a means for a Rule Maker to specify authorization
policies before allowing third party requests for that Target's
location. Until an authorization policy is established, the LIS MUST
reject requests by third parties.
When the LIS is operated by the Target's access network, the
relationship between the Target and the LIS can be transient.
However, the process of establishing network access usually results
in a form of agreement between the Target and the network provider.
This process offers a natural vehicle for establishing location
privacy policies. Establishing authorization policy might be a
manual process, an explicit part of the terms of service for the
network, or an automated system that accepts formal authorization
policies (see [RFC4745], [RFC4825]). This document does not mandate
any particular mechanism for establishing an authorization policy.
6. Security Considerations
The security considerations in
[I-D.ietf-geopriv-http-location-delivery] describe the use of TLS for
server authentication, confidentiality and protection from
modification. These protections apply to both LCP requests and the
requests made by third parties.
All HELD requests MUST be authenticated by the LIS. How
authentication is accomplished and what assurances are desired is a
matter for policy. The base HELD protocol uses return reachability--
the proof of ownership of an IP address implied by the requester
being able to successfully complete a TCP handshake. It is
RECOMMENDED that any means of authentication provide at least this
degree of assurance. [[MT: last sentence too subjective?]] For
Winterbottom, et al. Expires August 29, 2009 [Page 13]
Internet-Draft HELD Identity February 2009
requests that include Target identity, the LIS MUST support
authentication of TLS clients.
6.1. Location Configuration Protocol Requests
Requests made by a Device in the context of a location configuration
protocol are covered by the same set of protections offered by HELD.
LCP requests are authorized under an "LCP policy" that permits a
Target access to location information about itself.
Identity information provided by the Device is private data that
might be sensitive. The Device provides this information in the
expectation that it assists the LIS in providing the Device a
service. The LIS MUST NOT use identity information for any other
purpose other than serving the request that includes that
information.
6.2. Third Party Requests
Requests from third parties have the same requirements for server
authentication, confidentiality and protection from modification as
LCP requests. However, because the third party needs to be
authorized, the requester MUST be authenticated by the LIS. In
addition, third party requests MUST be explicitly authorized by a
policy that is established by a Rule Maker.
More detail on the privacy implications of third party requests are
covered in Section 5.
7. IANA Considerations
This document registers an XML namespace and schema with IANA in
accordance with guidelines in [RFC3688]. It also creates a new
registry for device identity types, and stipulates how new types are
to be added.
7.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:id
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:held:id", as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:held:id
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), James Winterbottom
(james.winterbottom@andrew.com).
Winterbottom, et al. Expires August 29, 2009 [Page 14]
Internet-Draft HELD Identity February 2009
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 Target Identity Parameters</title>
</head>
<body>
<h1>Namespace for HELD Target Identity Parameters</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:id</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
7.2. XML Schema Registration
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:geopriv:held:id
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
James Winterbottom (james.winterbottom@andrew.com).
Schema: The XML for this schema can be found as the entirety of
Section 4 of this document.
7.3. Registration of HELD 'badIdentifier' Error Code
This section registers the "badIdentifier" error code in the "Geopriv
HELD Registries, Error codes for HELD" IANA registry.
badIdentifier This error code indicates that the Target identifiers
used in the HELD request were either: not supported by the LIS,
badly formatted, or that the requester was not authorized to make
a erquest for that identifier.
8. Acknowledgements
The authors wish to thank the NENA VoIP location working group for
their assistance in the definition of the schema used in this
document. Special thanks go to Barbara Stark, Guy Caron, Nadine
Winterbottom, et al. Expires August 29, 2009 [Page 15]
Internet-Draft HELD Identity February 2009
Abbott, Jerome Grenier and Martin Dawson. Bob Sherry provided input
on use of URIs. Thanks to Adam Muhlbauer and Eddy Corbett for
providing further corrections. Bernard Aboba provided extensive
feedback on use cases and the security model; Bernard, along with
Alan DeKok, also helped resolve an issue with NAIs. Ray Bellis
provided motivation for the protocol port parameters.
9. References
9.1. Normative references
[RFC2119] Bradner, S., "Key words
for use in RFCs to
Indicate Requirement
Levels", BCP 14, RFC 2119,
March 1997.
[RFC3315] Droms, R., Bound, J.,
Volz, B., Lemon, T.,
Perkins, C., and M.
Carney, "Dynamic Host
Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315,
July 2003.
[RFC3688] Mealling, M., "The IETF
XML Registry", BCP 81,
RFC 3688, January 2004.
[RFC4282] Aboba, B., Beadles, M.,
Arkko, J., and P. Eronen,
"The Network Access
Identifier", RFC 4282,
December 2005.
[RFC4361] Lemon, T. and B.
Sommerfeld, "Node-specific
Client Identifiers for
Dynamic Host Configuration
Protocol Version Four
(DHCPv4)", RFC 4361,
February 2006.
[I-D.ietf-geopriv-http-location-delivery] Barnes, M., Winterbottom,
J., Thomson, M., and B.
Stark, "HTTP Enabled
Location Delivery (HELD)",
draft-ietf-geopriv-http-
Winterbottom, et al. Expires August 29, 2009 [Page 16]
Internet-Draft HELD Identity February 2009
location-delivery-12 (work
in progress),
January 2009.
[I-D.ietf-geopriv-l7-lcp-ps] Tschofenig, H. and H.
Schulzrinne, "GEOPRIV
Layer 7 Location
Configuration Protocol;
Problem Statement and
Requirements", draft-ietf-
geopriv-l7-lcp-ps-09 (work
in progress),
February 2009.
[W3C.REC-xml-names11-20060816] Tobin, R., Layman, A.,
Bray, T., and D.
Hollander, "Namespaces in
XML 1.1 (Second Edition)",
World Wide Web Consortium
Recommendation REC-xml-
names11-20060816,
August 2006, <http://
www.w3.org/TR/2006/
REC-xml-names11-20060816>.
9.2. Informative references
[RFC3693] Cuellar, J., Morris, J.,
Mulligan, D., Peterson,
J., and J. Polk, "Geopriv
Requirements", RFC 3693,
February 2004.
[RFC3825] Polk, J., Schnizlein, J.,
and M. Linsner, "Dynamic
Host Configuration
Protocol Option for
Coordinate-based Location
Configuration
Information", RFC 3825,
July 2004.
[RFC4388] Woundy, R. and K. Kinnear,
"Dynamic Host
Configuration Protocol
(DHCP) Leasequery",
RFC 4388, February 2006.
Winterbottom, et al. Expires August 29, 2009 [Page 17]
Internet-Draft HELD Identity February 2009
[RFC4745] Schulzrinne, H.,
Tschofenig, H., Morris,
J., Cuellar, J., Polk, J.,
and J. Rosenberg, "Common
Policy: A Document Format
for Expressing Privacy
Preferences", RFC 4745,
February 2007.
[RFC4776] Schulzrinne, H., "Dynamic
Host Configuration
Protocol (DHCPv4 and
DHCPv6) Option for Civic
Addresses Configuration
Information", RFC 4776,
November 2006.
[RFC4825] Rosenberg, J., "The
Extensible Markup Language
(XML) Configuration Access
Protocol (XCAP)",
RFC 4825, May 2007.
[I-D.ietf-ecrit-phonebcp] Rosen, B. and J. Polk,
"Best Current Practice for
Communications Services in
support of Emergency
Calling", draft-ietf-
ecrit-phonebcp-07 (work in
progress), January 2009.
[I-D.thomson-geopriv-held-measurements] Thomson, M. and J.
Winterbottom, "Using
Device-provided Location-
Related Measurements in
Location Configuration
Protocols", draft-thomson-
geopriv-held-measurements-
03 (work in progress),
October 2008.
[LLDP] IEEE, "802.1AB, IEEE
Standard for Local and
Metropolitan area
networks, Station and
Media Access Control
Connectivity Discovery",
June 2005.
Winterbottom, et al. Expires August 29, 2009 [Page 18]
Internet-Draft HELD Identity February 2009
Authors' Addresses
James Winterbottom
Andrew Corporation
PO Box U40
University of Wollongong, NSW 2500
AU
EMail: james.winterbottom@andrew.com
Martin Thomson
Andrew Corporation
PO Box U40
University of Wollongong, NSW 2500
AU
EMail: martin.thomson@andrew.com
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Richard Barnes
BBN Technologies
9861 Broken Land Pkwy, Suite 400
Columbia, MD 21046
USA
Phone: +1 410 290 6169
EMail: rbarnes@bbn.com
Winterbottom, et al. Expires August 29, 2009 [Page 19]