Geopriv J. Winterbottom
Internet-Draft M. Thomson
Intended status: Standards Track Andrew Corporation
Expires: July 19, 2009 H. Tschofenig
Nokia Siemens Networks
R. Barnes
BBN Technologies
January 15, 2009
HELD Identity Extensions
draft-winterbottom-geopriv-held-identity-extensions-08
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 July 19, 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Winterbottom, et al. Expires July 19, 2009 [Page 1]
Internet-Draft HELD Identity January 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 an
Target's location can be determined based on its IP address.
Two additional use cases are addresses by this document. In the
first, the source IP address in the request is not the only
identifier for the Target. 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 additional identifiers assisting the location
determination process. It defines a set of URIs for Target
identifiers and an XML containment schema. This extension is used in
conjunction with HELD to provide Target identification, and set of
criteria of when to use this extensions are provided. Examples and
usage in HELD message syntax are also shown.
Winterbottom, et al. Expires July 19, 2009 [Page 2]
Internet-Draft HELD Identity January 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Applications . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Identity Extension Details . . . . . . . . . . . . . . . . . . 7
3.1. URI Definitions . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. MAC Address URI . . . . . . . . . . . . . . . . . . . 7
3.1.2. IP Address URIs . . . . . . . . . . . . . . . . . . . 7
3.2. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5.1. Location Configuration Protocol Requests . . . . . . . . . 13
5.2. Third Party Requests . . . . . . . . . . . . . . . . . . . 13
5.3. Distinguishing LCP Requests from Third Party Requests . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 15
6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 15
6.3. Identifier 'type' Attribute values . . . . . . . . . . . . 16
6.4. URI Type Attribute Values . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative references . . . . . . . . . . . . . . . . . . . 19
8.2. Informative references . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Winterbottom, et al. Expires July 19, 2009 [Page 3]
Internet-Draft HELD Identity January 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 Target simpler for LCPs, since IP
datagrams that carry the request already carry an identifier for the
Target, 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 Target.
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 of the request. 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. The
identifiers are defined as URIs that include a range of different
types of identification information. Finally, 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
Target and a LIS. That is, an LCP is limited to the Target
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 Target-LIS interaction
obviously introduces a new set of privacy concerns. In an LCP, the
requester is implicitly authorized to access the request 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 4.
1.1. Applications
The use of additional identifiers in HELD falls into two categories.
A Device can use these parameters to provide additional
Winterbottom, et al. Expires July 19, 2009 [Page 4]
Internet-Draft HELD Identity January 2009
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
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
Device. 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 an LCP
or they are unable to successfully retrieve location information.
Winterbottom, et al. Expires July 19, 2009 [Page 5]
Internet-Draft HELD Identity January 2009
2. Terminology
This document reuses the term Target, as defined in [RFC3693].
This document uses the term Location Information Server, LIS as
described in [I-D.ietf-geopriv-l7-lcp-ps].
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].
Winterbottom, et al. Expires July 19, 2009 [Page 6]
Internet-Draft HELD Identity January 2009
3. Identity Extension Details
This section defines the details of the schema extension for HELD to
support the inclusion of a Target identity in the form of a URI or
typed-token. A set of URI definitions that can be used to specify
these identities is also provided.
3.1. URI Definitions
The URIs defined in this section are designed to identify a Target;
they do not identify measurements or sighting data associated with a
Target, such as the switch and port information to which the Target
is attached. This information may, for example, be acquired using
DHCP relay information [RFC3046] or LLDP [LLDP]. Device measurements
and sighting data are described in
[I-D.thomson-geopriv-held-measurements]. The identity provided may
be transitory, such as an IP address that is leased from a DHCP
server pool.
The URIs in the following sub-sections are defined using ABNF
(augmented Backus-Naur form) described in [RFC5234].
3.1.1. MAC Address URI
A MAC URI represents the media access control address of the Device,
as defined in the IEEE 802 series of specifications. The ABNF for
this URI type is defined as:
mac-uri = "mac:" 2*2HEXDIG 5*5macdig
macdig = "-" 2*2HEXDIG
MAC URIs can be used in the same manner as is suggested by the
undefined "mac:" URIs used in examples in RFC 4479 [RFC4479]. An
example of its use is provided in Figure 3.
3.1.2. IP Address URIs
This section provides the ABNF for IP version 4 and IP version 6
URIs. One application of this URI scheme is described in
[I-D.ietf-geopriv-l7-lcp-ps], where an outbound SIP proxy needs to
make location requests to a LIS on behalf of a Target because, for
some reason, the necessary information was not provided by the
Target.
ip-uri = "ip:" ipv4 / ipv6
ipv4 = "IPv4+" IPv4address ; from RFC 3986
ipv6 = "IPv6+" IPv6address ; from RFC 3986
Winterbottom, et al. Expires July 19, 2009 [Page 7]
Internet-Draft HELD Identity January 2009
The definitions for "IPv4address" and "IPv6address" are taken from
[RFC3986].
An example of a location request including a URI in this form to
identify the Target device is shown in Figure 1.
<locationRequest
xmlns="urn:ietf:params:xml:ns:geopriv:held" responseTime="8000">
<locationType>geodetic</locationType>
<deviceIdentity xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<uri>ip:IPv4+192.0.2.5</uri>
</deviceIdentity>
</locationRequest>
Figure 1: HELD Location Request Using an IP Address
Note that the URI types are not case sensitive and the iP:ipv4+
192.0.2.5 is still a valid URI.
3.2. Schema
This section defines a schema that is used to provide Target
identifiers in a HELD location request.
Winterbottom, et al. Expires July 19, 2009 [Page 8]
Internet-Draft HELD Identity January 2009
<?xml version="1.0"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held:id"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:heldDI="urn:ietf:params:xml:ns:geopriv:held:id"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- typedURI definition -->
<xs:complexType name="typedURI">
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute name="type" type="xs:token"
use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<!-- typedToken definition -->
<xs:complexType name="typedToken">
<xs:simpleContent>
<xs:extension base="xs:token">
<xs:attribute name="type" type="xs:token"
use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<!-- Identity Parameters -->
<xs:complexType name="idParameters">
<xs:sequence>
<xs:element name="uri" type="heldDI:typedURI"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="identifier" type="heldDI:typedToken"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="deviceIdentity" type="heldDI:idParameters"/>
</xs:schema>
Figure 2: Schema
Winterbottom, et al. Expires July 19, 2009 [Page 9]
Internet-Draft HELD Identity January 2009
The schema provided in Figure 2 allows a URI and/or token to be
provided so that a Target can identify itself by more than just its
IP address. The URI can also include an optional "type" attribute so
that URIs that might otherwise look the same can be distinguished
based on their usage.
For example <uri type="gruu">sip:callee@example.com</uri> or <uri
type="aor">sip:callee@example.com</uri>
An IANA registry is established for defining uri token types, and
this defined in Section 6.4.
When the <identifier> element is used the "type" attribute is
mandatory as it tells the LIS or receiving entity how to interpret
the identifier. An IANA registry is established for the central
repository for recognized identifier types. The set of initial types
is provided in Section 6.3.
A HELD location request sent by a device using the schema shown in
Figure 2 to provide its identity as a MAC URI would look similar to
Figure 3.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
responseTime="8000">
<locationType>geodetic</locationType>
<deviceIdentity xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<uri>mac:01-ab-34-ef-69-0c</uri>
</deviceIdentity>
</locationRequest>
Figure 3: HELD Location Request URI example
Similarly a Target identifying itself using its DHCP client
identifier (DHCP option 61 in [RFC2132]) in a location request to a
LIS would send something similar to Figure 4.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
responseTime="8000">
<locationType>geodetic</locationType>
<deviceIdentity xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<identifier type="dhcpClientId">035552764</identifier>
</deviceIdentity>
</locationRequest>
Figure 4: HELD Location Request Identifier example
Winterbottom, et al. Expires July 19, 2009 [Page 10]
Internet-Draft HELD Identity January 2009
4. 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. Such
a 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 the discussion in this
section, the two are considered one and the same.
When the identity extensions defined above are used by the Target to
augment an LCP query, this default "LCP policy" remains the relevant
policy, and the security and privacy considerations of the base HELD
protocol [I-D.ietf-geopriv-http-location-delivery] apply. The only
augmentation required is that if the LCP policy is to be applied, the
LIS MUST authenticate that the requested identity is in fact that of
the requestor, and MUST deny access to location if this
authentication fails.
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.
For a network operator, authorization 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.
When the LIS is operated by the Target's access network, the
relationship between the Target and the LIS can be transient.
Winterbottom, et al. Expires July 19, 2009 [Page 11]
Internet-Draft HELD Identity January 2009
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.
Winterbottom, et al. Expires July 19, 2009 [Page 12]
Internet-Draft HELD Identity January 2009
5. 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.
5.1. Location Configuration Protocol Requests
Requests made by a Device (or Target) in the context of a location
configuration protocol are covered by the same set of protections
offered by HELD. All the security considerations for HELD apply.
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.
Falsification of identification information could be used by
malicious Devices to gain access to location information for others,
or to acquire false location information. For location
configuration, the LIS MUST ensure that claimed identity information
belongs to the requester before relying upon it. If this
verification cannot be performed, the LIS MUST treat the request as
if it were a third party request.
Note: This might seem to negate much of the advantage provided by
the inclusion of identity parameters for the LCP case. However,
checking that the identity information is correct is generally
more feasible than acquiring the information in the first place.
For example, a MAC address provided by a target device can be
verified by performing a DHCP lease-query ([RFC4388]). Identity
extensions such as tel: URIs and hostnames can be validated using
network services such as the DNS, ENUM, LDAP and SIP registrars.
5.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. The LIS
MUST NOT provide location information to unauthorized requesters.
A LIS that allows requests from third parties MUST support TLS client
Winterbottom, et al. Expires July 19, 2009 [Page 13]
Internet-Draft HELD Identity January 2009
authentication.
More detail on the privacy implications of third party requests are
covered in Section 4.
5.3. Distinguishing LCP Requests from Third Party Requests
There is a risk that a LIS that supports both LCP requests as well as
requests from third parties could leak information. To successfully
exploit this leak, a third party could convince the server that its
request is an LCP request and that the identity information it
provides indeed belongs to it. This could mean that the third party
is exempted from the mandatory authorization process.
A LIS that only provides LCP access to Targets is subject to the same
attack. If a Target can provide false identification information
that is accepted by the LIS, it can effectively act as an authorized
third party.
This is limited by the ability of the LIS to detect falsified
identity information. Implementations need to take care to verify
identity information as described in Section 5.1.
For all requests, the LIS MUST ensure that the requester is
authorized to receive location information for the specified Target
before providing that information.
Winterbottom, et al. Expires July 19, 2009 [Page 14]
Internet-Draft HELD Identity January 2009
6. 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.
6.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).
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 Device Identity Extensions</title>
</head>
<body>
<h1>Namespace for HELD Device Identity Extensions</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
6.2. XML Schema Registration
This section registers an XML schema as per the guidelines in
[RFC3688].
Winterbottom, et al. Expires July 19, 2009 [Page 15]
Internet-Draft HELD Identity January 2009
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
Figure 2 of this document.
6.3. Identifier 'type' Attribute values
This document requests that the IANA create a new registry for
identifier 'type' attribute values. These are text strings that
clarify how the value identifies the Device. Referring to [RFC5226]
this registry operates under the "Expert Review" rule.
The following identifier types are registered as part of this memo:
dhcpClientId: The DHCP client identifier as defined by DHCP option
61 in [RFC2132]
msisdn: The Mobile Station International Subscriber Dial Number.
This is an E.164 number made up of 6 to 15 digits
imsi: The International Mobile Subscriber identifier. A unique
identifier for GSM or UMTS mobile terminal made up of 6 to 15
digits that identify the country code, the network code and
device.
imei: The International Mobile Equipment identifier. This is an
electronic serial number for a mobile device and is consists of up
to 15 digits
min: Mobile Identification Number. A unique equipment identifier
assigned to CDMA handsets.
mdn: Mobile Dial Number. An E.164 number made up of 6 to 15 digits.
hostname: The hostname or FQDN of the device.
directoryNumber: The directory number of the device.
6.4. URI Type Attribute Values
This document requests that the IANA create a new registry for uri
'type' attribute values. These are text strings that clarify what a
URI actually identifies, and MUSt include the URI scheme to which the
type applies. Referring to [RFC5226] this registry operates under
the "Expert Review" rule.
Winterbottom, et al. Expires July 19, 2009 [Page 16]
Internet-Draft HELD Identity January 2009
The following identifier types are registered as part of this memo:
aor: The SIP address of record as defined [RFC3261]. Applies to
'sip:', 'sips:', 'pres:'
gruu: The Globally Routable User Agent URI (GRUU) as defined in
[I-D.ietf-sip-gruu]. Applies to 'sip:', 'sips:'
Winterbottom, et al. Expires July 19, 2009 [Page 17]
Internet-Draft HELD Identity January 2009
7. 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
Abbott, Jerome Grenier and Martin Dawson. Thanks also to Bob Sherry
for requesting that URI-types be supported which led to the typedURI
form. Thanks to Adam Muhlbauer and Eddy Corbett for providing
further corrections.
Winterbottom, et al. Expires July 19, 2009 [Page 18]
Internet-Draft HELD Identity January 2009
8. References
8.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[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-location-delivery-11 (work in
progress), December 2008.
[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-08 (work in
progress), June 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC3261] 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.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-15 (work in progress),
October 2007.
8.2. Informative references
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
Winterbottom, et al. Expires July 19, 2009 [Page 19]
Internet-Draft HELD Identity January 2009
[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-06 (work in progress),
November 2008.
[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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[LLDP] IEEE, "802.1AB, IEEE Standard for Local and Metropolitan
area networks, Station and Media Access Control
Connectivity Discovery", June 2005.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001.
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,
July 2006.
[RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration
Protocol (DHCP) Leasequery", RFC 4388, February 2006.
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based
Location Configuration Information", RFC 3825, July 2004.
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[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.
Winterbottom, et al. Expires July 19, 2009 [Page 20]
Internet-Draft HELD Identity January 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 July 19, 2009 [Page 21]