add sabre (1.8.x) via composer in the !@#$ place it wants to be

1 files changed, 1459 insertions, 0 deletions

diff --git a/vendor/sabre/dav/docs/rfc4790.txt b/vendor/sabre/dav/docs/rfc4790.txt
new file mode 100644
index 000000000..d58191c09
--- /dev/null
+++ b/vendor/sabre/dav/docs/rfc4790.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Network Working Group                                          C. Newman
+Request for Comments: 4790                              Sun Microsystems
+Category: Standards Track                                      M. Duerst
+                                                Aoyama Gakuin University
+                                                          A. Gulbrandsen
+                                                                    Oryx
+                                                              March 2007
+
+
+            Internet Application Protocol Collation Registry
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   Many Internet application protocols include string-based lookup,
+   searching, or sorting operations.  However, the problem space for
+   searching and sorting international strings is large, not fully
+   explored, and is outside the area of expertise for the Internet
+   Engineering Task Force (IETF).  Rather than attempt to solve such a
+   large problem, this specification creates an abstraction framework so
+   that application protocols can precisely identify a comparison
+   function, and the repertoire of comparison functions can be extended
+   in the future.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman, et al.              Standards Track                     [Page 1]
+
+RFC 4790                   Collation Registry                 March 2007
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.1.  Conventions Used in This Document  . . . . . . . . . . . .  4
+   2.  Collation Definition and Purpose . . . . . . . . . . . . . . .  4
+     2.1.  Definition . . . . . . . . . . . . . . . . . . . . . . . .  4
+     2.2.  Purpose  . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     2.3.  Some Other Terms Used in this Document . . . . . . . . . .  5
+     2.4.  Sort Keys  . . . . . . . . . . . . . . . . . . . . . . . .  5
+   3.  Collation Identifier Syntax  . . . . . . . . . . . . . . . . .  6
+     3.1.  Basic Syntax . . . . . . . . . . . . . . . . . . . . . . .  6
+     3.2.  Wildcards  . . . . . . . . . . . . . . . . . . . . . . . .  6
+     3.3.  Ordering Direction . . . . . . . . . . . . . . . . . . . .  7
+     3.4.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
+     3.5.  Naming Guidelines  . . . . . . . . . . . . . . . . . . . .  7
+   4.  Collation Specification Requirements . . . . . . . . . . . . .  8
+     4.1.  Collation/Server Interface . . . . . . . . . . . . . . . .  8
+     4.2.  Operations Supported . . . . . . . . . . . . . . . . . . .  8
+       4.2.1.  Validity . . . . . . . . . . . . . . . . . . . . . . .  9
+       4.2.2.  Equality . . . . . . . . . . . . . . . . . . . . . . .  9
+       4.2.3.  Substring  . . . . . . . . . . . . . . . . . . . . . .  9
+       4.2.4.  Ordering . . . . . . . . . . . . . . . . . . . . . . . 10
+     4.3.  Sort Keys  . . . . . . . . . . . . . . . . . . . . . . . . 10
+     4.4.  Use of Lookup Tables . . . . . . . . . . . . . . . . . . . 11
+   5.  Application Protocol Requirements  . . . . . . . . . . . . . . 11
+     5.1.  Character Encoding . . . . . . . . . . . . . . . . . . . . 11
+     5.2.  Operations . . . . . . . . . . . . . . . . . . . . . . . . 11
+     5.3.  Wildcards  . . . . . . . . . . . . . . . . . . . . . . . . 12
+     5.4.  String Comparison  . . . . . . . . . . . . . . . . . . . . 12
+     5.5.  Disconnected Clients . . . . . . . . . . . . . . . . . . . 12
+     5.6.  Error Codes  . . . . . . . . . . . . . . . . . . . . . . . 13
+     5.7.  Octet Collation  . . . . . . . . . . . . . . . . . . . . . 13
+   6.  Use by Existing Protocols  . . . . . . . . . . . . . . . . . . 13
+   7.  Collation Registration . . . . . . . . . . . . . . . . . . . . 14
+     7.1.  Collation Registration Procedure . . . . . . . . . . . . . 14
+     7.2.  Collation Registration Format  . . . . . . . . . . . . . . 15
+       7.2.1.  Registration Template  . . . . . . . . . . . . . . . . 15
+       7.2.2.  The Collation Element  . . . . . . . . . . . . . . . . 15
+       7.2.3.  The Identifier Element . . . . . . . . . . . . . . . . 16
+       7.2.4.  The Title Element  . . . . . . . . . . . . . . . . . . 16
+       7.2.5.  The Operations Element . . . . . . . . . . . . . . . . 16
+       7.2.6.  The Specification Element  . . . . . . . . . . . . . . 16
+       7.2.7.  The Submitter Element  . . . . . . . . . . . . . . . . 16
+       7.2.8.  The Owner Element  . . . . . . . . . . . . . . . . . . 16
+       7.2.9.  The Version Element  . . . . . . . . . . . . . . . . . 17
+       7.2.10. The Variable Element . . . . . . . . . . . . . . . . . 17
+     7.3.  Structure of Collation Registry  . . . . . . . . . . . . . 17
+     7.4.  Example Initial Registry Summary . . . . . . . . . . . . . 18
+
+
+
+Newman, et al.              Standards Track                     [Page 2]
+
+RFC 4790                   Collation Registry                 March 2007
+
+
+   8.  Guidelines for Expert Reviewer . . . . . . . . . . . . . . . . 18
+   9.  Initial Collations . . . . . . . . . . . . . . . . . . . . . . 19
+     9.1.  ASCII Numeric Collation  . . . . . . . . . . . . . . . . . 20
+       9.1.1.  ASCII Numeric Collation Description  . . . . . . . . . 20
+       9.1.2.  ASCII Numeric Collation Registration . . . . . . . . . 20
+     9.2.  ASCII Casemap Collation  . . . . . . . . . . . . . . . . . 21
+       9.2.1.  ASCII Casemap Collation Description  . . . . . . . . . 21
+       9.2.2.  ASCII Casemap Collation Registration . . . . . . . . . 22
+     9.3.  Octet Collation  . . . . . . . . . . . . . . . . . . . . . 22
+       9.3.1.  Octet Collation Description  . . . . . . . . . . . . . 22
+       9.3.2.  Octet Collation Registration . . . . . . . . . . . . . 23
+   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
+   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 23
+   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
+   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
+     13.1. Normative References . . . . . . . . . . . . . . . . . . . 24
+     13.2. Informative References . . . . . . . . . . . . . . . . . . 24
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman, et al.              Standards Track                     [Page 3]
+
+RFC 4790                   Collation Registry                 March 2007
+
+
+1.  Introduction
+
+   The Application Configuration Access Protocol ACAP [11] specification
+   introduced the concept of a comparator (which we call collation in
+   this document), but failed to create an IANA registry.  With the
+   introduction of stringprep [6] and the Unicode Collation Algorithm
+   [7], it is now time to create that registry and populate it with some
+   initial values appropriate for an international community.  This
+   specification replaces and generalizes the definition of a comparator
+   in ACAP, and creates a collation registry.
+
+1.1.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+   in this document are to be interpreted as defined in "Key words for
+   use in RFCs to Indicate Requirement Levels" [1].
+
+   The attribute syntax specifications use the Augmented Backus-Naur
+   Form (ABNF) [2] notation, including the core rules defined in
+   Appendix A.  The ABNF production "Language-tag" is imported from
+   Language Tags [5] and "reg-name" from URI: Generic Syntax [4].
+
+2.  Collation Definition and Purpose
+
+2.1.  Definition
+
+   A collation is a named function which takes two arbitrary length
+   strings as input and can be used to perform one or more of three
+   basic comparison operations: equality test, substring match, and
+   ordering test.
+
+2.2.  Purpose
+
+   Collations are an abstraction for comparison functions so that these
+   comparison functions can be used in multiple protocols.  The details
+   of a particular comparison operation can be specified by someone with
+   appropriate expertise, independent of the application protocols that
+   use that collation.  This is similar to the way a charset [13]
+   separates the details of octet to character mapping from a protocol
+   specification, such as MIME [9], or the way SASL [10] separates the
+   details of an authentication mechanism from a protocol specification,
+   such as ACAP [11].
+
+
+
+
+
+
+
+
+
+Newman, et al.              Standards Track                     [Page 4]
+
+RFC 4790                   Collation Registry                 March 2007
+
+
+   Here is a small diagram to help illustrate the value of this
+   abstraction:
+
+   +-------------------+                         +-----------------+
+   | IMAP i18n SEARCH  |--+                      | Basic           |
+   +-------------------+  |                   +--| Collation Spec  |
+                          |                   |  +-----------------+
+   +-------------------+  |  +-------------+  |  +-----------------+
+   | ACAP i18n SEARCH  |--+--| Collation   |--+--| A stringprep    |
+   +-------------------+  |  | Registry    |  |  | Collation Spec  |
+                          |  +-------------+  |  +-----------------+
+   +-------------------+  |                   |  +-----------------+
+   | ...other protocol |--+                   |  | locale-specific |
+   +-------------------+                      +--| Collation Spec  |
+                                                 +-----------------+
+
+   Thus IMAP, ACAP, and future application protocols with international
+   search capability simply specify how to interface to the collation
+   registry instead of each protocol specification having to specify all
+   the collations it supports.
+
+2.3.  Some Other Terms Used in this Document
+
+   The terms client, server, and protocol are used in somewhat unusual
+   senses.
+
+   Client means a user, or a program acting directly on behalf of a
+   user.  This may be a mail reader acting as an IMAP client, or it may
+   be an interactive shell, where the user can type protocol commands/
+   requests directly, or it may be a script or program written by the
+   user.
+
+   Server means a program that performs services requested by the
+   client.  This may be a traditional server such as an HTTP server, or
+   it may be a Sieve [14] interpreter running a Sieve script written by
+   a user.  A server needs to use the operations provided by collations
+   in order to fulfill the client's requests.
+
+   The protocol describes how the client tells the server what it wants
+   done, and (if applicable) how the server tells the client about the
+   results.  IMAP is a protocol by this definition, and so is the Sieve
+   language.
+
+2.4.  Sort Keys
+
+   One component of a collation is a transformation, which turns a
+   string into a sort key, which is then used while sorting.
+
+
+
+
+Newman, et al.              Standards Track                     [Page 5]
+
+RFC 4790                   Collation Registry                 March 2007
+
+
+   The transformation can range from an identity mapping (e.g., the
+   i;octet collation Section 9.3) to a mapping that makes the string
+   unreadable to a human.
+
+   This is an implementation detail of collations or servers.  A
+   protocol SHOULD NOT expose it to clients, since some collations leave
+   the sort key's format up to the implementation, and current
+   conformant implementations are known to use different formats.
+
+3.  Collation Identifier Syntax
+
+3.1.  Basic Syntax
+
+   The collation identifier itself is a single US-ASCII string.  The
+   identifier MUST NOT be longer than 254 characters, and obeys the
+   following grammar:
+
+     collation-char  = ALPHA / DIGIT / "-" / ";" / "=" / "."
+
+     collation-id    = collation-prefix ";" collation-core-name
+                       *collation-arg
+
+     collation-scope = Language-tag / "vnd-" reg-name
+
+     collation-core-name = ALPHA *( ALPHA / DIGIT / "-" )
+
+     collation-arg   = ";" ALPHA *( ALPHA / DIGIT ) "="
+                       1*( ALPHA / DIGIT / "." )
+
+
+   Note: the ABNF production "Language-tag" is imported from Language
+   Tags [5] and "reg-name" from URI: Generic Syntax [4].
+
+   There is a special identifier called "default".  For protocols that
+   have a default collation, "default" refers to that collation.  For
+   other protocols, the identifier "default" MUST match no collations,
+   and servers SHOULD treat it in the same way as they treat nonexistent
+   collations.
+
+3.2.  Wildcards
+
+   The string a client uses to select a collation MAY contain one or
+   more wildcard ("*") characters that match zero or more collation-
+   chars.  Wildcard characters MUST NOT be adjacent.  If the wildcard
+   string matches multiple collations, the server SHOULD attempt to
+   select a widely useful collation in preference to a narrowly useful
+   one.
+
+
+
+
+Newman, et al.              Standards Track                     [Page 6]
+
+RFC 4790                   Collation Registry                 March 2007
+
+
+     collation-wild  =  ("*" / (ALPHA ["*"])) *(collation-char ["*"])
+                         ; MUST NOT exceed 254 characters total
+
+3.3.  Ordering Direction
+
+   When used as a protocol element for ordering, the collation
+   identifier MAY be prefixed by either "+" or "-" to explicitly specify
+   an ordering direction. "+" has no effect on the ordering operation,
+   while "-" inverts the result of the ordering operation.  In general,
+   collation-order is used when a client requests a collation, and
+   collation-selected is used when the server informs the client of the
+   selected collation.
+
+     collation-selected =  ["+" / "-"] collation-id
+
+     collation-order =  ["+" / "-"] collation-wild
+
+3.4.  URIs
+
+   Some protocols are designed to use URIs [4] to refer to collations
+   rather than simple tokens.  A special section of the IANA URL space
+   is reserved for such usage.  The "collation-uri" form is used to
+   refer to a specific named collation (the collation registration may
+   not actually be present).  The "collation-auri" form is an abstract
+   name for an ordering, a collation pattern or a vendor private
+   collator.
+
+     collation-uri   =  "http://www.iana.org/assignments/collation/"
+                        collation-id ".xml"
+
+     collation-auri  =  ( "http://www.iana.org/assignments/collation/"
+                        collation-order ".xml" ) / other-uri
+
+     other-uri       =  <absoluteURI>
+                     ;  excluding the IANA collation namespace.
+
+3.5.  Naming Guidelines
+
+   While this specification makes no absolute requirements on the
+   structure of collation identifiers, naming consistency is important,
+   so the following initial guidelines are provided.
+
+   Collation identifiers with an international audience typically begin
+   with "i;".  Collation identifiers intended for a particular language
+   or locale typically begin with a language tag [5] followed by a ";".
+   After the first ";" is normally the name of the general collation
+   algorithm, followed by a series of algorithm modifications separated
+   by the ";" delimiter.  Parameterized modifications will use "=" to
+
+
+
+Newman, et al.              Standards Track                     [Page 7]
+
+RFC 4790                   Collation Registry                 March 2007
+
+
+   delimit the parameter from the value.  The version numbers of any
+   lookup tables used by the algorithm SHOULD be present as
+   parameterized modifications.
+
+   Collation identifiers of the form *;vnd-hostname;* are reserved for
+   vendor-specific collations created by the owner of the hostname
+   following the "vnd-" prefix (e.g., vnd-example.com for the vendor
+   example.com).  Registration of such collations (or the name space as
+   a whole), with intended use of the "Vendor", is encouraged when a
+   public specification or open-source implementation is available, but
+   is not required.
+
+4.  Collation Specification Requirements
+
+4.1.  Collation/Server Interface
+
+   The collation itself defines what it operates on.  Most collations
+   are expected to operate on character strings.  The i;octet
+   (Section 9.3) collation operates on octet strings.  The i;ascii-
+   numeric (Section 9.1) operation operates on numbers.
+
+   This specification defines the collation interface in terms of octet
+   strings.  However, implementations may choose to use character
+   strings instead.  Such implementations may not be able to implement
+   e.g., i;octet.  Since i;octet is not currently mandatory to implement
+   for any protocol, this should not be a problem.
+
+4.2.  Operations Supported
+
+   A collation specification MUST state which of the three basic
+   operations are supported (equality, substring, ordering) and how to
+   perform each of the supported operations on any two input character
+   strings, including empty strings.  Collations must be deterministic,
+   i.e., given a collation with a specific identifier, and any two fixed
+   input strings, the result MUST be the same for the same operation.
+
+   In general, collation operations should behave as their names
+   suggest.  While a collation may be new, the operations are not, so
+   the new collation's operations should be similar to those of older
+   collations.  For example, a date/time collation should not provide a
+   "substring" operation that would morph IMAP substring SEARCH into
+   e.g., a date-range search.
+
+   A non-obvious consequence of the rules for each collation operation
+   is that, for any single collation, either none or all of the
+   operations can return "undefined".  For example, it is not possible
+   to have an equality operation that never returns "undefined", and a
+   substring operation that occasionally does.
+
+
+
+Newman, et al.              Standards Track                     [Page 8]
+
+RFC 4790                   Collation Registry                 March 2007
+
+
+4.2.1.  Validity
+
+   The validity test takes one string as argument.  It returns valid if
+   its input string is a valid input to the collation's other
+   operations, and invalid if not.  (In other words, a string is valid
+   if it is equal to itself according to the collation's equality
+   operation.)
+
+   The validity test is provided by all collations.  It MUST NOT be
+   listed separately in the collation registration.
+
+4.2.2.  Equality
+
+   The equality test always returns "match" or "no-match" when it is
+   supplied valid input, and MAY return "undefined" if one or both input
+   strings are not valid.
+
+   The equality test MUST be reflexive and symmetric.  For valid input,
+   it MUST be transitive.
+
+   If a collation provides either a substring or an ordering test, it
+   MUST also provide an equality test.  The substring and/or ordering
+   tests MUST be consistent with the equality test.
+
+   The return values of the equality test are called "match", "no-match"
+   and "undefined" in this document.
+
+4.2.3.  Substring
+
+   The substring matching operation determines if the first string is a
+   substring of the second string, i.e., if one or more substrings of
+   the second string is equal to the first, as defined by the
+   collation's equality operation.
+
+   A collation that supports substring matching will automatically
+   support two special cases of substring matching: prefix and suffix
+   matching, if those special cases are supported by the application
+   protocol.  It returns "match" or "no-match" when it is supplied valid
+   input and returns "undefined" when supplied invalid input.
+
+   Application protocols MAY return position information for substring
+   matches.  If this is done, the position information SHOULD include
+   both the starting offset and the ending offset for each match.  This
+   is important because more sophisticated collations can match strings
+   of unequal length (for example, a pre-composed accented character can
+   match a decomposed accented character).  In general, overlapping
+   matches SHOULD be reported (as when "ana" occurs twice within
+   "banana"), although there are cases where a collation may decide not
+
+
+
+Newman, et al.              Standards Track                     [Page 9]
+
+RFC 4790                   Collation Registry                 March 2007
+
+
+   to.  For example, in a collation which treats all whitespace
+   sequences as identical, the substring operation could be defined such
+   that " 1 " (SP "1" SP) is reported just once within "  1  " (SP SP
+   "1" SP SP), not four times (SP SP "1" SP, SP "1" SP, SP "1" SP SP and
+   SP SP "1" SP SP), since the four matches are, in a sense, the same
+   match.
+
+   A string is a substring of itself.  The empty string is a substring
+   of all strings.
+
+   Note that the substring operation of some collations can match
+   strings of unequal length.  For example, a pre-composed accented
+   character can match a decomposed accented character.  The Unicode
+   Collation Algorithm [7] discusses this in more detail.
+
+   The return values of the substring operation are called "match", "no-
+   match", and "undefined" in this document.
+
+4.2.4.  Ordering
+
+   The ordering operation determines how two strings are ordered.  It
+   MUST be reflexive.  For valid input, it MUST be transitive and
+   trichotomous.
+
+   Ordering returns "less" if the first string is listed before the
+   second string, according to the collation; "greater", if the second
+   string is listed before the first string; and "equal", if the two
+   strings are equal, as defined by the collation's equality operation.
+   If one or both strings are invalid, the result of ordering is
+   "undefined".
+
+   When the collation is used with a "+" prefix, the behavior is the
+   same as when used with no prefix.  When the collation is used with a
+   "-" prefix, the result of the ordering operation of the collation
+   MUST be reversed.
+
+   The return values of the ordering operation are called "less",
+   "equal", "greater", and "undefined" in this document.
+
+4.3.  Sort Keys
+
+   A collation specification SHOULD describe the internal transformation
+   algorithm to generate sort keys.  This algorithm can be applied to
+   individual strings, and the result can be stored to potentially
+   optimize future comparison operations.  A collation MAY specify that
+   the sort key is generated by the identity function.  The sort key may
+   have no meaning to a human.  The sort key may not be valid input to
+   the collation.
+
+
+
+Newman, et al.              Standards Track                    [Page 10]
+
+RFC 4790                   Collation Registry                 March 2007
+
+
+4.4.  Use of Lookup Tables
+
+   Some collations use customizable lookup tables, e.g., because the
+   tables depend on locale, and may be modified after shipping the
+   software.  Collations that use more than one customizable lookup
+   table in a documented format MUST assign numbers to the tables they
+   use.  This permits an application protocol command to access the
+   tables used by a server collation, so that clients and servers use
+   the same tables.
+
+5.  Application Protocol Requirements
+
+   This section describes the requirements and issues that an
+   application protocol needs to consider if it offers searching,
+   substring matching and/or sorting, and permits the use of characters
+   outside the US-ASCII charset.
+
+5.1.  Character Encoding
+
+   The protocol specification has to make sure that it is clear on which
+   characters (rather than just octets) the collations are used.  This
+   can be done by specifying the protocol itself in terms of characters
+   (e.g., in the case of a query language), by specifying a single
+   character encoding for the protocol (e.g., UTF-8 [3]), or by
+   carefully describing the relevant issues of character encoding
+   labeling and conversion.  In the later case, details to consider
+   include how to handle unknown charsets, any charsets that are
+   mandatory-to-implement, any issues with byte-order that might apply,
+   and any transfer encodings that need to be supported.
+
+5.2.  Operations
+
+   The protocol must specify which of the operations defined in this
+   specification (equality matching, substring matching, and ordering)
+   can be invoked in the protocol, and how they are invoked.  There may
+   be more than one way to invoke an operation.
+
+   The protocol MUST provide a mechanism for the client to select the
+   collation to use with equality matching, substring matching, and
+   ordering.
+
+   If a protocol needs a total ordering and the collation chosen does
+   not provide it because the ordering operation returns "undefined" at
+   least once, the recommended fallback is to sort all invalid strings
+   after the valid ones, and use i;octet to order the invalid strings.
+
+   Although the collation's substring function provides a list of
+   matches, a protocol need not provide all that to the client.  It may
+
+
+
+Newman, et al.              Standards Track                    [Page 11]
+
+RFC 4790                   Collation Registry                 March 2007
+
+
+   provide only the first matching substring, or even just the
+   information that the substring search matched.  In this way,
+   collations can be used with protocols that are defined such that "x
+   is a substring of y" returns true-false.
+
+   If the protocol provides positional information for the results of a
+   substring match, that positional information SHOULD fully specify the
+   substring(s) in the result that matches, independent of the length of
+   the search string.  For example, returning both the starting and
+   ending offset of the match would suffice, as would the starting
+   offset and a length.  Returning just the starting offset is not
+   acceptable.  This rule is necessary because advanced collations can
+   treat strings of different lengths as equal (for example, pre-
+   composed and decomposed accented characters).
+
+5.3.  Wildcards
+
+   The protocol MUST specify whether it allows the use of wildcards in
+   collation identifiers.  If the protocol allows wildcards, then:
+      The protocol MUST specify how comparisons behave in the absence of
+      explicit collation negotiation, or when a collation of "default"
+      is requested.  The protocol MAY specify that the default collation
+      used in such circumstances is sensitive to server configuration.
+
+      The protocol SHOULD provide a way to list available collations
+      matching a given wildcard pattern, or patterns.
+
+5.4.  String Comparison
+
+   If a protocol compares strings in any nontrivial way, using a
+   collation may be appropriate.  As an example, many protocols use
+   case-independent strings.  In many cases, a simple ASCII mapping to
+   upper/lower case works well.  In other cases, it may be better to use
+   a specifiable collation; for example, so that a server can treat "i"
+   and "I" as equivalent in Italy, and different in Turkey (Turkish also
+   has a dotted upper-case" I" and a dotless lower-case "i").
+
+   Protocol designers should consider, in each case, whether to use a
+   specifiable collation.  Keywords often have other needs than user
+   variables, and search arguments may be different again.
+
+5.5.  Disconnected Clients
+
+   If the protocol supports disconnected clients, and a collation is
+   used that can use configurable tables (e.g., to support
+   locale-specific extensions), then the client may not be able to
+   reproduce the server's collation operations while offline.
+
+
+
+
+Newman, et al.              Standards Track                    [Page 12]
+
+RFC 4790                   Collation Registry                 March 2007
+
+
+   A mechanism to download such tables has been discussed.  Such a
+   mechanism is not included in the present specification, since the
+   problem is not yet well understood.
+
+5.6.  Error Codes
+
+   The protocol specification should consider assigning protocol error
+   codes for the following circumstances:
+
+   o  The client requests the use of a collation by identifier or
+      pattern, but no implemented collation matches that pattern.
+
+   o  The client attempts to use a collation for an operation that is
+      not supported by that collation -- for example, attempting to use
+      the "i;ascii-numeric" collation for substring matching.
+
+   o  The client uses an equality or substring matching collation, and
+      the result is an error.  It may be appropriate to distinguish
+      between the two input strings, particularly when one is supplied
+      by the client and the other is stored by the server.  It might
+      also be appropriate to distinguish the specific case of an invalid
+      UTF-8 string.
+
+5.7.  Octet Collation
+
+   The i;octet (Section 9.3) collation is only usable with protocols
+   based on octet-strings.  Clients and servers MUST NOT use i;octet
+   with other protocols.
+
+   If the protocol permits the use of collations with data structures
+   other than strings, the protocol MUST describe the default behavior
+   for a collation with those data structures.
+
+6.  Use by Existing Protocols
+
+   This section is informative.
+
+   Both ACAP [11] and Sieve [14] are standards track specifications that
+   used collations prior to the creation of this specification and
+   registry.  Those standards do not meet all the application protocol
+   requirements described in Section 5.
+
+   These protocols allow the use of the i;octet (Section 9.3) collation
+   working directly on UTF-8 data, as used in these protocols.
+
+
+
+
+
+
+
+Newman, et al.              Standards Track                    [Page 13]
+
+RFC 4790                   Collation Registry                 March 2007
+
+
+   In Sieve, all matches are either true or false.  Accordingly, Sieve
+   servers must treat "undefined" and "no-match" results of the equality
+   and substring operations as false, and only "match" as true.
+
+   In ACAP and Sieve, there are no invalid strings.  In this document's
+   terms, invalid strings sort after valid strings.
+
+   IMAP [15] also collates, although that is explicit only when the
+   COMPARATOR [17] extension is used.  The built-in IMAP substring
+   operation and the ordering provided by the SORT [16] extension may
+   not meet the requirements made in this document.
+
+   Other protocols may be in a similar position.
+
+   In IMAP, the default collation is i;ascii-casemap, because its
+   operations are understood to match IMAP's built-in operations.
+
+7.  Collation Registration
+
+7.1.  Collation Registration Procedure
+
+   The IETF will create a mailing list, collation@ietf.org, which can be
+   used for public discussion of collation proposals prior to
+   registration.  Use of the mailing list is strongly encouraged.  The
+   IESG will appoint a designated expert who will monitor the
+   collation@ietf.org mailing list and review registrations.
+
+   The registration procedure begins when a completed registration
+   template is sent to iana@iana.org and collation@ietf.org.  The
+   designated expert is expected to tell IANA and the submitter of the
+   registration within two weeks whether the registration is approved,
+   approved with minor changes, or rejected with cause.  When a
+   registration is rejected with cause, it can be re-submitted if the
+   concerns listed in the cause are addressed.  Decisions made by the
+   designated expert can be appealed to the IESG Applications Area
+   Director, then to the IESG.  They follow the normal appeals procedure
+   for IESG decisions.
+
+   Collation registrations in a standards track, BCP, or IESG-approved
+   experimental RFC are owned by the IETF, and changes to the
+   registration follow normal procedures for updating such documents.
+   Collation registrations in other RFCs are owned by the RFC author(s).
+   Other collation registrations are owned by the individual(s) listed
+   in the contact field of the registration, and IANA will preserve this
+   information.
+
+   If the registration is a change of an existing collation, it MUST be
+   approved by the owner.  In the event the owner cannot be contacted
+
+
+
+Newman, et al.              Standards Track                    [Page 14]
+
+RFC 4790                   Collation Registry                 March 2007
+
+
+   for a period of one month, and the designated expert deems the change
+   necessary, the IESG MAY re-assign ownership to an appropriate party.
+
+7.2.  Collation Registration Format
+
+   Registration of a collation is done by sending a well-formed XML
+   document to collation@ietf.org and iana@iana.org.
+
+7.2.1.  Registration Template
+
+   Here is a template for the registration:
+
+   <?xml version='1.0'?>
+   <!DOCTYPE collation SYSTEM 'collationreg.dtd'>
+   <collation rfc="YYYY" scope="global" intendedUse="common">
+     <identifier>collation identifier</identifier>
+     <title>technical title for collation</title>
+     <operations>equality order substring</operations>
+     <specification>specification reference</specification>
+     <owner>email address of owner or IETF</owner>
+     <submitter>email address of submitter</submitter>
+     <version>1</version>
+   </collation>
+
+7.2.2.  The Collation Element
+
+   The root of the registration document MUST be a <collation> element.
+   The collation element contains the other elements in the
+   registration, which are described in the following sub-subsections,
+   in the order given here.
+
+   The <collation> element MAY include an "rfc=" attribute if the
+   specification is in an RFC.  The "rfc=" attribute gives only the
+   number of the RFC, without any prefix, such as "RFC", or suffix, such
+   as ".txt".
+
+   The <collation> element MUST include a "scope=" attribute, which MUST
+   have one of the values "global", "local", or "other".
+
+   The <collation> element MUST include an "intendedUse=" attribute,
+   which must have one of the values "common", "limited", "vendor", or
+   "deprecated".  Collation specifications intended for "common" use are
+   expected to reference standards from standards bodies with
+   significant experience dealing with the details of international
+   character sets.
+
+   Be aware that future revisions of this specification may add
+   additional function types, as well as additional XML attributes,
+
+
+
+Newman, et al.              Standards Track                    [Page 15]
+
+RFC 4790                   Collation Registry                 March 2007
+
+
+   values, and elements.  Any system that automatically parses these XML
+   documents MUST take this into account to preserve future
+   compatibility.
+
+7.2.3.  The Identifier Element
+
+   The <identifier> element gives the precise identifier of the
+   collation, e.g., i;ascii-casemap.  The <identifier> element is
+   mandatory.
+
+7.2.4.  The Title Element
+
+   The <title> element gives the title of the collation.  The <title>
+   element is mandatory.
+
+7.2.5.  The Operations Element
+
+   The <operations> element lists which of the three operations
+   ("equality", "order" or "substring") the collation provides,
+   separated by single spaces.  The <operations> element is mandatory.
+
+7.2.6.  The Specification Element
+
+   The <specification> element describes where to find the
+   specification.  The <specification> element is mandatory.  It MAY
+   have a URI attribute.  There may be more than one <specification>
+   element, in which case, they together form the specification.
+
+   If it is discovered that parts of a collation specification conflict,
+   a new revision of the collation is necessary, and the
+   collation@ietf.org mailing list should be notified.
+
+7.2.7.  The Submitter Element
+
+   The <submitter> element provides an RFC 2822 [12] email address for
+   the person who submitted the registration.  It is optional if the
+   <owner> element contains an email address.
+
+   There may be more than one <submitter> element.
+
+7.2.8.  The Owner Element
+
+   The <owner> element contains either the four letters "IETF" or an
+   email address of the owner of the registration.  The <owner> element
+   is mandatory.  There may be more than one <owner> element.  If so,
+   all owners are equal.  Each owner can speak for all.
+
+
+
+
+
+Newman, et al.              Standards Track                    [Page 16]
+
+RFC 4790                   Collation Registry                 March 2007
+
+
+7.2.9.  The Version Element
+
+   The <version> element MUST be included when the registration is
+   likely to be revised, or has been revised in such a way that the
+   results change for one or more input strings.  The <version> element
+   is optional.
+
+7.2.10.  The Variable Element
+
+   The <variable> element specifies an optional variable to control the
+   collation's behaviour, for example whether it is case sensitive.  The
+   <variable> element is optional.  When <variable> is used, it must
+   contain <name> and <default> elements, and it may contain one or more
+   <value> elements.
+
+7.2.10.1.  The Name Element
+
+   The <name> element specifies the name value of a variable.  The
+   <name> element is mandatory.
+
+7.2.10.2.  The Default Element
+
+   The <default> element specifies the default value of a variable.  The
+   <default> element is mandatory.
+
+7.2.10.3.  The Value Element
+
+   The <value> element specifies a legal value of a variable.  The
+   <value> element is optional.  If one or more <value> elements are
+   present, only those values are legal.  If none are, then the
+   variable's legal values do not form an enumerated set, and the rules
+   MUST be specified in an RFC accompanying the registration.
+
+7.3.  Structure of Collation Registry
+
+   Once the registration is approved, IANA will store each XML
+   registration document in a URL of the form
+   http://www.iana.org/assignments/collation/collation-id.xml, where
+   collation-id is the content of the identifier element in the
+   registration.  Both the submitter and the designated expert are
+   responsible for verifying that the XML is well-formed.  The
+   registration document should avoid using new elements.  If any are
+   necessary, it is important to be consistent with other registrations.
+
+   IANA will also maintain a text summary of the registry under the name
+   http://www.iana.org/assignments/collation/collation-index.html.  This
+   summary is divided into four sections.  The first section is for
+   collations intended for common use.  This section is intended for
+
+
+
+Newman, et al.              Standards Track                    [Page 17]
+
+RFC 4790                   Collation Registry                 March 2007
+
+
+   collation registrations published in IESG-approved RFCs, or for
+   locally scoped collations from the primary standards body for that
+   locale.  The designated expert is encouraged to reject collation
+   registrations with an intended use of "common" if the expert believes
+   it should be "limited", as it is desirable to keep the number of
+   "common" registrations small and of high quality.  The second section
+   is reserved for limited-use collations.  The third section is
+   reserved for registered vendor-specific collations.  The final
+   section is reserved for deprecated collations.
+
+7.4.  Example Initial Registry Summary
+
+   The following is an example of how IANA might structure the initial
+   registry summary.html file:
+
+     Collation                              Functions Scope Reference
+     ---------                              --------- ----- ---------
+   Common Use Collations:
+     i;ascii-casemap                        e, o, s   Local [RFC 4790]
+
+   Limited Use Collations:
+     i;octet                                e, o, s   Other [RFC 4790]
+     i;ascii-numeric                        e, o      Other [RFC 4790]
+
+   Vendor Collations:
+
+   Deprecated Collations:
+
+
+   References
+   ----------
+   [RFC 4790]  Newman, C., Duerst, M., Gulbrandsen, A., "Internet
+               Application Protocol Collation Registry", RFC 4790,
+               Sun Microsystems, March 2007.
+
+8.  Guidelines for Expert Reviewer
+
+   The expert reviewer appointed by the IESG has fairly broad latitude
+   for this registry.  While a number of collations are expected
+   (particularly customizations of the UCA for localized use), an
+   explosion of collations (particularly common-use collations) is not
+   desirable for widespread interoperability.  However, it is important
+   for the expert reviewer to provide cause when rejecting a
+   registration, and, when possible, to describe corrective action to
+
+
+
+
+
+
+
+Newman, et al.              Standards Track                    [Page 18]
+
+RFC 4790                   Collation Registry                 March 2007
+
+
+   permit the registration to proceed.  The following table includes
+   some example reasons to reject a registration with cause:
+
+   o  The registration is not a well-formed XML document.
+
+   o  The registration has an intended use of "common", but there is no
+      evidence the collation will be widely deployed, so it should be
+      listed as "limited".
+
+   o  The registration has an intended use of "common", but it is
+      redundant with the functionality of a previously registered
+      "common" collation.
+
+   o  The registration has an intended use of "common", but the
+      specification is not detailed enough to allow interoperable
+      implementations by others.
+
+   o  The collation identifier fails to precisely identify the version
+      numbers of relevant tables to use.
+
+   o  The registration fails to meet one of the "MUST" requirements in
+      Section 4.
+
+   o  The collation identifier fails to meet the syntax in Section 3.
+
+   o  The collation specification referenced in the registration is
+      vague or has optional features without a clear behavior specified.
+
+   o  The referenced specification does not adequately address security
+      considerations specific to that collation.
+
+   o  The registration's operations are needlessly different from those
+      of traditional operations.
+
+   o  The registration's XML is needlessly different from that of
+      already registered collations.
+
+9.  Initial Collations
+
+   This section registers the three collations that were originally
+   defined in [11], and are implemented in most [14] engines.  Some of
+   the behavior of these collations is perhaps not ideal, such as
+   i;ascii-casemap accepting non-ASCII input.  Compatibility with widely
+   deployed code was judged more important than fixing the collations.
+   Some of the aspects of these collations are necessary to maintain
+   compatibility with widely deployed code.
+
+
+
+
+
+Newman, et al.              Standards Track                    [Page 19]
+
+RFC 4790                   Collation Registry                 March 2007
+
+
+9.1.  ASCII Numeric Collation
+
+9.1.1.  ASCII Numeric Collation Description
+
+   The "i;ascii-numeric" collation is a simple collation intended for
+   use with arbitrarily-sized, unsigned decimal integer numbers stored
+   as octet strings.  US-ASCII digits (0x30 to 0x39) represent digits of
+   the numbers.  Before converting from string to integer, the input
+   string is truncated at the first non-digit character.  All input is
+   valid; strings that do not start with a digit represent positive
+   infinity.
+
+   The collation supports equality and ordering, but does not support
+   the substring operation.
+
+   The equality operation returns "match" if the two strings represent
+   the same number (i.e., leading zeroes and trailing non-digits are
+   disregarded), and "no-match" if the two strings represent different
+   numbers.
+
+   The ordering operation returns "less" if the first string represents
+   a smaller number than the second, "equal" if they represent the same
+   number, and "greater" if the first string represents a larger number
+   than the second.
+
+   Some examples: "0" is less than "1", and "1" is less than
+   "4294967298". "4294967298", "04294967298", and "4294967298b" are all
+   equal. "04294967298" is less than "". "", "x", and "y" are equal.
+
+9.1.2.  ASCII Numeric Collation Registration
+
+   <?xml version='1.0'?>
+   <!DOCTYPE collation SYSTEM 'collationreg.dtd'>
+   <collation rfc="4790" scope="other" intendedUse="limited">
+     <identifier>i;ascii-numeric</identifier>
+     <title>ASCII Numeric</title>
+     <operations>equality order</operations>
+     <specification>RFC 4790</specification>
+     <owner>IETF</owner>
+     <submitter>chris.newman@sun.com</submitter>
+   </collation>
+
+
+
+
+
+
+
+
+
+
+Newman, et al.              Standards Track                    [Page 20]
+
+RFC 4790                   Collation Registry                 March 2007
+
+
+9.2.  ASCII Casemap Collation
+
+9.2.1.  ASCII Casemap Collation Description
+
+   The "i;ascii-casemap" collation is a simple collation that operates
+   on octet strings and treats US-ASCII letters case-insensitively.  It
+   provides equality, substring, and ordering operations.  All input is
+   valid.  Note that letters outside ASCII are not treated case-
+   insensitively.
+
+   Its equality, ordering, and substring operations are as for i;octet,
+   except that at first, the lower-case letters (octet values 97-122) in
+   each input string are changed to upper case (octet values 65-90).
+
+   Care should be taken when using OS-supplied functions to implement
+   this collation, as it is not locale sensitive.  Functions, such as
+   strcasecmp and toupper, are sometimes locale sensitive, and may
+   inappropriately map lower-case letters other than a-z to upper case.
+
+   The i;ascii-casemap collation is well-suited for use with many
+   Internet protocols and computer languages.  Use with natural language
+   is often inappropriate; even though the collation apparently supports
+   languages such as Swahili and English, in real-world use, it tends to
+   mis-sort a number of types of string:
+
+   o  people and place names containing non-ASCII,
+
+   o  words such as "naive" (if spelled with an accent, the accented
+      character could push the word to the wrong spot in a sorted list),
+
+   o  names such as "Lloyd" (which, in Welsh, sorts after "Lyon", unlike
+      in English),
+
+   o  strings containing euro and pound sterling symbols, quotation
+      marks other than '"', dashes/hyphens, etc.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman, et al.              Standards Track                    [Page 21]
+
+RFC 4790                   Collation Registry                 March 2007
+
+
+9.2.2.  ASCII Casemap Collation Registration
+
+   <?xml version='1.0'?>
+   <!DOCTYPE collation SYSTEM 'collationreg.dtd'>
+   <collation rfc="4790" scope="local" intendedUse="common">
+     <identifier>i;ascii-casemap</identifier>
+     <title>ASCII Casemap</title>
+     <operations>equality order substring</operations>
+     <specification>RFC 4790</specification>
+     <owner>IETF</owner>
+     <submitter>chris.newman@sun.com</submitter>
+   </collation>
+
+9.3.  Octet Collation
+
+9.3.1.  Octet Collation Description
+
+   The "i;octet" collation is a simple and fast collation intended for
+   use on binary octet strings rather than on character data.  Protocols
+   that want to make this collation available have to do so by
+   explicitly allowing it.  If not explicitly allowed, it MUST NOT be
+   used.  It never returns an "undefined" result.  It provides equality,
+   substring, and ordering operations.
+
+   The ordering algorithm is as follows:
+
+   1.  If both strings are the empty string, return the result "equal".
+
+   2.  If the first string is empty and the second is not, return the
+       result "less".
+
+   3.  If the second string is empty and the first is not, return the
+       result "greater".
+
+   4.  If both strings begin with the same octet value, remove the first
+       octet from both strings and repeat this algorithm from step 1.
+
+   5.  If the unsigned value (0 to 255) of the first octet of the first
+       string is less than the unsigned value of the first octet of the
+       second string, then return "less".
+
+   6.  If this step is reached, return "greater".
+
+   This algorithm is roughly equivalent to the C library function
+   memcmp, with appropriate length checks added.
+
+
+
+
+
+
+Newman, et al.              Standards Track                    [Page 22]
+
+RFC 4790                   Collation Registry                 March 2007
+
+
+   The matching operation returns "match" if the sorting algorithm would
+   return "equal".  Otherwise, the matching operation returns "no-
+   match".
+
+   The substring operation returns "match" if the first string is the
+   empty string, or if there exists a substring of the second string of
+   length equal to the length of the first string, which would result in
+   a "match" result from the equality function.  Otherwise, the
+   substring operation returns "no-match".
+
+9.3.2.  Octet Collation Registration
+
+   This collation is defined with intendedUse="limited" because it can
+   only be used by protocols that explicitly allow it.
+
+   <?xml version='1.0'?>
+   <!DOCTYPE collation SYSTEM 'collationreg.dtd'>
+   <collation rfc="4790" scope="global" intendedUse="limited">
+     <identifier>i;octet</identifier>
+     <title>Octet</title>
+     <operations>equality order substring</operations>
+     <specification>RFC 4790</specification>
+     <owner>IETF</owner>
+     <submitter>chris.newman@sun.com</submitter>
+   </collation>
+
+10.  IANA Considerations
+
+   Section 7 defines how to register collations with IANA.  Section 9
+   defines a list of predefined collations that have been registered
+   with IANA.
+
+11.  Security Considerations
+
+   Collations will normally be used with UTF-8 strings.  Thus, the
+   security considerations for UTF-8 [3], stringprep [6], and Unicode
+   TR-36 [8] also apply, and are normative to this specification.
+
+12.  Acknowledgements
+
+   The authors want to thank all who have contributed to this document,
+   including Brian Carpenter, John Cowan, Dave Cridland, Mark Davis,
+   Spencer Dawkins, Lisa Dusseault, Lars Eggert, Frank Ellermann, Philip
+   Guenther, Tony Hansen, Ted Hardie, Sam Hartman, Kjetil Torgrim Homme,
+   Michael Kay, John Klensin, Alexey Melnikov, Jim Melton, and Abhijit
+   Menon-Sen.
+
+
+
+
+
+Newman, et al.              Standards Track                    [Page 23]
+
+RFC 4790                   Collation Registry                 March 2007
+
+
+13.  References
+
+13.1.  Normative References
+
+   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
+         Specifications: ABNF", RFC 4234, October 2005.
+
+   [3]   Yergeau, F., "UTF-8, a transformation format of ISO 10646",
+         STD 63, RFC 3629, November 2003.
+
+   [4]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+         Resource Identifier (URI): Generic Syntax", RFC 3986,
+         January 2005.
+
+   [5]   Phillips, A. and M. Davis, "Tags for Identifying Languages",
+         BCP 47, RFC 4646, September 2006.
+
+   [6]   Hoffman, P. and M. Blanchet, "Preparation of Internationalized
+         Strings ("stringprep")", RFC 3454, December 2002.
+
+   [7]   Davis, M. and K. Whistler, "Unicode Collation Algorithm version
+         14", May 2005,
+         <http://www.unicode.org/reports/tr10/tr10-14.html>.
+
+   [8]   Davis, M. and M. Suignard, "Unicode Security Considerations",
+         February 2006, <http://www.unicode.org/reports/tr36/>.
+
+13.2.  Informative References
+
+   [9]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+         Extensions (MIME) Part One: Format of Internet Message Bodies",
+         RFC 2045, November 1996.
+
+   [10]  Melnikov, A., "Simple Authentication and Security Layer
+         (SASL)", RFC 4422, June 2006.
+
+   [11]  Newman, C. and J. Myers, "ACAP -- Application Configuration
+         Access Protocol", RFC 2244, November 1997.
+
+   [12]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.
+
+   [13]  Freed, N. and J. Postel, "IANA Charset Registration
+         Procedures", BCP 19, RFC 2978, October 2000.
+
+
+
+
+
+Newman, et al.              Standards Track                    [Page 24]
+
+RFC 4790                   Collation Registry                 March 2007
+
+
+   [14]  Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028,
+         January 2001.
+
+   [15]  Crispin, M., "Internet Message Access Protocol - Version
+         4rev1", RFC 3501, March 2003.
+
+   [16]  Crispin, M. and K. Murchison, "Internet Message Access Protocol
+         - Sort and Thread Extensions", Work in Progress, May 2004.
+
+   [17]  Newman, C. and A. Gulbrandsen, "Internet Message Access
+         Protocol Internationalization", Work in Progress, January 2006.
+
+Authors' Addresses
+
+   Chris Newman
+   Sun Microsystems
+   1050 Lakes Drive
+   West Covina, CA  91790
+   USA
+
+   EMail: chris.newman@sun.com
+
+
+   Martin Duerst
+   Aoyama Gakuin University
+   5-10-1 Fuchinobe
+   Sagamihara, Kanagawa  229-8558
+   Japan
+
+   Phone: +81 42 759 6329
+   Fax:   +81 42 759 6495
+   EMail: duerst@it.aoyama.ac.jp
+   URI:   http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/
+
+   Note: Please write "Duerst" with u-umlaut wherever possible, for
+   example as "D&#252;rst" in XML and HTML.
+
+
+   Arnt Gulbrandsen
+   Oryx Mail Systems GmbH
+   Schweppermannstr. 8
+   81671 Munich
+   Germany
+
+   Fax:   +49 89 4502 9758
+   EMail: arnt@oryx.com
+   URI:   http://www.oryx.com/arnt/
+
+
+
+
+Newman, et al.              Standards Track                    [Page 25]
+
+RFC 4790                   Collation Registry                 March 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Newman, et al.              Standards Track                    [Page 26]
+