Geopriv J. Winterbottom
Internet-Draft M. Thomson
Intended status: Standards Track Andrew Corporation
Expires: January 15, 2009 H. Tschofenig
Nokia Siemens Networks
July 14, 2008
HELD Identity Extensions
draft-winterbottom-geopriv-held-identity-extensions-06.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 January 15, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Winterbottom, et al. Expires January 15, 2009 [Page 1]
Internet-Draft HELD-ID-EXT July 2008
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 appropriate in many environments.
However, when an entity acting on behalf of the Target would like to
request location information then the source IP address of the
request will lead to wrong results. In other cases the IP address is
not the only identifier that serves as an input to the location
determination procedure.
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 January 15, 2009 [Page 2]
Internet-Draft HELD-ID-EXT July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Criteria for using on behalf of location requests . . . . . . 6
4. Identity Extension Details . . . . . . . . . . . . . . . . . . 7
4.1. URI Definitions . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Ethernet MAC URI . . . . . . . . . . . . . . . . . . . 7
4.1.2. IP Address URIs . . . . . . . . . . . . . . . . . . . 7
4.2. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5.1. Device-provided identity extensions . . . . . . . . . . . 11
5.2. On behalf of requests . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 12
6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12
6.3. Identifier 'type' Attribute values . . . . . . . . . . . . 13
6.4. URI Type Attribute Values . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative references . . . . . . . . . . . . . . . . . . . 16
8.2. Informative references . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Winterbottom, et al. Expires January 15, 2009 [Page 3]
Internet-Draft HELD-ID-EXT July 2008
1. Introduction
Location Configuration Protocols, such as HELD
[I-D.ietf-geopriv-http-location-delivery], need to identify a Target
in order to determine its location. The base HELD specification only
provides Target identity through the IP address of the requesting
Target, while [I-D.ietf-geopriv-l7-lcp-ps] provides examples of where
this may be insufficient. This memo defines a set of URIs and a
containment schema that allows the entity requesting location
information to indicate a Target identifier beyond the source IP
address of the request.
In addition to a Target providing additional information about itself
in order to aid location determination, a trusted node can use the
techniques described in this memo to request location information
about a specific Target, on behalf of (OBO) that Target. Use cases
for this functionality are described in [I-D.ietf-geopriv-l7-lcp-ps]
and [I-D.ietf-ecrit-phonebcp] and focus on environments where a call-
server or proxy resides in the same administrative domain as the LIS,
and the Target has either failed, or is unable, to provide location
information when it is required to do so. This memo provides a set
of criteria that can be applied by operators considering an OBO-based
location deployment.
Winterbottom, et al. Expires January 15, 2009 [Page 4]
Internet-Draft HELD-ID-EXT July 2008
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 January 15, 2009 [Page 5]
Internet-Draft HELD-ID-EXT July 2008
3. Criteria for using on behalf of location requests
The general model for acquiring location in the Internet places the
onus on the end-point to acquire its location prior to invoking a
service that needs this information in order to operate correctly.
There is general acceptance from a range of organizations and
operators that this approach cannot ensure the operation of essential
services in the short to medium term with current terminal and
network deployments. Network operators do not, for the most part,
control or own user-terminal equipment, which means that they are not
in a position to ensure essential services will work correctly for
legacy devices connected to the network and this presents a dilema
that requires a standarized technical solution. The accepted
approach is to have a trusted node be able to request location on-
behalf-of of the end-point to facilitate the correct operation of
services deemed essential by the local jurisdiction. Examples of
essential services include, but are not limited to ambulance, law
enforcement, and fire services.
To support an on-behalf-of location request mechanism there is a need
for a strong trust relationship between the access and service
provider entities. This relationship should exist soley for the
purposes of providing services considered essential by the
jurisdiction. The essential service may be provided inside the local
access network, placing the access network and service provider in
same administrative domain. Alternatively, the essential service is
provided by a jurisdictional authority that has the right to request
the location information for a Target in an access network operating
in its legal boundaries.
In addition to a strong trust relationship the access and service
providers need to agree on a Target identifier. This identifier must
have the properties of allowing the essential service to identify the
LIS in the serving access network, and allowing the LIS to identify
the end-device in the access network.
Winterbottom, et al. Expires January 15, 2009 [Page 6]
Internet-Draft HELD-ID-EXT July 2008
4. 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.
4.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 [RFC2234].
4.1.1. Ethernet MAC URI
This is the Ethernet hardware address of the device, and is defined
as per the IEEE 802 specifications. The ABNF for this URI type is
defined as:
mac-uri = "mac:" 2*2HEXDIG 5*5macdig
macdig = "-" 2*2HEXDIG
This type of URI is, for example, used in RFC 4479 [RFC4479]. An
example of its use is provided in Figure 5.
4.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.
Winterbottom, et al. Expires January 15, 2009 [Page 7]
Internet-Draft HELD-ID-EXT July 2008
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
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>
<deviceIdentity xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<uri>ip:IPv4+192.0.2.5</uri>
</deviceIdentity>
</locationRequest>
Figure 3: 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.
4.2. Schema
This section defines a schema that is used to provide Target
identifiers in a HELD location request.
Winterbottom, et al. Expires January 15, 2009 [Page 8]
Internet-Draft HELD-ID-EXT July 2008
<?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 4: Schema
Winterbottom, et al. Expires January 15, 2009 [Page 9]
Internet-Draft HELD-ID-EXT July 2008
The schema provided in Figure 4 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 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>
<deviceIdentity xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<uri>mac:01-ab-34-ef-69-0c</uri>
</deviceIdentity>
</locationRequest>
Figure 5: 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 6.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
responseTime="8">
<locationType>geodetic</locationType>
<deviceIdentity xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<identifier type="dhcpClientId">035552764</identifier>
</deviceIdentity>
</locationRequest>
Figure 6: HELD Location Request Identifier example
Winterbottom, et al. Expires January 15, 2009 [Page 10]
Internet-Draft HELD-ID-EXT July 2008
5. Security Considerations
5.1. Device-provided identity extensions
Identity extensions proivded by the Target device are commonly
provided to assist the LIS in location determination. Where the LIS
is going to use this information it MUST be verifiable by the LIS,
the choice to perform this verification or not is left to the
operator of the service. A MAC address provided by a target device,
for example, can be verified by performing a DHCP lease-query based
described in [RFC4388]. Identity extensions such as tel uris and
hostnames can be validated using network services such as enum and
ldap.
Information that cannot be verified, or is found to be false MUST be
ignroed by the LIS.
5.2. On behalf of requests
The on behalf of mechanism allows the access network provider to
specify rules for location acqusition for essential local services.
The requirement to implement and comply with these rules will often
be outside the control of the access provider with legislation
mandating adherence. In such circumstances connectivity to the
access network by an end-device is an implicit acceptance of these
usage rules. Providers of access networks that divulge location in
an on behalf of manner should provide an indication of this in it
terms and conditions allowing allowing the user of device the option
of connecting or not. Where the network may use on behalf of
location acqusition for non-essential services, the user of an end-
device MUST have the option of restricting the divulging of location
to essential services only. How this restriction occurs is outside
the scope of this specification.
The LIS MUST not accept on behalf of location requests from, or
divulge location information to, any third-party that it cannot
authenticate or authorize. In most cases on behalf of requests
should be restricted to essential services legislated by the local
juridiction.
Winterbottom, et al. Expires January 15, 2009 [Page 11]
Internet-Draft HELD-ID-EXT July 2008
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 January 15, 2009 [Page 12]
Internet-Draft HELD-ID-EXT July 2008
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.
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 [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.
o '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 [RFC2434] this registry operates under
Winterbottom, et al. Expires January 15, 2009 [Page 13]
Internet-Draft HELD-ID-EXT July 2008
the "Expert Review" rule.
The following identifier types are registered as part of this memo:
o 'aor' The SIP address of record as defined [RFC3261]. Applies to
'sip:', 'sips:', 'pres:'
o 'gruu' The Globally Routable User Agent URI (GRUU) as defined in
[I-D.ietf-sip-gruu]. Applies to 'sip:', 'sips:'
Winterbottom, et al. Expires January 15, 2009 [Page 14]
Internet-Draft HELD-ID-EXT July 2008
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 January 15, 2009 [Page 15]
Internet-Draft HELD-ID-EXT July 2008
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-08 (work in
progress), July 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.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[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.
[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.
[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-05 (work in progress),
Winterbottom, et al. Expires January 15, 2009 [Page 16]
Internet-Draft HELD-ID-EXT July 2008
July 2008.
[I-D.thomson-geopriv-held-measurements]
Thomson, M. and J. Winterbottom, "Using Device-provided
Location-Related Measurements in HELD",
draft-thomson-geopriv-held-measurements-02 (work in
progress), May 2008.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[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.
[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.
[RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration
Protocol (DHCP) Leasequery", RFC 4388, February 2006.
Winterbottom, et al. Expires January 15, 2009 [Page 17]
Internet-Draft HELD-ID-EXT July 2008
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
Winterbottom, et al. Expires January 15, 2009 [Page 18]
Internet-Draft HELD-ID-EXT July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Winterbottom, et al. Expires January 15, 2009 [Page 19]