Geopriv J. Winterbottom
Internet-Draft M. Thomson
Intended status: Standards Track Andrew Corporation
Expires: April 26, 2008 October 24, 2007
HELD Device identity Extensions
draft-winterbottom-geopriv-held-identity-extensions-03.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 April 26, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Winterbottom & Thomson Expires April 26, 2008 [Page 1]
Internet-Draft HELD-ID-EXT October 2007
Abstract
This document defines a set of URIs for Device identities and a XML
containment schema. These can be used in conjunction with HELD to
provide Device identification beyond source IP Address. Examples and
usage in HELD message syntax are provided.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. URI Definitions . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Ethernet MAC URI . . . . . . . . . . . . . . . . . . . 5
3.1.2. IP Address URIs . . . . . . . . . . . . . . . . . . . 5
3.2. Device Identity Schema . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 10
5.2. XML Schema Registration . . . . . . . . . . . . . . . . . 10
5.3. Identifier 'type' Attribute values . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative references . . . . . . . . . . . . . . . . . . . 13
7.2. Informative references . . . . . . . . . . . . . . . . . . 13
Appendix A. Alternatives . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Winterbottom & Thomson Expires April 26, 2008 [Page 2]
Internet-Draft HELD-ID-EXT October 2007
1. Introduction
Protocols such as HELD [I-D.ietf-geopriv-http-location-delivery] need
to identify a device in order to perform some task. Basic HELD only
provides device identity through the IP address of the requesting
Target, while [I-D.ietf-geopriv-l7-lcp-ps] provides examples of where
this may be insufficent. This memo defines a set of URIs an a
containment schema that allow the specification of device identity
beyond source IP address and may be used with HELD and general
presence documents as described in [RFC4479].
Winterbottom & Thomson Expires April 26, 2008 [Page 3]
Internet-Draft HELD-ID-EXT October 2007
2. Terminology
The key conventions and terminology used in this document are defined
as follows:
This document reuses the terms Device and 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 & Thomson Expires April 26, 2008 [Page 4]
Internet-Draft HELD-ID-EXT October 2007
3. Details
The details of this memo consist of a simple schema extension for
HELD to support the inclusion of a device identity in the form of a
URI or typed-token, and a set of URI definitions that can be used for
device identities.
3.1. URI Definitions
The URIs defined in this section are designed to identify a device.
The URIs identify the Device, they do not identify measurements or
sighting data associated with a Device, such as the switch and port
information to which the Device is attached (which can 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, but it MUST uniquely identify a device within a network
at the time it is used.
The URIs in this section are defined using ABNF (augmented Backus-
Naur form) described in [RFC2234].
3.1.1. Ethernet MAC URI
This is the Ethernet hardware address of the device. The form of
this URI is used as example in [RFC4479] and this section provides
the ABNF for this URI type. An example of its use is provided in
Figure 5.
mac-uri = "mac:" 12*12HEXDIG
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 Device because, for
some reason, the necessary information was not provided by the
Device.
ip-uri = "ip:" ipv4 / ipv6
ipv4 = "IPv4+" IPv4-Address
IPv4-Address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
ipv6 = "IPv6+" hexpart [ ":" IPv4-Address ]
hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
Winterbottom & Thomson Expires April 26, 2008 [Page 5]
Internet-Draft HELD-ID-EXT October 2007
An example of a location request including a URI in this form to
identify the Target device is shown in Figure 3.
<locationRequest
xmlns="urn:ietf:params:xml:ns:geopriv:held" responseTime="8">
<locationType>geodetic</locationType>
<heldDevice xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<uri>ip:IPv4+192.0.2.5</uri>
</heldDevice>
</locationRequest>
Figure 3: HELD Location Request Using an IP Address
Note that the URI types are not case sensative and the iP:ipv4+
192.0.2.5 is still a valid URI.
3.2. Device Identity Schema
This section defines a schema that can be used to provide device
identities in a HELD location request.
Winterbottom & Thomson Expires April 26, 2008 [Page 6]
Internet-Draft HELD-ID-EXT October 2007
<?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:typeToken"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="deviceIdentity" type="heldDI:idParameters"/>
</xs:schema>
Figure 4: Device identity schema
Winterbottom & Thomson Expires April 26, 2008 [Page 7]
Internet-Draft HELD-ID-EXT October 2007
The schema provided in Figure 4 allows a URI and/or token to be
provided so a Device 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>
When the <identifier> element is used the "type" attribute is
mandatory as this 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 5.3.
A HELD location request sent by a device using the schema shown in
Figure 4 to provide its identity as a mac URI would look similar to
Figure 5.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
responseTime="8">
<locationType>geodetic</locationType>
<heldDevice xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<uri>mac:01ab34ef690c</uri>
</heldDevice>
</locationRequest>
Figure 5: HELD Location Request URI example
Similarly a device 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 6.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
responseTime="8">
<locationType>geodetic</locationType>
<heldDevice xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<identifier type="dhcpClientId">035552764</identifier>
</heldDevice>
</locationRequest>
Figure 6: HELD Location Request Identifier example
Winterbottom & Thomson Expires April 26, 2008 [Page 8]
Internet-Draft HELD-ID-EXT October 2007
4. Security Considerations
An Operator of a LIS that supports this schema extension needs to
ensure that location provided to nodes requesting location in this
manner are entitled to the location information being requested. In
some circumstances support of this schema extension will be
inappropriate and alternative measures will need to be employed.
Winterbottom & Thomson Expires April 26, 2008 [Page 9]
Internet-Draft HELD-ID-EXT October 2007
5. 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.
5.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
5.2. XML Schema Registration
This section registers an XML schema as per the guidelines in
[RFC3688].
Winterbottom & Thomson Expires April 26, 2008 [Page 10]
Internet-Draft HELD-ID-EXT October 2007
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 4 of this document.
5.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 [RFC2434]
this registry operates under the "Expert Review" rule.
The following identifier types are registered as part of this memo:
o 'dhcpClientId' The DHCP client identifier as defined by DHCP
option 61 in [RFC2132]
o 'msisdn' The Mobile Station International Subscriber Dial Number.
This is an E.164 number made up of 6 to 15 digits
o '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.
o 'imei' The International Mobile Equipment identifier. This is an
electronic serial number for a mobile device and is consists of up
to 15 digits
o 'min' Mobile Identification Number. A unique equipment identifier
assigned to CDMA handsets.
o 'mdn' Mobile Dial Number. An E.164 number made up of 6 to 15
digits.
o 'hostname' The hostname or FQDN of the device.
Winterbottom & Thomson Expires April 26, 2008 [Page 11]
Internet-Draft HELD-ID-EXT October 2007
6. 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.
Winterbottom & Thomson Expires April 26, 2008 [Page 12]
Internet-Draft HELD-ID-EXT October 2007
7. References
7.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-02 (work in
progress), September 2007.
[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-05 (work in
progress), September 2007.
[I-D.thomson-geopriv-held-measurements]
Thomson, M. and J. Winterbottom, "Using Device-provided
Location Measurements in HELD",
draft-thomson-geopriv-held-measurements-00 (work in
progress), October 2007.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
7.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.
[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",
Winterbottom & Thomson Expires April 26, 2008 [Page 13]
Internet-Draft HELD-ID-EXT October 2007
RFC 3046, January 2001.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,
July 2006.
Winterbottom & Thomson Expires April 26, 2008 [Page 14]
Internet-Draft HELD-ID-EXT October 2007
Appendix A. Alternatives
An alternative to providing the mobile identifiers as an <identifier>
'type' they could be defined as URI types as shown below. This would
fit seeming well as other telephony device identifiers are already
specified using telephone URIs [RFC3966].
mobile-uri = "mob:" mobile-identifier
mobile-identifier = imsi / msisdn / imei / min / mdn
imsi = "imsi:" 6*15DIGIT
msisdn = "msisdn:" 6*15DIGIT
imei = "imei:" 1*15DIGIT
min = "min:" 1*15DIGIT
mdn = "mdn:" 6*15DIGIT
The URIs defined above allow an easy way for the Device to specify
this binding to a LIS by using a HELD location request. When the LIS
receives the location request in Figure 9 it is able to bind the
source IP address of the location request with the provided MSISDN.
<locationRequest
xmlns="urn:ietf:params:xml:ns:geopriv:held" responseTime="8">
<locationType>geodetic</locationType>
<heldDevice xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<uri>mob:msisdn:61448266004</uri>
</heldDevice>
</locationRequest>
Figure 9: HELD Location Request Using MSISDN
Winterbottom & Thomson Expires April 26, 2008 [Page 15]
Internet-Draft HELD-ID-EXT October 2007
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
Winterbottom & Thomson Expires April 26, 2008 [Page 16]
Internet-Draft HELD-ID-EXT October 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).
Winterbottom & Thomson Expires April 26, 2008 [Page 17]