GEOPRIV WG M. Barnes, Ed.
Internet-Draft Nortel
Intended status: Standards Track
Expires: October 19, 2008
April 17, 2008
HTTP Enabled Location Delivery (HELD)
draft-ietf-geopriv-http-location-delivery-07.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 October 19, 2008.
Abstract
A Layer 7 Location Configuration Protocol (L7 LCP) is described that
is used for retrieving location information from a server within an
access network. The protocol includes options for retrieving
location information in two forms: by value and by reference. The
protocol is an extensible application-layer protocol that is
independent of session-layer. This document describes the use of
Hypertext Transfer Protocol (HTTP) as a transport for the protocol.
Barnes, et al. Expires October 19, 2008 [Page 1]
Internet-Draft HELD April 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4
3. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Location by Value . . . . . . . . . . . . . . . . . . . . 7
4.2. Location by Reference . . . . . . . . . . . . . . . . . . 7
4.3. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 7
4.3.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 8
4.3.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 8
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9
5.1. Delivery Protocol . . . . . . . . . . . . . . . . . . . . 9
5.2. Location Request . . . . . . . . . . . . . . . . . . . . . 10
5.3. Location Response . . . . . . . . . . . . . . . . . . . . 10
5.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 10
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10
6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11
6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12
6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 12
6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 13
6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 13
6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 14
6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 14
6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 14
6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 14
7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. HELDS: URI Definition . . . . . . . . . . . . . . . . . . . . 18
9. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10.1. Assuring that the proper LIS has been contacted . . . . . 21
10.2. Protecting responses from modification . . . . . . . . . . 21
10.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 21
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. HTTP Example Messages . . . . . . . . . . . . . . . . . . 23
11.2. Simple Location Request Example . . . . . . . . . . . . . 25
11.3. Location Request Example for Multiple Location Types . . . 26
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
12.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 27
12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 28
12.3. MIME Media Type Registration for 'application/held+xml' . 28
12.4. Error code Registry . . . . . . . . . . . . . . . . . . . 29
12.5. URI Registration . . . . . . . . . . . . . . . . . . . . . 30
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
15. Changes since last Version . . . . . . . . . . . . . . . . . . 31
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Barnes, et al. Expires October 19, 2008 [Page 2]
Internet-Draft HELD April 2008
16.1. Normative References . . . . . . . . . . . . . . . . . . . 35
16.2. Informative References . . . . . . . . . . . . . . . . . . 36
Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 37
A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 38
A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 38
A.3. L7-3: ASP and Access Network Provider Relationship . . . . 38
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 39
A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 39
A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 40
A.7. L7-7: Network Access Authentication . . . . . . . . . . . 40
A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 40
A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 40
A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . . . 43
Barnes, et al. Expires October 19, 2008 [Page 3]
Internet-Draft HELD April 2008
1. Introduction
The location of a Device is information that is useful for a number
of applications. The L7 Location Configuration Protocol (LCP)
problem statement and requirements document
[I-D.ietf-geopriv-l7-lcp-ps] provides some scenarios in which the
Device might rely on its access network to provide location
information. The LIS service applies to access networks employing
both wired technology (e.g. DSL, Cable) and wireless technology
(e.g. WiMAX) with varying degrees of Device mobility. This document
describes a protocol that can be used to acquire Location Information
(LI) from a Location Information Server (LIS) within an access
network.
This specification identifies two types of location information that
may be retrieved from the LIS. Location may be retrieved from the
LIS by value, that is, the Device may acquire a literal location
object describing the location of the Device. The Device may also
request that the LIS provide a location reference in the form of a
location URI or set of location URIs, allowing the Device to
distribute its LI by reference. Both of these methods can be
provided concurrently from the same LIS to accommodate application
requirements for different types of location information.
This specification defines an extensible XML-based protocol that
enables the retrieval of LI from a LIS by a Device. This protocol
can be bound to any session-layer protocol, particularly those
capable of MIME transport. This document describes the use of
Hypertext Transfer Protocol (HTTP) as a transport for the protocol.
2. Conventions & Terminology
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].
This document uses the terms (and their acronym forms) Access
Provider (AP), Location Information (LI), Location Object (LO),
Device, Target, Location Generator (LG), Location Recipient (LR),
Rule Maker (RM) and Rule Holder (RH) as defined in RFC 3693, GEOPRIV
Requirements [RFC3693] . The terms Location Information Server
(LIS), Access Network, Access Provider (AP) and Access Network
Provider are used in the same context as defined in the L7 LCP
Problem statement and Requirements document
[I-D.ietf-geopriv-l7-lcp-ps]. The usage of the terms, Civic
Location/Address and Geodetic Location follows the usage in many of
the referenced documents.
Barnes, et al. Expires October 19, 2008 [Page 4]
Internet-Draft HELD April 2008
In describing the protocol, the terms "attribute" and "element" are
used according to their context in XML. The term "parameter" is used
in a more general protocol context and can refer to either an XML
"attribute" or "element".
3. Overview and Scope
This document describes an interface between a Device and a Location
Information Server (LIS). This document assumes that the LIS is
present within the same administrative domain as the Device (e.g.,
the access network). An Access Provider (AP) operates the LIS so
that Devices (and Targets) can retrieve their LI. The LIS exists
because not all Devices are capable of determining LI, and because,
even if a device is able to determine its own LI, it may be more
efficient with assistance. This document does not specify how LI is
determined.
This document is based on the attribution of the LI to a Device and
not specifically a person (end user) or Target, based on the premise
that location determination technologies are generally designed to
locate a device and not a person. It is expected that, for most
applications, LI for the device can be used as an adequate substitute
for the end user's LI. Since revealing the location of the device
almost invariably reveals some information about the location of the
user of the device, the same level of privacy protection demanded by
a user is required for the device. This approach may require either
some additional assurances about the link between device and target,
or an acceptance of the limitation that unless the device requires
active user authentication, there is no guarantee that any particular
individual is using the device at that instant.
Barnes, et al. Expires October 19, 2008 [Page 5]
Internet-Draft HELD April 2008
The following diagram shows the logical configuration of some of the
functional elements identified in [RFC3693] and the LIS defined in
[I-D.ietf-geopriv-l7-lcp-ps] and where this protocol applies, with
the Rule Maker and Target represented by the role of the Device.
Note that only the interfaces relevant to the Device are identified
in the diagram.
+---------------------------------------------+
| Access Network Provider |
| |
| +--------------------------------------+ |
| | Location Information Server | |
| | | |
| | | |
| | | |
| | | |
| +------|-------------------------------+ |
+----------|----------------------------------+
|
|
HELD
|
Rule Maker - _ +-----------+ +-----------+
o - - | Device | | Location |
This document (RFC xxxx) defines HELD messages.
Barnes, et al. Expires October 19, 2008 [Page 16]
Internet-Draft HELD April 2008
Barnes, et al. Expires October 19, 2008 [Page 17]
Internet-Draft HELD April 2008
8. HELDS: URI Definition
This section defines the schema for a helds: URI. This URI schema is
one possible URI scheme for the "locationURI" element, described in
Section 6.5.1, in a HELD "locationResponse " message. In this case,
the helds: URI indicates to the Device where to obtain the actual
location information for a Target. In addition, the helds: URI can
be the result of the LIS discovery process
[I-D.ietf-geopriv-lis-discovery] and indicates to the Device the LIS
from which LI should be requested.
The helds: URI is defined using a subset of the URI schema specified
in Appendix A. of RFC3986 [RFC3986] and the associated URI
Guidelines [RFC4395] per the following ABNF syntax:
HELD-URI = "helds://" host [ ":" port ] [ path-absolute ] [ "?" query ]
Barnes, et al. Expires October 19, 2008 [Page 18]
Internet-Draft HELD April 2008
The following summarizes the primary elements comprising the HELD-
URI:
host: As defined in RFC3986 [RFC3986]
port: As defined in RFC3986 [RFC3986]. There is no unique port
associated with location URIs.
path-absolute As defined in RFC3986 [RFC3986].
query: As defined in RFC3986 [RFC3986]. This allows for additional
information associated with the URIs such as a unique anonymous
identifier for the Device associated with the target location.
The helds: URI is not intended to be human-readable text, therefore
it is encoded entirely in US-ASCII. The following are examples of
helds: URIs:
helds://ls.example.com:49152/thisLocation?token=xyz987
helds://ls.example.com:5432/THISLOCATION?foobar=abc123
helds://ls.example.com:5432/THISlocation?foobar=ABC123
helds://ls.example.com:9876/civic
Other than the "host" portion, URIs are case sensitive and exact
equivalency is required for HELD-URI comparisons. For example, in
the above examples, although similar in information, the 2nd and 3rd
URIs are not considered equivalent.
In the case where the helds: URI is contained in a "locationURI"
element in a HELD locationResponse message, it is important to note
that the URI is only valid for the length of time indicated by the
"expires" attribute.
9. HTTP Binding
This section describes the use of HTTP [RFC2616] as a transport
mechanism for this protocol, which all conforming implementations
MUST support.
The request is carried in the body of an HTTP POST request. The MIME
type of both request and response bodies should be
"application/held+xml". This should be reflected in the HTTP
Content-Type and Accept header fields.
The LIS populates the HTTP headers so that they are consistent with
the contents of the message. In particular, the cache control header
SHOULD be set to disable the HTTP caching of any PIDF-LO document or
Location URIs. Otherwise, there is the risk of stale locations
Barnes, et al. Expires October 19, 2008 [Page 19]
Internet-Draft HELD April 2008
and/or the unauthorized disclosure of the LI. This also allows the
LIS to control any caching with the "expires" parameter. The HTTP
status code MUST indicate a 2xx series response for all HELD
locationResponse and error messages.
The use of HTTP also includes a default behaviour, which is triggered
by a GET request, or a POST with no request body. If either of these
queries are received, the LIS MUST attempt to provide either a
PIDF-LO document or a Location URI, as if the request was a location
request.
The implementation of HTTP as a transport mechanism MUST implement
TLS as described in [RFC2818]. TLS provides message integrity and
privacy between Device and LIS. The LIS MUST use the server
authentication method described in [RFC2818]; the Device MUST fail a
request if server authentication fails, except in the event of an
emergency.
10. Security Considerations
HELD is a location acquisition protocol whereby the a client requests
its location from a LIS. Specific requirements and security
considerations for location acquisition protocols are provided in
[I-D.ietf-geopriv-l7-lcp-ps]. An in-depth discussion of the security
considerations applicable to the use of Location URIs and by
reference provision of LI is included in
[I-D.ietf-geopriv-lbyr-requirements].
By using the HELD protocol, the client and the LIS expose themselves
to two types of risk:
Accuracy: Client receives incorrect location information
Privacy: An unauthorized entity receives location information
The provision of an accurate and privacy/confidentiality protected
location to the requestor depends on the success of five steps:
1. The client must determine the proper LIS.
2. The client must connect to the proper LIS.
3. The LIS must be able to identify the device by its identifier
(IP Address).
4. The LIS must be able to return the desired location.
5. HELD messages must be transmitted unmodified between the LIS
and the client.
Of these, only the second, third and the fifth are within the scope
of this document. The first step is based on either manual
Barnes, et al. Expires October 19, 2008 [Page 20]
Internet-Draft HELD April 2008
configuration or on the LIS discovery defined in
[I-D.ietf-geopriv-lis-discovery], in which appropriate security
considerations are already discussed. The fourth step is dependent
on the specific positioning capabilities of the LIS, and is thus
outside the scope of this document.
10.1. Assuring that the proper LIS has been contacted
This document assumes that the LIS to be contacted is identified
either by an IP address or a domain name, as is the case for a LIS
discovered as described in LIS Discovery
[I-D.ietf-geopriv-lis-discovery]. When the HELD transaction is
conducted using TLS [RFC4346], the LIS can authenticate its identity,
either as a domain name or as an IP address, to the client by
presenting a certificate containing that identifier as a
subjectAltName (i.e., as an iPAddress or dNSName, respectively). In
the case of the HTTP binding described above, this is exactly the
authentication described by TLS [RFC2818]. Any binding of HELD MUST
be capable of being transacted over TLS so that the client can
request the above authentication, and a LIS implementation for a
binding MUST include this feature. Note that in order for the
presented certificate to be valid at the client, the client must be
able to validate the certificate. In particular, the validation path
of the certificate must end in one of the client's trust anchors,
even if that trust anchor is the LIS certificate itself.
10.2. Protecting responses from modification
In order to prevent that response from being modified en route,
messages must be transmitted over an integrity-protected channel.
When the transaction is being conducted over TLS (a required feature
per Section 10.1), the channel will be integrity protected by
appropriate ciphersuites. When TLS is not used, this protection will
vary depending on the binding; in most cases, without protection from
TLS, the response will not be protected from modification en route.
10.3. Privacy and Confidentiality
Location information returned by the LIS must be protected from
access by unauthorized parties, whether those parties request the
location from the LIS or intercept it en route. As in section
Section 10.2, transactions conducted over TLS with appropriate
ciphersuites are protected from access by unauthorized parties en
route. Conversely, in most cases, when not conducted over TLS, the
response will be accessible while en route from the LIS to the
requestor.
Because HELD is an LCP and identifies clients and targets by IP
Barnes, et al. Expires October 19, 2008 [Page 21]
Internet-Draft HELD April 2008
addresses, a requestor is authorized to access location for an IP
address only if it is the holder of that IP address. The LIS MUST
verify that the client is the target of the returned location, i.e.,
the LIS MUST NOT provide location to other entities than the target.
Note that this is a necessary, but not sufficient criterion for
authorization. A LIS MAY deny requests according to any local
policy.
A prerequisite for meeting this requirement is that the LIS must have
some assurance of the identity of the client. Since the target of
the returned location is identified by an IP address, simply sending
the response to this IP address will provide sufficient assurance in
many cases. This is the default mechanism in HELD for assuring that
location is given only to authorized clients; LIS implementations
MUST support a mode of operation in which this is the only client
authentication.
Using IP return routability as an authenticator means that location
information is vulnerable to exposure through IP address spoofing
attacks. A temporary spoofing of IP address could mean that a device
could request a Location Object or Location URI that would result in
another Device's location. In addition, in cases where a Device
drops off the network for various reasons, the re-use of the Device's
IP address could result in another Device receiving the original
Device's location rather than its own location. One or more of the
following approaches are RECOMMENDED to limit these exposures:
o Location URIs SHOULD have a limited lifetime, as reflected by the
value for the expires element in Section 6.5.2.
o The network SHOULD have mechanisms that protect against IP address
spoofing, such as those defined in [RFC3704].
o The LIS and network SHOULD be configured so that the LIS is made
aware of Device movement within the network and addressing
changes. If the LIS detects a change in the network that results
in it no longer being able to determine the location of the
Device, then all location URIs for that Device SHOULD be
invalidated.
The above measures are dependent on network configuration, which
SHOULD be considered. For instance, in a fixed internet access,
providers may be able to restrict the allocation of IP addresses to a
single physical line, ensuring that spoofing is not possible; in such
an environment, other measures may not be necessary.
When there are further mechanisms available to authenticate ownership
of the IP address, the LIS SHOULD use them to authenticate that the
client is the owner of the target IP address. For example, in a TLS
transaction, the client could present a certificate with a public key
Barnes, et al. Expires October 19, 2008 [Page 22]
Internet-Draft HELD April 2008
bound to an IPv6 Cryptographically Generated Address, and the LIS
could verify this binding.
11. Examples
The following sections provide basic HTTP examples, a simple location
request example and a location request for multiple location types
example along with the relevant location responses. To focus on
important portions of messages, the examples in Section 11.2 and
Section 11.3 do not show HTTP headers or the XML prologue. In
addition, sections of XML not relevant to the example are replaced
with comments.
11.1. HTTP Example Messages
The examples in this section show a complete HTTP message that
includes the HELD request or response document.
This example shows the most basic request for a LO. This uses the
GET feature described by the HTTP binding. This example assumes that
the LIS service exists at the URL "https://lis.example.com/location".
GET /location HTTP/1.1
Host: lis.example.com
Accept:application/held+xml,
application/xml;q=0.8,
text/xml;q=0.7
Accept-Charset: UTF-8,*
The GET request is exactly identical to a minimal POST request that
includes an empty "locationRequest" element.
POST /location HTTP/1.1
Host: lis.example.com
Accept: application/held+xml,
application/xml;q=0.8,
text/xml;q=0.7
Accept-Charset: UTF-8,*
Content-Type: application/held+xml
Content-Length: 87
Barnes, et al. Expires October 19, 2008 [Page 23]
Internet-Draft HELD April 2008
Since neither of these requests includes a "locationType" element,
the successful response to either of these requests may contain any
type of location. The following shows a response containing a
minimal PIDF-LO.
HTTP/1.x 200 OK
Server: Example LIS
Date: Tue, 10 Jan 2006 03:42:29 GMT
Expires: Tue, 10 Jan 2006 03:42:29 GMT
Cache-control: private
Content-Type: application/held+xml
Content-Length: 594
-34.407 150.88001
2006-01-11T03:42:28+00:00
Wiremap
2006-01-10T03:42:28+00:00
Barnes, et al. Expires October 19, 2008 [Page 24]
Internet-Draft HELD April 2008
The error response to either of these requests is an error document.
The following response shows an example error response.
HTTP/1.x 200 OK
Server: Example LIS
Expires: Tue, 10 Jan 2006 03:49:20 GMT
Cache-control: private
Content-Type: application/held+xml
Content-Length: 135
11.2. Simple Location Request Example
The location request shown below doesn't specify any location types
or response time.
The example response to this location request contains a list of
Location URIs.
helds://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
Barnes, et al. Expires October 19, 2008 [Page 25]
Internet-Draft HELD April 2008
An error response to this location request is shown below:
11.3. Location Request Example for Multiple Location Types
The following Location Request message includes a request for
geodetic, civic and any Location URIs.
geodetic
civic
locationURI
The corresponding Location Response message includes the requested
location information, including two location URIs.
helds://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
-34.407242 150.882518
30
Barnes, et al. Expires October 19, 2008 [Page 26]
Internet-Draft HELD April 2008
AU
NSW
Wollongong
Gwynneville
Northfield Avenue
University of Wollongong
2
Andrew Corporation
2500
39
WS-183
U40
false
2007-05-25T12:35:02+10:00
Wiremap
2007-05-24T12:35:02+10:00
12. IANA Considerations
This document requires several IANA registrations detailed in the
following sections.
12.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:held", per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:held
Barnes, et al. Expires October 19, 2008 [Page 27]
Internet-Draft HELD April 2008
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com).
XML:
BEGIN
HELD Messages
Namespace for HELD Messages
urn:ietf:params:xml:ns:geopriv:held
[NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.]
See RFCXXXX
END
12.2. XML Schema Registration
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:geopriv:held
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Mary Barnes (mary.barnes@nortel.com).
Schema: The XML for this schema can be found as the entirety of
Section 7 of this document.
12.3. MIME Media Type Registration for 'application/held+xml'
This section registers the "application/held+xml" MIME type.
To: ietf-types@iana.org
Subject: Registration of MIME media type application/held+xml
MIME media type name: application
MIME subtype name: held+xml
Required parameters: (none)
Optional parameters: charset
Indicates the character encoding of enclosed XML. Default is
UTF-8.
Barnes, et al. Expires October 19, 2008 [Page 28]
Internet-Draft HELD April 2008
Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See RFC
3023 [RFC3023], section 3.2.
Security considerations: This content type is designed to carry
protocol data related to the location of an entity, which could
include information that is considered private. Appropriate
precautions should be taken to limit disclosure of this
information.
Interoperability considerations: This content type provides a basis
for a protocol
Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number for this specification.]
Applications which use this media type: Location information
providers and consumers.
Additional Information: Magic Number(s): (none)
File extension(s): .xml
Macintosh File Type Code(s): (none)
Person & email address to contact for further information: Mary
Barnes
Intended usage: LIMITED USE
Author/Change controller: The IETF
Other information: This media type is a specialization of
application/xml [RFC3023], and many of the considerations
described there also apply to application/held+xml.
12.4. Error code Registry
This document requests that the IANA create a new registry for the
HELD protocol including an initial registry for error codes. The
error codes are included in HELD error messages as described in
Section 6.3 and defined in the schema in the 'codeType' token in the
XML schema in (Section 7)
The following summarizes the requested registry:
Related Registry: Geopriv HELD Registries, Error codes for HELD
Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.]
Registration/Assignment Procedures: Following the policies outlined
in [I-D.narten-iana-considerations-rfc2434bis], the IANA policy
for assigning new values for the Error codes for HELD shall be
Specification Required: values and their meanings must be
documented in an RFC or in some other permanent and readily
available reference, in sufficient detail that interoperability
between independent implementations is possible.
Barnes, et al. Expires October 19, 2008 [Page 29]
Internet-Draft HELD April 2008
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Mary Barnes (mary.barnes@nortel.com).
This section pre-registers the following seven initial error codes as
described above in Section 6.3:
requestError: This code indicates that the request was badly formed
in some fashion.
xmlError: This code indicates that the XML content of the request
was either badly formed or invalid.
generalLisError: This code indicates that an unspecified error
occurred at the LIS.
locationUnknown: This code indicates that the LIS could not
determine the location of the Device.
unsupportedMessage: This code indicates that the request was not
supported or understood by the LIS.
timeout: This code indicates that the LIS could not satisfy the
request within the time specified in the "responseTime" parameter.
cannotProvideLiType: This code indicates that the LIS was unable to
provide LI of the type or types requested. This code is used when
the "exact" attribute on the "locationType" parameter is set to
"true".
12.5. URI Registration
The following summarizes the information necessary to register the
helds: URI. [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the
RFC number for this specification in the following list.]
URI Scheme Name: helds
Status: permanent
URI Scheme syntax: See section
URI Scheme Semantics: The helds: URI is intended to be used as a
reference to a location object or a location information server.
Further detail is provided in Section 8 of RFC XXXX.
Encoding Considerations: The HELDS: URI is not intended to be human-
readable text, therefore they are encoded entirely in US-ASCII.
Applications/protocols that use this URI scheme: The HELD protocol
described in RFC XXXX, the GEOPRIV Location De-reference Protocol
[I-D.winterbottom-geopriv-deref-protocol] and GEOPRIV Location
Information Server Discovery [I-D.ietf-geopriv-lis-discovery].
Interoperability considerations: This URI may be used as a parameter
for the HELD protocol in the locationResponse message. This URI
is also used as an input parameter for the GEOPRIV Location De-
reference Protocol [I-D.winterbottom-geopriv-deref-protocol].
This URI may also be a result of the GEOPRIV Location Information
Server Discovery [I-D.ietf-geopriv-lis-discovery] and thus used as
the target for the HELD protocol request messages. Refer to
Barnes, et al. Expires October 19, 2008 [Page 30]
Internet-Draft HELD April 2008
Section 8 in RFC XXXX for further detail and a particular example
on the lack of permanence of a specific HELDS: URI and thus the
importance of using these URIs only within the specific contexts
outlined in the references.
Security considerations: Section 10 in RFC XXXX addresses the
necessary security associated with the transport of location
information between a Device and the LIS to ensure the privacy and
integrity of the helds: URI. Section 6.5.1 in RFC XXXX also
recommends that the URI be allocated such that it does not reveal
any detail at all about the content of the PIDF-LO that it may
indirectly reference.
Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary
Barnes (mary.barnes@nortel.com).
Author/Change controller: This scheme is registered under the IETF
tree. As such, IETF maintains change control.
References: RFC XXXX, GEOPRIV Location De-reference Protocol
[I-D.winterbottom-geopriv-deref-protocol], GEOPRIV Location
Information Server Discovery [I-D.ietf-geopriv-lis-discovery]
13. Contributors
James Winterbottom, Martin Thomson and Barbara Stark are the authors
of the original document, from which this WG document was derived.
Their contact information is included in the Author's address
section. In addition, they also contributed to the WG document,
including the XML schema.
14. Acknowledgements
The author/contributors would like to thank the participants in the
GEOPRIV WG and the following people for their constructive input and
feedback on this document (in alphabetical order): Nadine Abbott,
Eric Arolick, Richard Barnes (in particular the security section),
Peter Blatherwick, Guy Caron, Martin Dawson, Lisa Dusseault, Jerome
Grenier, Ted Hardie, Cullen Jennings, Neil Justusson, Tat Lam, Marc
Linsner, Patti McCalmont, Roger Marshall, Perry Prozeniuk, Carl Reed,
Brian Rosen, John Schnizlein, Shida Schubert, Henning Schulzrinne, Ed
Shrum, Doug Stuard, Hannes Tschofenig and Karl Heinz Wolf.
15. Changes since last Version
NOTE TO THE RFC-Editor: Please remove this section prior to
publication as an RFC.
Changes from WG 06 to 07 (PROTO review comments):
Barnes, et al. Expires October 19, 2008 [Page 31]
Internet-Draft HELD April 2008
1) Fix nits: remove unused references, move requirements to
Informational References section, fix long line in ABNF, fix ABNF
(quotes around '?'), add schemaLocation to import namespace in XML
schema.
2) Remove text in Device and VPN section referencing DHCP and LLDP-
MED when a VPN device serves as a LIS, per Issue 1 resolution at
IETF-71. (Editorial oversight in producing version 06).
Changes from WG 05 to 06 (2nd WGLC comments):
1) Updated security section based on WG feedback, including
condensing section 10.1.1 (Assuring the proper LIS has been
contacted), restructuring sections by flattening, adding an
additional step to the list that had been in the Accuracy section and
removing summary section.
2) Changed URI schema to "helds" to address concerns over referential
integrity and for consistency with mandate of TLS for HELD.
3) Editorial clarifications including fixing examples to match HELD
URI definition (e.g., adding port, adding randomness to URI examples,
etc.)
4) Updated references removing unused references and moving
requirements docs to Informational Reference section to avoid
downrefs.
Changes from WG 04 to 05 (WGLC comments):
1) Totally replaced the security section with the details provided by
Richard Barnes so that we don't need a reference to the location
security document.
2) Fixed error codes in schema to allow extensibility. Change the
IANA registration to be "specification required".
3) Cleaned up the HELD: URI description, per comments from Martin and
James and partially addressing HELD-04 Issue 1. Put the definition
in a separate section and clarified the applicability (to also
include being a results of the discovery process) and fixed examples.
4) Updated the LocationURI section to be more accurate, address
HELD-04 Issue 3, and include the reference to the new HELD:URI
section. Also, fixed an error in the doc in that the top level parm
in the locationResponse is actually locationUriSet, which contains
any number of locationURI elements and the "expires" parameter. So,
Table 1 was also updated and a new section for the LocationURISet was
Barnes, et al. Expires October 19, 2008 [Page 32]
Internet-Draft HELD April 2008
added that includes the subsections for the "locationURI" and
"expires". And, then clarified that "expires" applies to
"locationURISet" and not per "locationURI".
5) Editorial nits: pointed out offline by Richard (e.g., by-value ->
by value, by-reference -> by reference, etc.) and onlist by James and
Martin. Please refer to the diff for a complete view of editorial
changes.
6) Added text in HTTP binding section to disable HTTP caching
(HELD-04 Issue 5 on the list).
Changes from WG 03 to 04:
1) Terminology: clarified in terminology section that "attribute" and
"element" are used in the strict XML sense and "parameter" is used as
a general protocol term Replaced term "HTTP delivery" with "HTTP
transport". Still have two terms "HTTP transport" and "HTTP
binding", but those are consistent with general uses of HTTP.
2) Editorial changes and clarifications: per Roger Marshall's and
Eric Arolick's comments and subsequent WG mailing list discussion.
3) Changed normative language for describing expected and recommended
LIS behaviors to be non-normative recommendations in cases where the
protocol parameters were not the target of the discussion (e.g., we
can't prescribe to the LIS how it determines location or what it
defines to be an "accurate" location).
4) Clarified responseTime attribute (section 6.1). Changed type from
"decimal" to "nonNegativeInteger" in XML schema (section 7)
5) Updated Table 1 in section 6 to only include top-level parameters
and fixed some errors in that table (i.e., code for locationResponse)
and adding PIDF-LO to the table. Added a detailed section describing
PIDF-LO (section 6.6), moving some of the normative text in the
Protocol Overview to this section.
6) Added schema and description for locationURI to section 6.5.
Added IANA registration for HELD: URI schema.
7) Added IANA registry for error codes.
Changes from WG 02 to 03:
1) Added text to address concern over use of IP address as device
identifier, per long email thread - changes to section 3 (overview)
and section 4 (protocol overview).
Barnes, et al. Expires October 19, 2008 [Page 33]
Internet-Draft HELD April 2008
2) Removed WSDL (section 8 updated, section 8.1 and 10.4 removed)
3) Added extensibility to baseRequestType in the schema (an oversight
from previous edits), along with fixing some other nits in schema
(section 7)
4) Moved discussion of Location URI from section 5.3 (Location
Response) to where it rightly belonged in Section 6.5 (Location URI
Parameter).
5) Clarified text for "expires" parameter (6.5.1) - it's an optional
parm, but required for LocationURIs
6) Clarified responseTime parameter: when missing, then the LCS
provides most precise LI, with the time required being implementation
specific.
7) Clarified that the MUST use in section 8 (HTTP binding) is a MUST
implement.
8) Updated references (removed unused/added new).
Changes from WG 01 to 02:
1) Updated Terminology to be consistent with WG agreements and other
documents (e.g., LCS -> LIS and removed duplicate terms). In the
end, there are no new terms defined in this document.
2) Modified definition of responseTime to reflect WG consensus.
3) Removed jurisdictionalCivic and postalCivic locationTypes (leaving
just "civic").
4) Clarified text that locationType is optional. Fixed table 1 and
text in section 5.2 (locationRequest description). Text in section
6.2 (description of locationType element) already defined the default
to be "any".
5) Simplified error responses. Separated the definition of error
response type from the locationResponse type thus no need for
defining an error code of "success". This simplifies the schema and
processing.
6) Updated schema/examples for the above.
7) Updated Appendix A based on updates to requirements document,
specifically changes to A.1, A.3 and adding A.10.
Barnes, et al. Expires October 19, 2008 [Page 34]
Internet-Draft HELD April 2008
8) Miscellaneous editorial clarifications.
Changes from WG 00 to 01:
1) heldResponse renamed to locationResponse.
2) Changed namespace references for the PIDF-LO geoShape in the
schema to match the agreed GML PIDF-LO Geometry Shape Application
Schema.
3) Removed "options" element - leaving optionality/extensibility to
XML mechanisms.
4) Changed error codes to be enumerations and not redefinitions of
HTTP response codes.
5) Updated schema/examples for the above and removed some remnants of
the context element.
6) Clarified the definition of "Location Information (LI)" to include
a reference to the location (to match the XML schema and provide
consistency of usage throughout the document). Added an additional
statement in section 7.2 (locationType) to clarify that LCS MAY also
return a Location URI.
7) Modifed the definition of "Location Configuration Server (LCS)" to
be consistent with the current definiton in the requirements
document.
8) Updated Location Response (section 6.3) to remove reference to
context and discuss the used of a local identifier or unlinked
pseudonym in providing privacy/security.
9) Clarified that the source IP address in the request is used as the
identifier for the target/device for the HELD protocol as defined in
this document.
10) Miscellaneous editorial clarifications.
16. References
16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
Barnes, et al. Expires October 19, 2008 [Page 35]
Internet-Draft HELD April 2008
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[I-D.ietf-geopriv-pdif-lo-profile]
Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations and
Recommendations", draft-ietf-geopriv-pdif-lo-profile-11
(work in progress), February 2008.
[W3C.REC-xmlschema-1-20041028]
Mendelsohn, N., Thompson, H., Beech, D., and M. Maloney,
"XML Schema Part 1: Structures Second Edition", World Wide
Web Consortium Recommendation REC-xmlschema-1-20041028,
October 2004,
.
[W3C.REC-xmlschema-2-20041028]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium
Recommendation REC-xmlschema-2-20041028, October 2004,
.
[I-D.ietf-geopriv-lis-discovery]
Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)",
draft-ietf-geopriv-lis-discovery-00 (work in progress),
December 2007.
16.2. Informative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
Barnes, et al. Expires October 19, 2008 [Page 36]
Internet-Draft HELD April 2008
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 115,
RFC 4395, February 2006.
[I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs",
draft-narten-iana-considerations-rfc2434bis-09 (work in
progress), March 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-07 (work in
progress), March 2008.
[I-D.ietf-geopriv-lbyr-requirements]
Marshall, R., "Requirements for a Location-by-Reference
Mechanism", draft-ietf-geopriv-lbyr-requirements-02 (work
in progress), February 2008.
[I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol",
draft-ietf-sip-location-conveyance-10 (work in progress),
February 2008.
[I-D.winterbottom-geopriv-deref-protocol]
Winterbottom, J., Tschofenig, H., Schulzrinne, H.,
Thomson, M., and M. Dawson, "An HTTPS Location
Dereferencing Protocol Using HELD",
draft-winterbottom-geopriv-deref-protocol-00 (work in
progress), November 2007.
Appendix A. HELD Compliance to IETF LCP requirements
This appendix describes HELD's compliance to the requirements
specified in the [I-D.ietf-geopriv-l7-lcp-ps].
Barnes, et al. Expires October 19, 2008 [Page 37]
Internet-Draft HELD April 2008
A.1. L7-1: Identifier Choice
"The L7 LCP MUST be able to carry different identifiers or MUST
define an identifier that is mandatory to implement. Regarding the
latter aspect, such an identifier is only appropriate if it is from
the same realm as the one for which the location information service
maintains identifier to location mapping."
COMPLY
HELD uses the IP address of the location request message as the
primary source of identity for the requesting device or target. This
identity can be used with other contextual network information to
provide a physical location for the Target for many network
deployments. There may be network deployments where an IP address
alone is insufficient to identify a Target in a network. However,
any necessary identity extensions for these networks is beyond the
scope of this document.
A.2. L7-2: Mobility Support
"The GEOPRIV Layer 7 Location Configuration Protocol MUST support a
broad range of mobility from devices that can only move between
reboots, to devices that can change attachment points with the impact
that their IP address is changed, to devices that do not change their
IP address while roaming, to devices that continuously move by being
attached to the same network attachment point."
COMPLY
Mobility support is inherently a characteristic of the access network
technology and HELD is designed to be access network agnostic.
Consequently HELD complies with this requirement. In addition HELD
provides specific support for mobile environments by providing an
optional responseTime attribute in location request messages.
Wireless networks often have several different mechanisms at their
disposal for position determination (e.g. Assisted GPS versus
location based on serving base station identity), each providing
different degrees of accuracy and taking different amounts of time to
yield a result. The responseTime parameter provides the LIS with a
criterion which it can use to select a location determination
technique.
A.3. L7-3: ASP and Access Network Provider Relationship
"The design of the L7 LCP MUST NOT assume a business or trust
relationship between the Application Service Provider (ASP) and the
Access Network Provider. Requirements for resolving a reference to
Barnes, et al. Expires October 19, 2008 [Page 38]
Internet-Draft HELD April 2008
location information are not discussed in this document."
COMPLY
HELD describes a location acquisition protocol and has no
dependencies on the business or trust relationship between the ASP
and the Access Network Provider. Location acquisition using HELD is
subject to the restrictions described in Section 10.
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship
"The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST assume that there is a trust and business relationship between
the L2 and the L3 provider. The L3 provider operates the LIS and
needs to obtain location information from the L2 provider since this
one is closest to the end host. If the L2 and L3 provider for the
same host are different entities, they cooperate for the purposes
needed to determine end system locations."
COMPLY
HELD was specifically designed with this model in mind and readily
allows itself to chaining requests between operators without a change
in protocol being required. HELD is a webservices protocol it can be
bound to transports other than HTTP. Using o offers the option of
high request throughput over a dedicated connection between an L3
provider and an L2 provider without incurring the serial restriction
imposed by HTTP. This is less easy to do with protocols that do not
decouple themselves from the transport.
A.5. L7-5: Legacy Device Considerations
"The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST consider legacy residential NAT devices and NTEs in an DSL
environment that cannot be upgraded to support additional protocols,
for example to pass additional information through DHCP."
COMPLY
HELD is an application protocol and operates on top of IP. A HELD
request from a host behind a residential NAT will traverse the NAT
acquiring the external address of the home router. The location
provided to the host therefore will be the address of the home router
in this circumstance. No changes are required to the home router in
order to support this function, HELD was designed specifically to
address this deployment scenario.
Barnes, et al. Expires October 19, 2008 [Page 39]
Internet-Draft HELD April 2008
A.6. L7-6: VPN Awareness
"The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST assume that at least one end of a VPN is aware of the VPN
functionality. In an enterprise scenario, the enterprise side will
provide the LIS used by the client and can thereby detect whether the
LIS request was initiated through a VPN tunnel."
COMPLY
HELD does not preclude a LIS on the far end of a VPN tunnel being
aware that the client request is occurring over that tunnel. It also
does not preclude a client device from accessing a LIS serving the
local physical network and subsequently using the location
information with an application that is accessed over a VPN tunnel.
A.7. L7-7: Network Access Authentication
"The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST NOT assume prior network access authentication."
COMPLY
HELD makes no assumptions about prior network access authentication.
HELD strongly recommends the use of TLS with server-side certificates
for communication between the end-point and the LIS. There is no
requirement for the end-point to authenticate with the LIS.
A.8. L7-8: Network Topology Unawareness
"The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST NOT assume end systems being aware of the access network
topology. End systems are, however, able to determine their public
IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP."
COMPLY
HELD makes no assumption about the network topology. HELD doesn't
require that the device know its external IP address, except where
that is required for discovery of the LIS.
A.9. L7-9: Discovery Mechanism
"The L7 LCP MUST define a single mandatory to implement discovery
mechanism."
COMPLY
Barnes, et al. Expires October 19, 2008 [Page 40]
Internet-Draft HELD April 2008
HELD uses the discovery mechanism in
[I-D.ietf-geopriv-lis-discovery].
A.10. L7-10: PIDF-LO Creation
"When a LIS creates a PIDF-LO per RFC 4119 then it MUST put the
element into the element of the presence document
(see RFC 4479). This ensures that the resulting PIDF-LO document,
which is subsequently distributed to other entities, conforms to the
rules outlined in ". [I-D.ietf-geopriv-pdif-lo-profile]
COMPLY
HELD protocol overview (Section 4 ) describes the requirements on the
LIS in creating the PIDF-LO and prescribes that the PIDF-LO generated
by the LIS MUST conform to [I-D.ietf-geopriv-pdif-lo-profile].
Authors' Addresses
Mary Barnes (editor)
Nortel
2201 Lakeside Blvd
Richardson, TX
Email: mary.barnes@nortel.com
James Winterbottom
Andrew
PO Box U40
Wollongong University Campus, NSW 2500
AU
Phone: +61 2 4221 2938
Email: james.winterbottom@andrew.com
URI: http://www.andrew.com/
Barnes, et al. Expires October 19, 2008 [Page 41]
Internet-Draft HELD April 2008
Martin Thomson
Andrew
PO Box U40
Wollongong University Campus, NSW 2500
AU
Phone: +61 2 4221 2915
Email: martin.thomson@andrew.com
URI: http://www.andrew.com/
Barbara Stark
BellSouth
Room 7A41
725 W Peachtree St.
Atlanta, GA 30308
US
Email: barbara.stark@bellsouth.com
Barnes, et al. Expires October 19, 2008 [Page 42]
Internet-Draft HELD April 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.
Barnes, et al. Expires October 19, 2008 [Page 43]