One document matched: draft-thomson-geopriv-location-quality-02.txt
Differences from draft-thomson-geopriv-location-quality-01.txt
GEOPRIV M. Thomson
Internet-Draft J. Winterbottom
Intended status: Standards Track Andrew
Expires: June 8, 2009 December 5, 2008
Specifying Location Quality Constraints in Location Protocols
draft-thomson-geopriv-location-quality-02
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 June 8, 2009.
Thomson & Winterbottom Expires June 8, 2009 [Page 1]
Internet-Draft Location Quality December 2008
Abstract
Parameters that define the expected quality of location information
are defined for use in location protocols. These parameter can be
used by a requester to indicate to a Location Server the desired
constraints on the quality of the location information provided. If
applicable, the Location Server is able to use this information to
control how location information is determined. An optional
indication of whether the quality constraints were met is defined to
be provided by the Location Server alongside location information.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . 4
2. Location Quality Operation . . . . . . . . . . . . . . . . . . 5
3. Location Quality Objects . . . . . . . . . . . . . . . . . . . 6
3.1. Location Quality Request . . . . . . . . . . . . . . . . . 6
3.1.1. Maximum Uncertainty . . . . . . . . . . . . . . . . . 6
3.1.2. Required Civic Elements . . . . . . . . . . . . . . . 7
3.1.3. Maximum Age . . . . . . . . . . . . . . . . . . . . . 8
3.2. Location Quality Indication . . . . . . . . . . . . . . . 8
4. Location Quality Schema . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lq . . . . . . . . . . . . 14
6.2. XML Schema Registration for Location Quality Schema . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Thomson & Winterbottom Expires June 8, 2009 [Page 2]
Internet-Draft Location Quality December 2008
1. Introduction
Location determination methods produce results of varying accuracy.
In general, the accuracy of location information increases as the
effort expended in generating the information increases. Accuracy is
the primary aspect of the quality of location information that is
relevant to a Location Recipient (LR). Other aspects of quality can
also be significant, such as the currency of the data.
Means for expressing the quality of location information is outlined
in [I-D.thomson-geopriv-uncertainty] and [GeoShape]. An entity
requesting location information of a Location Server (LS) is unable
to specify the quality of the location that it ultimately receives.
This is inefficient because an LS either provides location
information that is inadequate for the intended task; or the LS could
waste resources generating location information that is of
eccessively high quality.
This document defines XML objects that can be added to any protocol
that provides location information. These elements provide the
ability to communicate location quality constraints to an LS. These
constraints specify a desired uncertainty at a certain confidence,
plus the maximum acceptable age where location information is stored.
Guidelines for deterministically evaluating location information
against these rules are provided.
This document provides semantics, examples and security
considerations for the HELD protocol
[I-D.ietf-geopriv-http-location-delivery]. Application of the
parameters described in this document to other protocols is out of
scope.
Location quality constraints provide information that an LS can use
in deciding how to generate location information, if the LS has that
capacity directly or otherwise. This is the case for a Location
Information Server (LIS) and the HELD protocol.
Specifying location quality constraints ensures that a Location
Receipient (LR) receives information that is suited to their needs.
It also provides information that any Location Generator (LG) can use
to better decide how location information is generated. This
provides advantages to both requester and source of the information.
In one example, a LIS that is able to provide a location estimate
with uncertainty that matches the requested constraints might be able
to provide that response before the time indicated within the time
indicated in the request (the "responseTime").
This document also defines an object that can be used by the LS to
Thomson & Winterbottom Expires June 8, 2009 [Page 3]
Internet-Draft Location Quality December 2008
indicate if the location quality meets the constraints. These
parameters can be used by a Location Recipient to ensure that the
location is of adequate quality without requiring specific checking
without having to examine the location object. Response parameters
are an optional optimisation; the presence of a quality indication in
the response also indicates that the LS has understood the location
quality constraints.
1.1. Conventions used in this document
Terms and procedures relating to uncertainty and confidence are taken
from [I-D.thomson-geopriv-uncertainty]. Familiarity with terminology
outlined in [I-D.ietf-geopriv-l7-lcp-ps] and [RFC3693] is also
assumed.
The term Location Server (LS) is used as a generic label, since these
paramters apply in all cases where location information is served to
a requesting entity. From the perspective of this document, the LS
could be a Location Information Server (LIS). Similarly, the term
Location Recipient (LR) is used to refer to the requester of location
information, which could be a Device or Target for HELD.
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].
Thomson & Winterbottom Expires June 8, 2009 [Page 4]
Internet-Draft Location Quality December 2008
2. Location Quality Operation
Location quality parameters are provided by a Location Recipient in a
location request message. Figure 1 shows an example HELD message
where a Device requests location information of a specified quality.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="true">geodetic</locationType>
<quality xmlns="urn:ietf:params:xml:ns:geopriv:lq">
<maxUncertainty confidence="95">
<horizontal>150</horizontal>
<vertical>1000</vertical>
</maxUncertainty>
<maxAge>2008-05-27T05:47:55Z</maxAge>
</quality>
</locationRequest>
Figure 1: Example HELD Location Request
An LS that supports the location quality element uses the information
contained in the request to choose how it serves the query. If the
LS sources the information from an LG, this information might be
passed to the LG to determine how it generates the information. The
response to this message contains a quality indicator element that
includes a list of the quality constraints that were met. Figure 2
shows a location response that includes a quality indicator.
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:user@example.com">
<!-- Actual location information omitted -->
</presence>
<qualityInd xmlns="urn:ietf:params:xml:ns:geopriv:lq">
maxUncertainty/vertical maxAge
</qualityInd>
</locationResponse>
Figure 2: Example HELD Location Response
An LS provides an indication of the constraints that have been met.
The actual quality of the location estimate SHOULD be included in the
actual PIDF-LO document, expressed in the location uncertainty,
timestamp, or through the presence of absence of civic address
fields.
Thomson & Winterbottom Expires June 8, 2009 [Page 5]
Internet-Draft Location Quality December 2008
3. Location Quality Objects
This section defines the format and semantics of the location quality
parameters for requests and the indication that is included with
responses.
3.1. Location Quality Request
The "quality" element is included in a HELD request to indicate the
constraints set by the Location Recipient (LR) on the quality of
returned location information. This document defines three elements
that are included.
3.1.1. Maximum Uncertainty
The "maxUncertainty" element describes an upper limit on uncertainty
at a given confidence. Uncertainty is divided in to horizontal and
vertical components. Horizontal uncertainty is the maximum distance
from the centroid of the area to the point in the shape furthest from
the centroid on the horizontal plane. Vertical uncertainty is the
difference in altitude from the centroid to the point in the shape
with the greatest altitude.
The "horizontal" and "vertical" elements are numerical values that
contain a decimal value in metres. Maximum uncertainty values MUST
be greater than zero.
A location estimate that does not contain uncertainty (i.e. a Point
shape), never meets location quality constraints. Where uncertainty
is unknown, it MUST be assumed to be infinite at any non-zero
confidence. In particular, this applies to vertical uncertainty
where the location estimate is two-dimensional only; location
estimates without a vertical component of uncertainty never meet
vertical uncertainty constraints.
Note: An LS MAY provide location information using the Point shape
and indicate that the requested uncertainty is met, if the LS has
access to uncertainty information and does not want to share this
information. However, this is NOT RECOMMENDED since the LR has no
way of independently verifying that the uncertainty meets their
requirements.
The "confidence" attribute of this element includes the confidence
level (expressed as a percentage) that the uncertainty is evaluated
at. Confidence has a default value of 95%.
To evaluate uncertainty, the location estimate is first scaled so
that the confidence of the estimate matches (or exceeds) the
Thomson & Winterbottom Expires June 8, 2009 [Page 6]
Internet-Draft Location Quality December 2008
requested confidence. The LS SHOULD convert the shape of the
uncertainty to a circle or a sphere prior to scaling to simply the
scaling process. For consistency--and contrary to the rules in
[I-D.thomson-geopriv-uncertainty]--it is RECOMMENDED that a normal
PDF be assumed for all location information except where confidence
is reduced for a rectangular PDF.
Horizontal uncertainty is evalulated by removing the altitude and
altitude uncertainty components from the location estimate. While
removing altitude components from a location estimate might normally
increase confidence, confidence MUST NOT be increased at this step;
the confidence value has already been considered. The shape is then
converted to a circle, if it is not already in that shape. The
radius of the resulting circle is compared to the maximum horizontal
uncertainty.
Vertical uncertainty is evaluated for shapes that contain altitude
uncertainty. The value used for evaluating vertical uncertainty
depends on the shape type: the vertical axis value for the Ellipsoid
shape; the radius of the Sphere shape; half the height of the Prism
shape. A constraint on vertical uncertainty cannot be met if
vertical uncertainty is not known.
The LS MAY use location quality parameters to alter the way that it
generates location information and to provide location information
that more closely matches what is requested. If maximum value is
provided for vertical uncertainty, it is RECOMMENDED that the LS
provide a location estimate that includes altitude and altitude
uncertainty if possible. It is RECOMMENDED that the LS provide
location information at the confidence included in the request, if
scaling to a particular confidence is possible. Scaling MAY be
avoided if the location information is significantly degraded by the
scaling process.
3.1.2. Required Civic Elements
The "requiredCivic" element represents the requirements of an LR for
civic address information. An LR can specify the address elements
that need to be present in the civic address in order for the
location information to meet their quality requirements.
The "requiredCivic" element contains a whitespace-separated list of
element names. These can be interpreted as XPath
[W3C.REC-xpath20-20070123] expressions that are evaluated in the
context of the "civicAddress" element [RFC5139]. These XPath
statements are restricted to use of qualified names only (using the
response document namespace context) and the "/" separator; that is,
the only permitted axis is the "child::" axis. All child nodes of
Thomson & Winterbottom Expires June 8, 2009 [Page 7]
Internet-Draft Location Quality December 2008
elements (including attributes and textual content) are treated as
belonging to an element.
Figure 3 shows an example request where an LR requires country, state
(or equivalent) and post code civic address elements in the location
information provided by the LS.
<quality xmlns="urn:ietf:params:xml:ns:geopriv:lq">
<requiredCivic
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
ca:country ca:A1 ca:PC
</requiredCivic>
</quality>
Figure 3: Example Specifying Required Civic Address Fields
Note that this does not force the LS to restrict civic address
information to the indicated fields. Additional fields can be
provided.
3.1.3. Maximum Age
Where location information is stored or cached, an LR can specify a
limit on the age of this information. This is particularly important
if location information is generated in advance. The "age" of
location information is indicated by the the "timestamp" element in
the PIDF tuple. The age parameter specifies the minimum value for
this field; that is, the oldest location information that is
acceptable.
Location information that has greater age than requested SHOULD
either be determined anew, or checked so that the timestamp can be
updated. A value of "now" can be used to indicate that stored
location information is not acceptable to the LR.
3.2. Location Quality Indication
The "qualityInd" element is used in responses to indicate which of
the location quality constraints from a request were met. The
"qualityInd" element contains a list of the quality constraints that
the accompanying location information meets.
The list of constraints is represented as a whitespace-separated list
of element names. These can be interpreted as XPath
[W3C.REC-xpath20-20070123] expressions that are evaluated in the
context of the original location quality request. These statements
follow the same constraints as the list of elements in Section 3.1.2.
Thomson & Winterbottom Expires June 8, 2009 [Page 8]
Internet-Draft Location Quality December 2008
Where elements are nested, such as the "maxUncertainty" element, the
outer element can be included to indicate an entire constraint is
met; or, each individual child element can be identified. Two
equivalent indications are shown in Figure 4.
<qualityInd xmlns="urn:ietf:params:xml:ns:geopriv:lq">
maxUncertainty
</qualityInd>
<qualityInd xmlns="urn:ietf:params:xml:ns:geopriv:lq">
maxUncertainty/horizontal maxUncertainty/vertical
</qualityInd>
Figure 4: Equivalent Quality Indications
A LS that is unable to determine if a constraint MUST either omit the
quality indication, or indicate that the constraint was not met.
Two special values are added to the quality indication element for
convenience. The value "##all" indicates that all quality
constraints were met (including any extensions). An empty list
indicates that none of the constraints were met.
Thomson & Winterbottom Expires June 8, 2009 [Page 9]
Internet-Draft Location Quality December 2008
4. Location Quality Schema
Note that the pattern rules in the following schema wrap due to
length constraints in RFC documents. None of the patterns contain
whitespace.
<?xml version="1.0"?>
<xs:schema
xmlns:lq="urn:ietf:params:xml:ns:geopriv:lq"
xmlns:conf="urn:ietf:params:xml:ns:geopriv:conf"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lq"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lq">
HELD Location Quality
</xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
published RFC and remove this note.]] -->
This schema defines a framework for location quality requests
and indications of whether they are met.
</xs:documentation>
</xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:geopriv:conf"/>
<xs:element name="quality">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element ref="lq:maxUncertainty" minOccurs="0"/>
<xs:element ref="lq:requiredCivic" minOccurs="0"/>
<xs:element ref="lq:maxAge" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="maxUncertainty" type="lq:maxUncertaintyType"/>
Thomson & Winterbottom Expires June 8, 2009 [Page 10]
Internet-Draft Location Quality December 2008
<xs:complexType name="maxUncertaintyType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="horizontal" type="lq:limitType"/>
<xs:element name="vertical" type="lq:limitType"/>
</xs:sequence>
<xs:attribute name="confidence" type="conf:confidenceBase"
default="95"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:simpleType name="limitType">
<xs:restriction base="xs:decimal">
<xs:minExclusive value="0.0"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="maxAge" type="lq:maxAgeType"/>
<xs:simpleType name="maxAgeType">
<xs:restriction base="xs:duration">
<xs:minInclusive value="PT0S"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="requiredCivic" type="lq:elementListType"/>
<xs:element name="qualityInd" type="lq:qualityIndType"/>
<xs:simpleType name="qualityIndType">
<xs:union memberTypes="lq:elementListType">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="##all"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:simpleType name="elementListType">
<xs:list>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:pattern
value="(([\i-[:]][\c-[:]]*:)?[\i-[:]][\c-[:]]*/)*
([\i-[:]][\c-[:]]*:)?[\i-[:]][\c-[:]]*"/>
</xs:restriction>
</xs:simpleType>
Thomson & Winterbottom Expires June 8, 2009 [Page 11]
Internet-Draft Location Quality December 2008
</xs:list>
</xs:simpleType>
</xs:schema>
Thomson & Winterbottom Expires June 8, 2009 [Page 12]
Internet-Draft Location Quality December 2008
5. Security Considerations
This document does not introduce any security considerations.
[[Editor's Note: Please let us know if you find any.]]
Thomson & Winterbottom Expires June 8, 2009 [Page 13]
Internet-Draft Location Quality December 2008
6. IANA Considerations
This section registers a namespace and schema for the location
quality objects.
6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lq
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:lq", as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:lq
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Martin Thomson (martin.thomson@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>Location Quality</title>
</head>
<body>
<h1>Namespace for Location Quality</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lq</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 for Location Quality Schema
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:geopriv:lq
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
Thomson & Winterbottom Expires June 8, 2009 [Page 14]
Internet-Draft Location Quality December 2008
Schema: The XML for this schema can be found in Section 4 of this
document.
Thomson & Winterbottom Expires June 8, 2009 [Page 15]
Internet-Draft Location Quality December 2008
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.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, February 2008.
[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-10 (work in
progress), October 2008.
[I-D.thomson-geopriv-uncertainty]
Thomson, M. and J. Winterbottom, "Representation of
Uncertainty and Confidence in PIDF-LO",
draft-thomson-geopriv-uncertainty-02 (work in progress),
November 2008.
7.2. Informative References
[W3C.REC-xpath20-20070123]
Boag, S., Chamberlin, D., Berglund, A., Robie, J., Kay,
M., Simeon, J., and M. Fernandez, "XML Path Language
(XPath) 2.0", World Wide Web Consortium
Recommendation REC-xpath20-20070123, January 2007,
<http://www.w3.org/TR/2007/REC-xpath20-20070123>.
[I-D.busin-geopriv-location-qos-req]
Busin, A., Jin, Y., Mosmondor, M., and S. Loreto,
"Requirements for a Location Quality of Service (QoS)
Information Object",
draft-busin-geopriv-location-qos-req-01 (work in
progress), November 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-08 (work in
progress), June 2008.
Thomson & Winterbottom Expires June 8, 2009 [Page 16]
Internet-Draft Location Quality December 2008
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[GeoShape]
Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape
Application Schema for use by the Internet Engineering
Task Force (IETF)", Candidate OpenGIS Implementation
Specification 06-142r1, Version: 1.0, April 2007.
Thomson & Winterbottom Expires June 8, 2009 [Page 17]
Internet-Draft Location Quality December 2008
Authors' Addresses
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/
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/
Thomson & Winterbottom Expires June 8, 2009 [Page 18]
Internet-Draft Location Quality December 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.
Thomson & Winterbottom Expires June 8, 2009 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-23 12:57:47 |