Network Working Group A. Mayrhofer
Internet-Draft enum.at
Intended status: Standards Track C. Spanring
Expires: August 18, 2008 OIR-ID
Feb 15, 2008
A Uniform Resource Identifier for Geographic Areas ('geo' URI)
draft-mayrhofer-geo-uri-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 August 18, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document specifies an Uniform Resource Identifier (URI) for
geographic areas using the 'geo' scheme name. A 'geo' URI provides a
compact, human-readable, and protocol independent way to identify an
area by means of a hierarchical tiling scheme.
Mayrhofer & Spanring Expires August 18, 2008 [Page 1]
Internet-Draft 'geo' URI scheme Feb 2008
Table of Contents
1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. IANA Registration of 'geo' URI Scheme . . . . . . . . . . . . 5
5.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 5
5.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 5
5.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 5
5.4.1. Component Description . . . . . . . . . . . . . . . . 6
5.4.2. URI Comparison . . . . . . . . . . . . . . . . . . . . 6
5.5. Properties of the URI scheme . . . . . . . . . . . . . . . 6
5.6. Applications/protocols That Use This URI Scheme . . . . . 7
5.7. Interopability Considerations . . . . . . . . . . . . . . 7
5.8. Security Considerations . . . . . . . . . . . . . . . . . 7
5.9. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.10. Author/Change controller . . . . . . . . . . . . . . . . . 7
5.11. References . . . . . . . . . . . . . . . . . . . . . . . . 7
6. The Tile Hierarchy . . . . . . . . . . . . . . . . . . . . . . 8
7. Encoding of Tile Identifiers . . . . . . . . . . . . . . . . . 11
7.1. Area Bitstring Padding . . . . . . . . . . . . . . . . . . 11
7.2. Appending Padding Counter and Parity Bits . . . . . . . . 11
7.3. Final Base32 Encoding . . . . . . . . . . . . . . . . . . 12
8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Mayrhofer & Spanring Expires August 18, 2008 [Page 2]
Internet-Draft 'geo' URI scheme Feb 2008
1. Change Log
[Note to editors: This section is to be removed before publication -
XML source available on request]
draft-mayrhofer-geo-uri-02
completely new way to create URI - tiling scheme, base32 encoding,
etc.
draft-mayrhofer-geo-uri-01
removed parameters
draft-mayrhofer-geo-uri-00
initial draft
2. Introduction
The use of spatial location in internet technology has gained
significant importance over the last few years. More and more
protocols and data formats are being extended to carry spatial
information, most prominently geographic location.
Most of those specifications are optimized for machine readability,
capable of carrying complex location information (and are therefore
complex by themselves), or are tied to a specific protocol or data
format. On the contrary, the success of domain names, URIs and
telephone numbers indicates that there is a demand for conveying
simple, concise identity information by a variety of "manual" means
between humans.
This document aims at specifying such a simple, concise identifier
for geographic location using a hierarchical tiling scheme. It is
intended to coexist with and support existing "machine-readable"
location information schemes.
According to [RFC3986], a Uniform Resource Identifier (URI) "is a
compact sequence of characters that identifies an abstract or
physical resource". The URI scheme specified in this document (using
the 'geo' scheme name) identifies such a physical resource (a
geographic area) in a compact, human-readable, and protocol
idependent way.
The URI scheme specified in this document uses only geographic
coordinates - the provision of civic addresses to identify locations
is out of scope of this document.
Mayrhofer & Spanring Expires August 18, 2008 [Page 3]
Internet-Draft 'geo' URI scheme Feb 2008
3. 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 RFC 2119 [RFC2119].
In addition this document uses the following terminology:
o area bitstring: A string of bits, describing a geographic tile
according to Section 6.
o tile identifier: A base32 encoded string containing an area
bitstring, padding and parity information, as described in
Section 7.
4. Requirements
(Note: Earlier versions of this document proposed URIs in the form of
"geo:<latitude>,<longitude>". Feedback from the GEOPRIV working
group indicated that this format does not seem to fulfill some of the
requirements mentioned during the presentation. Requirements are
therefore clarified in this section).
The IETF has already produced several specifications in the area of
encoding and conveying geographical location (RFC 4119, RFC 3825, RFC
4776). However, none of those schemes specifically focuses on
conveying geographic location identification among humans or between
humans and machines (for example, for user input into a device).
Identifiers handled by humans are considered to have the following
requirements:
o Interopability: Good identifiers are not limited to an
administrative domain, but are universally usable and recognized.
They have a clear public specification that allows anybody to
create, encode, decode and dereference identifier instances, and
they are easily distinguished from other identifier spaces. URI
schemes are an example of such an identifier scheme.
o Length: Good identifiers are as short as possible. Such
identifiers require less time to read, write and spell them. The
probability of "transmission errors" such as mistyped, missing, or
flipped characters is proportional to the length of an identifier.
o Character set: Good identifiers use a limited character set, which
reduces the risk of confusing two similar characters. A good
character set is also globally recognized.
o Ambigiuity: Good identifiers have little ambigiuity.
o Recognition: Good identifiers allow recognizing rough "similarity"
among a set of identifiers (for example, domain names below the
same top level domain, phone numbers within the same area or
network, email addresses within the same domain name). Such
Mayrhofer & Spanring Expires August 18, 2008 [Page 4]
Internet-Draft 'geo' URI scheme Feb 2008
identifiers allow a quick "categorization" even by humans.
o Error detection: Good identifiers provide basic error detection,
for example a mistyped identifier can at least be recognized as
invalid.
5. IANA Registration of 'geo' URI Scheme
This section contains the fields required for the URI scheme
registration, following the guidelines in section 5.4 of [RFC4395].
5.1. URI Scheme Name
geo
5.2. Status
permanent
5.3. URI Scheme Syntax
The syntax of the 'geo' URI scheme is specified below in Augmented
Backus-Naur Form (ABNF) [RFC4234]:
geo-URI = geo-scheme ":" geo-tile-id \
[ *("." geo-extension) ]
geo-scheme = "geo"
geo-tile-id = 2*32( ALPHA / base32-digits )
base32-digits = "2" / "3" / "4" / "5" / "6" / "7"
geo-extension = *(ALPHA / DIGITS / "-" / "," )
"geo-tile-id" and "geo-extension" are specified in section
Section 5.4.1.
(Note: The "geo-extension" component is under discussion, perspective
extensions are currently worked on. The authors seek feedback
whether an extension mechanism is considered useful)
5.4. URI Scheme Semantics
Data contained in a 'geo' URI identifies a physical resource, namely
the geographic coordinates of a spatial area on Earth in the World
Geodetic System 1984 [WGS84] datum / reference system.
Mayrhofer & Spanring Expires August 18, 2008 [Page 5]
Internet-Draft 'geo' URI scheme Feb 2008
5.4.1. Component Description
The "geo-tile-id" component of the URI contains a tile-identifier
(Base32 encoded), as specified in section Section 6. The
"geo-tile-id" component is case-insensitive.
The "geo-extension" component is currently not specified, but
applications should be prepared to receive URI instances with such
components. Applications should ignore the "geo-extension" for now.
The "geo-extension" components may be used in future revisions of the
specification to further narrow down the area identified.
Note: An application MAY attempt to recover a mistyped geo-tile-path
component by replacing the digit "0" (zero) with the character "o",
the digit "1" (one) with "i" and the digit "8" with "B" (even though
those character may not occur in that component). No replacement
SHOULD be attempted for the digit "9" or any character not listed.
An application SHOULD also strip any whitespace from the input string
before decoding a geo URI.
5.4.2. URI Comparison
Two 'geo' URIs are equal when their lowercased "geo-tile-id"
components are identical, and they contain identical lowercased "geo-
extension" components in identical order.
5.5. Properties of the URI scheme
The described URI scheme provides the following properties:
o URI instances are very short compared to other textual methods to
convey location - a 'geo' URI with a just 8 character long tile-
identifier (including padding and parity) already identifies an
area of approximately 150 x 150 meters (in the worst case, close
to the equator). An instance with 12 characters of tile-
identifier identifies an area of about 0.3 x 0.3 meters.
o By decoding 'geo' URIs while typing, applications can provide
rough results to the user even before the full URI has been
entered. Whenever the user types another character of the tile-
identifier, the application can "zoom in" further.
o It's easy to guess the approximate "scale" of a 'geo' URI by
looking at the length of the tile-identifier, much like numbers.
o The choice of Base32 encoding provides a character set that is
well known by almost all internet users, since it's a subset of
the characters used in Domain Names.
o The parity information provides a mechanism to recognize most
mistyped URIs without external information.
Mayrhofer & Spanring Expires August 18, 2008 [Page 6]
Internet-Draft 'geo' URI scheme Feb 2008
o 'geo' URIs can be visually compared. URIs with similar prefixes
reflect areas that are spatially nearby.
o Instances of 'geo' URIs are easy to read, spell and write, because
the use of special characters has been deliberately limited.
(Note: the current specification does not consider altitude - the
authors seek feedback whether that specification should be extended
to 3 dimensions)
5.6. Applications/protocols That Use This URI Scheme
The 'geo' URI provides resource identification independent of a
specific application or protocol. Examples of potential protocol
mappings and use cases can be found in Section 8.
5.7. Interopability Considerations
Applications MAY generate tile-identifiers using either lowercase or
uppercase characters during Base32 encoding, but SHOULD NOT mix
lowercase and uppercase characters in a single URI instance.
Applications MUST be able to decode URI instances with upper-, lower
as well as mixed case characters.
FIXME: accept geo URIs with "wrong" padding bits?
5.8. Security Considerations
See Section 10 of [insert reference to this document]
5.9. Contact
Christian Spanring (mailto:spanring@oir.at, http://spanring.eu/),
Alexander Mayrhofer (mailto:alexander.mayrhofer@enum.at,
http://nona.net/)
More information and sample applications can be found at
http://www.geouri.org/
5.10. Author/Change controller
The 'geo' URI scheme is registered under the IETF part of the URI
tree. As such, change control is up to the IETF.
5.11. References
tbd.
Mayrhofer & Spanring Expires August 18, 2008 [Page 7]
Internet-Draft 'geo' URI scheme Feb 2008
6. The Tile Hierarchy
The "tile-identifier" of the 'geo' URI uses a hierarchical scheme to
tile an equirectangular projection of Earth's surface into
rectangular tiles.
Tiling starts with a global plate carree (longitude ranging from 180
degrees west to 180 degrees east, and latitude ranging from 90
degrees north to 90 degrees south). The WGS 84 reference system and
datum is used. Such a plate carree reflects an empty area bitstring,
and can be illustrated as follows:
-180 0 +180
+90 +-----------------------------------------------+
| |
| |
| |
| |
| |
0 | |
| |
| |
| |
| |
| |
-90 +-----------------------------------------------+
The first tiling step splits that area vertically, into two aras of
(-180 to 0 longitude / +90 to -90 latitude) and (0 to 180 longitude /
+90 to -90 latitude), respectively. The "left" area is assigned a
binary 0, and the "right" area is assigned a binary 1, as illustrated
below:
-180 0 +180
+90 +-----------------------+-----------------------+
| | |
| | |
| | |
| | |
| | |
0 | 0 | 1 |
| | |
| | |
| | |
| | |
| | |
-90 +-----------------------+-----------------------+
Mayrhofer & Spanring Expires August 18, 2008 [Page 8]
Internet-Draft 'geo' URI scheme Feb 2008
A subsequent tiling step involves splitting each of the areas
vertically, resulting in a total number of 4 tiles. To identify a
sub-tile in this step, a binary 0 is appended to the area bitstring
of each individual "upper" tile, and a binary 1 to the "lower" tile:
-180 0 +180
+90 +-----------------------+-----------------------+
| | |
| | |
| 00 | 10 |
| | |
| | |
0 +-----------------------+-----------------------+
| | |
| | |
| 01 | 11 |
| | |
| | |
-90 +-----------------------+-----------------------+
From now on, vertical and horizontal splitting is continued until the
desired resolution is achieved, recursively tiling the whole range of
coordinates into smaller areas. Whenever a "sub-area" is split, the
new "left" (or "upper") area is identified by appending a binary 0 to
the area string , and the new "right" (or "lower") area is identified
by appending a binary 1 to the area bitstring. After another
repetition of a vertical split, the areas look like this:
-180 0 +180
+90 +-----------+-----------+-----------+-----------+
| | | | |
| | | | |
| 000 | 001 | 100 | 101 |
| | | | |
| | | | |
0 +-----------+-----------+-----------+-----------+
| | | | |
| | | | |
| 010 | 011 | 110 | 111 |
| | | | |
| | | | |
-90 +-----------+-----------+-----------+-----------+
After another horizontal split, the following areas are identified:
Mayrhofer & Spanring Expires August 18, 2008 [Page 9]
Internet-Draft 'geo' URI scheme Feb 2008
-180 0 +180
+90 +-----------+-----------+-----------+-----------+
| 0000 | 0010 | 1000 | 1010 |
| | | | |
+-----------+-----------+-----------+-----------+
| 0001 | 0011 | 1001 | 1011 |
| | | | |
0 +-----------+-----------+-----------+-----------+
| 0100 | 0110 | 1100 | 1110 |
| | | | |
+-----------+-----------+-----------+-----------+
| 0101 | 0111 | 1101 | 1111 |
| | | | |
-90 +-----------+-----------+-----------+-----------+
After another ("vertical" split), the following area bitstrings
exist:
-180 0 +180
+90 +-----+-----+-----+-----+-----+-----+-----+-----+
|00000|00001|00100|00101|10000|10001|10100|10101|
| | | | | | | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
|00010|00011|00110|00111|10010|10011|10110|10111|
| | | | | | | | |
0 +-----+-----+-----+-----+-----+-----+-----+-----+
|01001|01101|01100|01101|11000|11001|11100|11101|
| | | | | | | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
|01010|01011|01110|01111|11010|11011|11110|11111|
| | | | | | | | |
-90 +-----+-----+-----+-----+-----+-----+-----+-----+
Those splitting steps can be repeated as long until the desired size
of the area to be identified is reached. Tiling MUST always be
initiated with a vertical split. After a vertical split, the next
split MUST be a horizontal split. After a horizontal split, the next
split MUST be a vertical split, etc..
The resulting area bitstring is used in encoding tile identifiers
(see Section 7).
Note that area bitstrings can be obviously calculated directly as
well - the above "splitting" procedure is considered to have
illustrative value.
Mayrhofer & Spanring Expires August 18, 2008 [Page 10]
Internet-Draft 'geo' URI scheme Feb 2008
7. Encoding of Tile Identifiers
A "geo" URI contains base32 encoded tile identifiers. This section
describes how to transform area bitstrings into their Base32
representation.
7.1. Area Bitstring Padding
Since tiling as outlined above may be stopped at any "resolution",
area bitstrings may have arbitrary numbers of binary digits, and
therefore not fit into the 5-bit boundaries of Base32. The following
process MUST be followed to pad area bitstrings to multiples of 5 bit
(the example uses an area bitstring of 12 bits):
1. Identify number of significant bits in area bitstrings (void bits
are illustrated as dots below):
01011 10100 11... (12 significant bits)
area id: --------------
2. Pad area bitstring to the next 5-bit border with "0" bits, and
record the number of padding bits used in "padding-counter":
01011 10100 11000 (total lenght: 15 bit)
area id: --------------
padding: --- (padding-counter: 3)
(Note that after padding, the number of significant bit cannot be
recovered from the padded area bitstring without the padding-
counter).
7.2. Appending Padding Counter and Parity Bits
To recover the number of significant bits in the resulting URI
string, the binary representation of padding-counter is appended to
the padded area bitstring. Since the padding size is between 0 and 4
bits, 3 bits are required to encode padding-counter.
01011 10100 11000 011 (padding-counter: 3)
area id: --------------
padding: ---
padding-counter: ---
The encoded padding-counter of 3 bits always leaves 2 bits of "free
space" in the last 5 bit group. Those 2 bits are used for parity
bits, which are calculated as follows:
o The first parity bit (A) is used to convey even parity over the
"longitude" bits
Mayrhofer & Spanring Expires August 18, 2008 [Page 11]
Internet-Draft 'geo' URI scheme Feb 2008
o The second parity bit (B) is used to convey even parity for the
"latitude" bits
01011 10100 11000 01100
area id: ----- ----- --
parity bits: --
longitude bit: 0 0 1 0 0 1 0 (parity bit A - longitude)
latitude bit: 1 1 1 1 0 0 0 (parity bit B - latitude)
Note that padding bits MUST NOT be included in parity calculation
(the use of '0' bits for padding does not affect parity anyways,
however, mangled URI instances could contain '1's in padding).
7.3. Final Base32 Encoding
The bitstream resulting from the operations above (including the
significance / parity bits) is Base32 encoded according to section 5
of [RFC3548].
Bitstream: 01011 10100 11000 01100
Decimal: 11 20 24 12
Base32: L U Y M
Therefore, the final base32 encoded tile identifier is "LUYM". That
string is to be used in the "geo-tile-id" component of the URI (see
Section 5.3).
8. Example
The following 'geo' URI identifies a geographic area that resembles
the square in front of one of the author's office:
o Center coordinates (approx.): 48.200179 latitude, 16.367957
longitude.
o Number of tiling steps: 34
o Area bitstring: 1000010111001111100111010000111011
o Geographic coordinates of respective area: 48.1997680664 to
48.2011413574 degrees north, 16.3668823242 to 16.3696289062
degrees east ( approximately 150 x 300 meters).
o Area bitstring padded:
10000 10111 00111 11001 11010 00011 10110
=
o Area bitstring with padding-counter (1 bit padding):
10000 10111 00111 11001 11010 00011 10110 001
===
Mayrhofer & Spanring Expires August 18, 2008 [Page 12]
Internet-Draft 'geo' URI scheme Feb 2008
o Adding parity bits:
10000 10111 00111 11001 11010 00011 10110 00110
==
lon: 1 0 0 0 1 0 1 1 1 0 1 0 0 0 1 1 1 0 -> 1
lat: 0 0 1 1 1 0 1 1 0 1 1 1 0 0 1 0 1 --> 0
o Base32 encoding:
10000 10111 00111 11001 11010 00011 10110 00110
Q X H Z 2 D W G
o Resulting 'geo' URI:
geo:QXHZ2DWG
9. IANA Considerations
This document requests assignment of the 'geo' URI scheme in the IETF
part of the URI scheme tree, according to the guidelines in BCP 115
(RFC 4395) [RFC4395]. The definitions required for the assignment
are contained in Section 5.
10. Security Considerations
Because the 'geo' URI is not tied to any specific protocol, and
identifies a physical area rather than an abstract resource, most of
the general security considerations on URIs (Section 7 of RFC 3986)
do not apply.
Instances of 'geo' URIs convey location information. Such location
information may be publicly known, and therefore not be very
sensitive (for example, 'geo' URIs conveying the location of public
sights, hotels, etc.). However, 'geo' URIs might be used in
situations that have considerable privacy implications (for example,
the current location of a person combined with Personally
Identifieable Information).
Therefore, security and privacy must be considered for individual use
cases.
11. References
Mayrhofer & Spanring Expires August 18, 2008 [Page 13]
Internet-Draft 'geo' URI scheme Feb 2008
11.1. Normative References
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003.
11.2. Informative References
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 115,
RFC 4395, February 2006.
[WGS84] National Imagery and Mapping Agency, "Department of
Defense World Geodetic System 1984, Third Edition",
NIMA TR8350.2, January 2000.
Authors' Addresses
Alexander Mayrhofer
enum.at GmbH
Karlsplatz 1/9
Wien A-1010
Austria
Phone: +43 1 5056416 34
Email: alexander.mayrhofer@enum.at
URI: http://www.enum.at/
Christian Spanring
OIR-ID GmbH
Franz-Josefs-Kai 27
Wien A-1010
Phone: +43 1 5338747 36
Email: spanring@oir.at
URI: http://www.oir.at/
Mayrhofer & Spanring Expires August 18, 2008 [Page 14]
Internet-Draft 'geo' URI scheme Feb 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).
Mayrhofer & Spanring Expires August 18, 2008 [Page 15]