Network Working Group B. Hoehrmann
Internet-Draft September 20, 2006
Intended status: Informational
Expires: March 24, 2007
The application/www-form-urlencoded format
draft-hoehrmann-urlencoded-00
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 March 24, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This memo defines a compact data format that encodes data sets of
name-value pairs. It is designed to be suitable for use as query
strings in Internationalized Resource Identifiers and as standalone
format.
Hoehrmann Expires March 24, 2007 [Page 1]
Internet-Draft application/www-form-urlencoded format September 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Conformance . . . . . . . . . . . . . . . . . 4
3. Encoding algorithm . . . . . . . . . . . . . . . . . . . . . . 5
4. Decoding algorithm . . . . . . . . . . . . . . . . . . . . . . 6
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Fragment identifiers . . . . . . . . . . . . . . . . . . . . . 9
7. Application-specific processing . . . . . . . . . . . . . . . 10
8. Compatibility considerations . . . . . . . . . . . . . . . . . 11
9. Security considerations . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11. Media type registration . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . 14
Hoehrmann Expires March 24, 2007 [Page 2]
Internet-Draft application/www-form-urlencoded format September 2006
1. Introduction
RFC 1866 [RFC1866] introduced the application/x-www-form-urlencoded
media type to facilitate the encoding and transmission of form data
sets. Formats based on RFC 1866 continued to use this media type as
default encoding format, and other standards adopted the type for
similar purposes, in disregard of the fact that use of experimental
media types is discouraged [RFC4288].
The format itself has a number of shortcomings. As noted in RFC
1866, the use of the ampersand character as separator makes inclusion
of resource identifiers created based on this encoding in HTML/XML
documents unnecessarily difficult as the character has to be escaped;
the set of characters that have to be escaped is overly broad, making
resulting resource identifiers difficult to read and use, and issues
of internationalization are not addressed.
Attempts have been made to address some of these issues in specific
domains, such as allowing use of alternate separator characters,
allowing use of characters outside the ASCII repertoire, and use of a
charset parameter along with the media type; while these changes had
a positive effect in their respective domains, they have also led to
proliferation of the format.
This specification introduces application/www-form-urlencoded, a new
format intended to address these problems and to obsolete the legacy
application/x-www-form-urlencoded format. It provides the following
benefits:
o The format relies on the UTF-8 character encoding [RFC3629],
applications do not have to specify or guess the encoding, and
non-ASCII characters do not have to be escaped, which allows for
significant space saving when textual data is encoded.
o The ';' character is used as separator; resource identifiers
construced based on this format can be copied and pasted into HTML
and XML documents easily since no additional escaping has to be
applied.
o Common characters are not escaped, encoded data sets look like
"url=http://example.org/" not "url=http%3A%2F%2Fexample.org%2F" as
would be the case with application/x-www-form-urlencoded.
o Encoded data sets can be labeled with a registered media type in
the standards tree; applications do not have to rely on
unregistered and experimental types whose use is discouraged.
Hoehrmann Expires March 24, 2007 [Page 3]
Internet-Draft application/www-form-urlencoded format September 2006
o The format is fully defined in this document and compatible with
application/x-www-form-urlencoded which eases transition to the
new format in environments where compatibility is needed.
Migrating existing applications to application/www-form-urlencoded is
expected to be straightforward in many cases; refer to section 8 for
details.
2. Terminology and Conformance
A character string is a sequence of Unicode code points suitable for
use with the UTF-8 character encoding. An octet string is a sequence
of octets.
A character string conforms to this specification if and only if
encoding it using the UTF-8 character encoding yields a octet string
that conforms to this specification.
A octet string conforms to this specification if and only if it is,
after replacing all sequences that match pct-encoded [RFC3986] by the
corresponding octets, a valid UTF-8 sequence.
A software module that encodes data sets into character strings
conforms to this specification if and only if it does so as described
in section 3. Character strings that have been produced by means of
such a software module are said to be in the canonical form,
canonical encoding, or simply canonical.
A software module that decodes character strings or octets into data
sets conforms to this specification if and only if it does so as
described in section 4.
A specification conforms to this specification if and only if it
describes handling of application/www-form-urlencoded and does not
contradict this specification. Software that implements such a
specification will conform to this specification as applicable.
Note: Specifications defining application/x-www-form-urlencoded
processing sometimes include provisions to control, for example,
separator characters, character encoding, or which characters have
to be escaped. Such provisions cannot apply to the format defined
in this document.
Specifications are encouraged to specify Unicode normalization of
data sets before passing them to the encoding algorithm defined in
this specification, to specify CRLF newline normalization, and to
take advantage of the notion of undefined values.
Hoehrmann Expires March 24, 2007 [Page 4]
Internet-Draft application/www-form-urlencoded format September 2006
The algorithms defined in this document are considered equivalent to
any and all algorithms that map the same input to the same results.
3. Encoding algorithm
This section describes the transformation of an ordered list of
(<name>, <value>) pairs into a compact character string. A list of
pairs is empty, has at least one defined <value>, or one <name> of
non-zero length. A <name> is a character string; a <value> is either
a character string or undefined.
Note: This definition rules out the possibility of a list with
only one pair where the <name> is an empty string and the <value>
undefined; such a list would be transformed into the empty string
and therefore be indistinguishable from an empty list. All other
lists can be encoded.
For the purposes of the following algorithm, a character is escaped
by representing the character as sequence of octets using the UTF-8
character encoding, and percent-encoding [RFC3986] the octets using
uppercase hexadecimal digits.
The algorithm is as follows:
1. Replace all space characters (U+0020) by a plus sign (U+002B)
and escape the character '%' in each <name> and <value>.
2. Escape the characters ';', '&', '=' and any character that
cannot occur in an iquery [RFC3987] in each <name> and
<value>.
3. Replace each pair by <name> if the <value> is undefined and by
<name> followed by '=' followed by <value> otherwise.
4. Concatenate the character strings in order, using ';' as
separator.
The following is the set of characters that have to be escaped in the
second step of the algorithm above. Refer to the algorithm for the
normative definition of this set, and to [RFC3987] section 2.2 for
more information about the notation. The range U+D800-U+DFFF has
been included for reasons of completeness, character strings do not
include code points in this range.
Hoehrmann Expires March 24, 2007 [Page 5]
Internet-Draft application/www-form-urlencoded format September 2006
%x00000-00020 / %x00022-00023 / %x00026-000026 / %x00003B-00003D /
%x0003E-0003E / %x0005B-0005E / %x00060-000060 / %x00007B-00007D /
%x0007F-0009F / %x0D800-0DFFF / %x0FDD0-00FDEF / %x00FFF0-00FFFF /
%x1FFFE-1FFFF / %x2FFFE-2FFFF / %x3FFFE-03FFFF / %x04FFFE-04FFFF /
%x5FFFE-5FFFF / %x6FFFE-6FFFF / %x7FFFE-07FFFF / %x08FFFE-08FFFF /
%x9FFFE-9FFFF / %xAFFFE-AFFFF / %xBFFFE-0BFFFF / %x0CFFFE-0CFFFF /
%xDFFFE-E0FFF / %xEFFFE-EFFFF / %xFFFFE-0FFFFF / %x10FFFE-10FFFF ;
The resulting string matches the iquery production of [RFC3987] and
is thus suitable for use as query string in IRIs. Specifications
taking advantage of this feature are expected to define processing in
terms of IRIs and in accordance with [RFC3987]; construction of query
strings suitable for use in Uniform Resource Identifiers is thus
considered out of scope of this specification.
4. Decoding algorithm
This section describes the transformation of a character or octet
string that conforms to this specification into an ordered list of
(<name>, <value>) pairs. The purpose of this definition is to
establish which data set a given string corresponds to, it is not
meant to constrain how applications process the resulting data set.
The algorithm is as follows:
1. If the input is a character string, encode the sequence using
the UTF-8 character encoding.
2. If the octet sequence has a length of zero, the result is an
empty list of pairs; otherwise proceed with the algorithm.
3. Split the octet sequence into an ordered list at each
occurrence of the octets 0x3B (';') and 0x26 ('&'). If
neither octet is part of the sequence, the list contains this
sequence only.
4. Split each of the octet sequences into a (<name>, <value>)
pair at the first occurrence of the octet 0x3D ('='); if this
octet is not part of the sequence, the <name> is the whole
sequence and the <value> is undefined.
5. Replace each occurrence of a sequence that matches pct-encoded
[RFC3986] by the corresponding octet and each occurrence of
the octet 0x2B ('+') by the octet 0x20 (' ') in each <name>
and <value>.
6. Decode all octet sequences using the UTF-8 character encoding.
Hoehrmann Expires March 24, 2007 [Page 6]
Internet-Draft application/www-form-urlencoded format September 2006
Strings that do not conform to this specification cannot be decoded
my means of this algorithm as they represent invalid UTF-8 sequences.
Handling of invalid strings is subject to [RFC3629] and otherwise
unconstrained by this specification. Avoidance of any form of error
recovery when processing application/www-form-urlencoded entities is
encouraged.
5. Examples
This section provides a number of examples that illustrate encoding
and decoding of data sets as defined in this specification. At the
beginning of each example is the data set under consideration; it is
followed by the representation of the data set in the canonical
encoding (==) and then one or more alternate strings that represent
the same data set (~~) or a different data set (!!).
Note: Implementations of this specification only produce strings
in the canonical form. Decoders however will typically also have
to handle strings not in the canonical encoding, for example, when
the string had to be transformed for use in a context that does
not support the canonical form, such as query strings in URIs.
Character strings are delimited by '"' characters and may include
"<U+HHHH>" sequences which refer to the Unicode code point U+HHHH.
The examples are to be understood in the context of section 7; the
equivalence rules provided here hold in the general case, but some
applications might apply additional equivalence rules.
The following example illustrates handline of space characters. In
the canonical encoding space characters are replaced by the '+'
character; the decoding algorithm is more tolerant, it also accepts
spaces encoded as "%20" and space characters that occur literally.
Also note that leading and trailing space characters are preserved.
((" a b c ", " 1 3 "))
== "+a+b+c+=+1++3+"
~~ "%20a%20b%20c%20=1%20%203%20"
~~ "<U+0020>a<U+0020>b<U+0020>c=1<U+0020><U+0020>3<U+0020>"
Newline characters are not normalized by the encoder or decoder:
(("Text", "Line1<U+000A>Line2"))
== "Text=Line1%0ALine2"
~~ "Text=Line1<U+000A>Line2"
!! "Text=Line1%0D%0ALine2"
!! "Text=Line1%0A%0DLine2"
Hoehrmann Expires March 24, 2007 [Page 7]
Internet-Draft application/www-form-urlencoded format September 2006
Character outside the reportoire that can be encoded using US-ASCII
typically do not have to be escaped. As with newlines, the encoding
and decoding algorithms do not normalize or otherwise change the
content.
(("Chevron3", "Bo<U+00F6>tes"))
== "Chevron3=Bo<U+00F6>tes"
~~ "Chevron3=Bo%C3%B6tes"
!! "Chevron3=Boo<U+0308>tes"
The character U+0000 can occur in data sets and encoders and decoders
have to be prepared to handle them unless applications that employ
them gurantee otherwise. While escaped in the canonical encoding,
the character might also occur literally. It is incorrect so
truncate the data set at the first occurence of such a character.
(("Lookup", "<U+0000>,<U+2323>,<U+20AC>"))
== "Lookup=%00,<U+2323>,<U+20AC>"
~~ "Lookup=<U+0000>,<U+2323>,<U+20AC>"
!! "Lookup=,<U+2323>,<U+20AC>"
!! "Lookup="
The following example illustrates handling of percent-encoding by the
encoding and decoding algorithms. Certain sequences will never occur
in the canonical form, but the decoding algorithm is designed to be
highly robust and properly decode encoded data sets that contain them
anyway.
(("Cipher", "c=(m^e)%n"))
== "Cipher=c%3D(m%5Ee)%25n"
~~ "Cipher=c=(m%5Ee)%25n"
~~ "Cipher=c=(m^e)%n"
~~ "%43%69%70%68%65%72=%63%3d%28%6D%5E%65%29%25%6e"
!! "Cipher%3Dc%3D(m%5Ee)%25n"
!! "Cipher=c=(m^e)"
!! "Cipher=c"
The following six examples illustrate handling of empty name fields,
empty value fields, and undefined value fields. The special case
(("", undefined)) is not part of this list as it is the only data set
the encoding defined in this document cannot encode.
(("", undef), ("", undef)) == ";"
(("", undef), ("", "")) == ";="
(("", ""), ("", undef)) == "=;"
(("", ""), ("", "")) == "=;="
(("", undef)) == ""
(("", "")) == "="
Hoehrmann Expires March 24, 2007 [Page 8]
Internet-Draft application/www-form-urlencoded format September 2006
The separator characters ";" and "&" can both be used in encoded data
sets; they always separate pairs if not escaped, even if both of them
occur in a single string.
(("a&b", "1"), ("c", "2;3"), ("e", "4"))
== "a%26b=1;c=2%3B3;e=4"
~~ "a%26b=1&c=2%3B3&e=4"
~~ "a%26b=1;c=2%3B3&e=4"
~~ "a%26b=1&c=2%3B3;e=4"
!! "a&b=1;c=2%3B3;e=4"
!! "a%26b=1&c=2;3&e=4"
Applications may take advantage of the notion of undefined values in
encoded data sets; these are useful, for example, for boolean values,
to distinguish between empty strings and "null" values, or <isindex>
queries. For instance, a data set used to control columns in product
lists could look as follows. A more conventional way to encode the
same information would be, e.g., "c1=img&c2=avail&c3=name&c4=price".
(("img",undef), ("avail",undef), ("name",undef), ("price",undef))
== "img;avail;name;price"
The following examples do not conform to this specification, because
they use Unicode code points not suitable for use with the UTF-8
character encoding or because they contain sequences that do not
represent valid UTF-8 sequences.
* "Lookup=<U+DB40><U+DC7F>"
* "Lookup=%ED%AD%80%ED%B1%BF"
* "Lookup=%FE%83%9E%AB%9B%BB%AF"
* "Lookup=%C0%80"
* "Lookup=%C3"
* "Chevron3=Bo%F6tes"
6. Fragment identifiers
Fragment identifiers [RFC3987] of application/www-form-urlencoded
resources identify a subset of the data set encoded by the resource.
The characters '(', ')', and ',' are reserved and have to be escaped
unless they are used as described in this section.
Fragment identifiers that include '(' or ')' are reserved for future
versions of this specification and have undefined semantics. It is
incorrect to ignore or otherwise attempt to process them. The comma
separates names. The fragment identifier syntax is a comma-separated
list of names, encoded using the UTF-8 character encoding and percent
escaped as required by [RFC3986] or [RFC3987].
Hoehrmann Expires March 24, 2007 [Page 9]
Internet-Draft application/www-form-urlencoded format September 2006
Applications that generate fragment identifiers are encouraged to
avoid escaping of characters that do not need to be escaped. The
percent-encoding has to be reversed before the fragment identifier
can be processed succssfully.
The fragment identifier acts as a filter over the data set, only the
fields whose name matches a name in the list of names as encoded in
the fragment identifier are identified. The order of names in the
fragment identifier is insignificant, the original order is retained.
data:application/www-form-urlencoded,a=1;b;a=2;=3;d,;f#e,,a,%64%2C
Here the fragment identifier identifies the original data set with
all fields that are not named in the fragment identifier removed:
(("a", "1"), ("a", "2"), ("", "3"), ("d,", undefined))
Applications supporting this fragment identifier syntax are expected
to process the resource identifier given above essentially as if it
were the following:
data:application/www-form-urlencoded,a=1;a=2;=3;d,
Fragment identifiers including the character '(' or ')', for example,
<data:application/www-form-urlencoded,a=1;b;a=2;=3;d;f#value-of(a)>,
have undefined semantics as specified above.
7. Application-specific processing
This specification constrains the behavior of applications only in so
far as they act as encoders and decoders. It does not define a
protocol or other environment in which such processing takes place.
This section provides a few examples to illustrate the implications.
This specification does not define how applications obtain a list of
pairs suitable for application/www-form-urlencoded encoding. Such a
definition is considered part of the processing environment of the
application, and if such an environment fails to define the process,
applications trying to operate in the environment might fail to
interoperate.
This specification defines which data set conforming strings in a
non-canonical encoding correspond to. For some applications it might
be reasonable to assume that it will only have to process strings in
the canonical encoding and consider the occurence of non-canonical
strings to indicate a malfunction of the system and abort processing.
This specification considers the order of pairs significant, treats
Hoehrmann Expires March 24, 2007 [Page 10]
Internet-Draft application/www-form-urlencoded format September 2006
strings case-sensitively, and allows multiple pairs to use the same
name. Some applications might post-process the data set transforming
it into a set with unique uppercase names and use that for further
processing.
Applications will typically be able to understand only a limited set
of names and values, require them to be in a specific order, or place
other constraints on the data set. In consequence, such applications
might have to process data sets that do not meet the application's
constraints. This specification makes no attempt to define how such
applications should handle this kind of problem.
It is expected that specifications of processing environments taking
advantage of the format defined in this specification address their
respective interoperability needs by restricting application behavior
as needed and appropriate for their environment.
8. Compatibility considerations
Editorial note: This section is terrible. Replacements for this
section are very much welcome.
Most applications will have to be changed to take advantage of, or
achieve compatibility with, the format defined in this document; in
particular, applications encoding that sets and applications which
depend on intrinsic knowledge of this format's media type require
updating. This section discusses differences between the format
defined in this document and application/x-www-form-urlencoded by
means of the following HTML form.
<form method='get' action='/t'
enctype='application/www-form-urlencoded'>
<p><input name='url'
value='http://example.org/Ragnarök/' /></p>
<p><input name='lang' value='de' /></p>
<p><input type='submit' /></p>
</form>
Submitting this form will result in a request as follows. Note that
the character U+00F6 has been escaped only due to limitations of the
underlying protocol.
GET /t?url=http://example.org/Ragnar%C3%B6k/;lang=de HTTP/1.1
...
Using method='post' instead, the request would be as follows. Note
that in this case the character U+00F6 is not escaped but represented
as sequence of octets in the UTF-8 character encoding as in this case
Hoehrmann Expires March 24, 2007 [Page 11]
Internet-Draft application/www-form-urlencoded format September 2006
the format is not constrained by the protocol.
POST /t HTTP/1.1
Content-Type: application/www-form-urlencoded
...
url=http://example.org/Ragnar<C3><B6>k/;lang=de
Using the legacy format application/x-www-form-urlencoded instead
would result in the following requests for method='get' and 'post'
respectively. Note that it is being assumed that here, too, the
UTF-8 character encoding is used when encoding the data set. Many
existing applications use some other encoding; such applications are
considered out of scope of this section.
GET /t?url=http%3A%2F%2Fexample.org%2FRagnar%C3%B6k%2F&lang=de ...
...
and
POST /t HTTP/1.1
Content-Type: application/x-www-form-urlencoded
...
url=http%3A%2F%2Fexample.org%2FRagnar%C3%B6k%2F&lang=de
The HTML specification recommends that HTML implementations ignore
the enctype='application/www-form-urlencoded' attribute specified in
the example form above when they do not understand the value.
Implementations that follow this recommendation will then use the
default value enctype='application/x-www-form-urlencoded' when
submitting the form data set. As such, applications will typically
have to handle both formats.
The decoding algorithm defined in this specification can properly
decode any UTF-8-based application/x-www-form-urlencoded encoded data
set and as such, if the 't' script can handle the form as specified
above, it will also be able to handle submissions from HTML
implementations lacking proper application/www-form-urlencoded
support, with one caveat: if method='post' is used, it will also have
to recognize the application/x-www-form-urlencoded media type.
The 't' script might also have been designed for use with the legacy
application/x-www-form-urlencoded format; in this case, the script
would have to be able to accept characters like '/' and ':' in their
unescaped form, accept ';' as separator, and in case of POST, accept
the application/www-form-urlencoded media type.
Such applications typically have no problems handling unescaped
characters; accepting ';' as separator character is recommended by
Hoehrmann Expires March 24, 2007 [Page 12]
Internet-Draft application/www-form-urlencoded format September 2006
the HTML specification and many applications either follow this
recommendation or can easily be configured to do so. Applications
will typically not be able to recognize the new media type, and as
such using the 'POST' method is unlikely to work with such legacy
applications.
9. Security considerations
None not already inherent to the processing of the UTF-8 character
encoding [RFC3629] and the handling of percent-encoded sequences
[RFC3986]. Depending on how the format defined in this document is
being used, the security considerations of the aforementioned RFCs,
[RFC3987], and [RFC3875] might inform security decisions.
10. IANA Considerations
This document registers a new media type as defined in the following
section.
11. Media type registration
Type name: application
Subtype name: www-form-urlencoded
Required parameters: none
Optional parameters: none
Note: The media type does not have a 'charset' parameter, it
is incorrect specify one and to associate any significance to
it if specified. The character encoding is always UTF-8. The
Unicode encoding form signature is not supported; a leading
U+FEFF character will be considered part of a <name>.
Encoding considerations: 8bit
Security considerations: See section 9.
Interoperability considerations:
None, except as noted in other sections of this document.
Published specification: RFC XXXX
Applications that use this media type:
Systems that interchange data sets of name-value pairs.
Additional information:
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): TEXT
Fragment identifiers: See section 6.
Hoehrmann Expires March 24, 2007 [Page 13]
Internet-Draft application/www-form-urlencoded format September 2006
Person & email address to contact for further information:
See Author's Address section.
Intended usage: COMMON
Restrictions on usage: n/a
Author: See Author's Address section.
Change controller: The IESG.
12. References
12.1. Normative References
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005.
12.2. Informative References
[RFC1866] Berners-Lee, T. and D. Connolly, "Hypertext Markup
Language - 2.0", RFC 1866, November 1995.
[RFC3875] Robinson, D. and K. Coar, "The Common Gateway Interface
(CGI) Version 1.1", RFC 3875, October 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
Author's Address
Bjoern Hoehrmann
Weinheimer Strasse 22
Mannheim D-68309
Germany
EMail: mailto:bjoern@hoehrmann.de
URI: http://bjoern.hoehrmann.de
Hoehrmann Expires March 24, 2007 [Page 14]
Internet-Draft application/www-form-urlencoded format September 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Hoehrmann Expires March 24, 2007 [Page 15]