Initial Alpine Version

3 files changed, 2044 insertions, 0 deletions

diff --git a/imap/docs/draft/README b/imap/docs/draft/README
new file mode 100644
index 00000000..9aec4719
--- /dev/null
+++ b/imap/docs/draft/README
@@ -0,0 +1,19 @@
+Last Updated: 6 March 2008
+
+This directory contains Internet Drafts which, at the time of release of
+this software, were not yet been published as RFCs.  These documents are
+expected to be released as RFCs in the near future.
+
+This software adheres to the specification in these documents, which
+are included for informational purposes.  Note, however, that these
+documents must be considered preliminary in nature and will be superceded
+by the successor RFC.
+
+File Name	I-D Name
+---------	--------
+sort.txt	draft-ietf-imapext-sort-20.txt
+		;; SORT and THREAD commands
+		;; Status: approved, blocked waiting for i18n
+
+i18n.txt	draft-ietf-imapext-i18n-15.txt
+		;; internationalization in IMAP
diff --git a/imap/docs/draft/i18n.txt b/imap/docs/draft/i18n.txt
new file mode 100644
index 00000000..f47c6cc7
--- /dev/null
+++ b/imap/docs/draft/i18n.txt
@@ -0,0 +1,1140 @@
+

+

+

+

+

+

+Network Working Group                                       Chris Newman

+Internet-Draft                                          Sun Microsystems

+Intended Status: Proposed Standard                      Arnt Gulbrandsen

+                                                  Oryx Mail Systems GmhH

+                                                         Alexey Melnikov

+                                                           Isode Limited

+                                                        February 1, 2008

+

+         Internet Message Access Protocol Internationalization

+                     draft-ietf-imapext-i18n-15.txt

+

+

+Status of this Memo

+    By submitting this Internet-Draft, each author represents that any

+    applicable patent or other IPR claims of which he or she is aware

+    have been or will be disclosed, and any of which he or she becomes

+    aware will be disclosed, in accordance with Section 6 of BCP 79.

+

+    Internet-Drafts are working documents of the Internet Engineering

+    Task Force (IETF), its areas, and its working groups.  Note that

+    other groups may also distribute working documents as Internet-

+    Drafts.

+

+    Internet-Drafts are draft documents valid for a maximum of six

+    months and may be updated, replaced, or obsoleted by other documents

+    at any time.  It is inappropriate to use Internet-Drafts as

+    reference material or to cite them other than as "work in progress".

+

+    The list of current Internet-Drafts can be accessed at

+    http://www.ietf.org/ietf/1id-abstracts.txt.  The list of Internet-

+    Draft Shadow Directories can be accessed at

+    http://www.ietf.org/shadow.html.

+

+    This Internet-Draft expires in August 2008.

+

+

+Copyright Notice

+

+    Copyright (C) The IETF Trust (2008).

+

+

+Abstract

+

+    Internet Message Access Protocol (IMAP) version 4rev1 has basic

+    support for non-ASCII characters in mailbox names and search

+    substrings.  It also supports non-ASCII message headers and content

+    encoded as specified by Multipurpose Internet Mail Extensions

+    (MIME).  This specification defines a collection of IMAP extensions

+

+

+

+Newman & Co                Expires August 2008                FF[Page 1]

+

+

+

+

+

+Internet-draft                                             February 2008

+

+

+    which improve international support including comparator negotiation

+    for search, sort and thread, language negotiation for international

+    error text, and translations for namespace prefixes.

+

+

+Table of Contents

+

+    1.  Conventions Used in this Document . . . . . . . . . . . . . .  2

+    2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  3

+    3.  LANGUAGE Extension  . . . . . . . . . . . . . . . . . . . . .  3

+    3.1 LANGUAGE Extension Requirements . . . . . . . . . . . . . . .  3

+    3.2 LANGUAGE Command  . . . . . . . . . . . . . . . . . . . . . .  4

+    3.3 LANGUAGE Response . . . . . . . . . . . . . . . . . . . . . .  6

+    3.4 TRANSLATION Extension to the NAMESPACE Response . . . . . . .  6

+    3.5 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .  6

+    4.  I18NLEVEL=1 and I18NLEVEL=2 Extensions  . . . . . . . . . . .  7

+    4.1 Introduction and Overview . . . . . . . . . . . . . . . . . .  8

+    4.2 Requirements common to both I18NLEVEL=1 and I18NLEVEL=2 . . .

+    4.3 I18NLEVEL=1 Extension Requirements  . . . . . . . . . . . . .  8

+    4.4 I18NLEVEL=2 Extension Requirements  . . . . . . . . . . . . .  8

+    4.5 Compatibility Notes

+    4.6 Comparators and Charsets  . . . . . . . . . . . . . . . . . .  9

+    4.7 COMPARATOR Command  . . . . . . . . . . . . . . . . . . . . .  9

+    4.8 COMPARATOR Response . . . . . . . . . . . . . . . . . . . . . 10

+    4.9 BADCOMPARATOR Response Code . . . . . . . . . . . . . . . . .

+    4.10 Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . 10

+    5.  Other IMAP Internationalization Issues  . . . . . . . . . . . 11

+    5.1 UTF-8 Userids and Passwords . . . . . . . . . . . . . . . . . 11

+    5.2 UTF-8 Mailbox Names . . . . . . . . . . . . . . . . . . . . . 11

+    5.3 UTF-8 Domains, Addresses and Mail Headers . . . . . . . . . . 11

+    6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12

+    7.  Security Considerations . . . . . . . . . . . . . . . . . . . 12

+    8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . 12

+    9.  Relevant Standards for i18n IMAP Implementations  . . . . . . 13

+        Normative References  . . . . . . . . . . . . . . . . . . . . 13

+        Informative References  . . . . . . . . . . . . . . . . . . . 14

+        Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . 15

+        Intellectual Property and Copyright Statements  . . . . . . . 16

+

+

+Conventions Used in This Document

+

+    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

+    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

+    document are to be interpreted as described in [RFC2119].

+

+    The formal syntax use the Augmented Backus-Naur Form (ABNF)

+    [RFC4234] notation including the core rules defined in Appendix A.

+

+

+

+Newman & Co                Expires August 2008                FF[Page 2]

+

+

+

+

+

+Internet-draft                                             February 2008

+

+

+    The UTF8-related productions are defined in [RFC3629].

+

+    In examples, "C:" and "S:" indicate lines sent by the client and

+    server respectively.  If a single "C:" or "S:" label applies to

+    multiple lines, then the line breaks between those lines are for

+    editorial clarity only and are not part of the actual protocol

+    exchange.

+

+

+2.  Introduction

+

+    This specification defines two IMAP4rev1 [RFC3501] extensions to

+    enhance international support.  These extensions can be advertised

+    and implemented separately.

+

+    The LANGUAGE extension allows the client to request a suitable

+    language for protocol error messages and in combination with the

+    NAMESPACE extension [RFC2342] enables namespace translations.

+

+    The I18NLEVEL=2 extension allows the client to request a suitable

+    collation which will modify the behavior of the base specification's

+    SEARCH command as well as the SORT and THREAD extensions [SORT].

+    This leverages the collation registry [RFC4790].

+

+

+3.  LANGUAGE Extension

+

+    IMAP allows server responses to include human-readable text that in

+    many cases needs to be presented to the user.  But that text is

+    limited to US-ASCII by the IMAP specification [RFC3501] in order to

+    preserve backwards compatibility with deployed IMAP implementations.

+    This section specifies a way for an IMAP client to negotiate which

+    language the server should use when sending human-readable text.

+

+    The LANGUAGE extension only provides a mechanism for altering fixed

+    server strings such as response text and NAMESPACE folder names.

+    Assigning localized language aliases to shared mailboxes would be

+    done with a separate mechanism such as the proposed METADATA

+    extension (see [METADATA]).

+

+

+3.1 LANGUAGE Extension Requirements

+

+    IMAP servers that support this extension MUST list the keyword

+    LANGUAGE in their CAPABILITY response as well as in the greeting

+    CAPABILITY data.

+

+    A server that advertises this extension MUST use the language "i-

+

+

+

+Newman & Co                Expires August 2008                FF[Page 3]

+

+

+

+

+

+Internet-draft                                             February 2008

+

+

+    default" as described in [RFC2277] as its default language until

+    another supported language is negotiated by the client. A server

+    MUST include "i-default" as one of its supported languages.

+

+    Clients and servers that support this extension MUST also support

+    the NAMESPACE extension [RFC2342].

+

+    The LANGUAGE command is valid in all states. Clients are urged to

+    issue LANGUAGE before authentication, since some servers send

+    valuable user information as part of authentication (e.g. "password

+    is correct, but expired").  If a security layer (such as SASL or

+    TLS) is subsequently negotiated by the client, it MUST re-issue the

+    LANGUAGE command in order to make sure that no previous active

+    attack (if any) on LANGUAGE negotiation has effect on subsequent

+    error messages. (See Section 7 for a more detailed explanation of

+    the attack.)

+

+

+

+3.2 LANGUAGE Command

+

+    Arguments: Optional language range arguments.

+

+    Response:  A possible LANGUAGE response (see section 3.3).

+               A possible NAMESPACE response (see section 3.4).

+

+    Result:    OK - Command completed

+               NO - Could not complete command

+               BAD - arguments invalid

+

+    The LANGUAGE command requests that human-readable text emitted by

+    the server be localized to a language matching one of the language

+    range argument as described by section 2 of [RFC4647].

+

+    If the command succeeds, the server will return human-readable

+    responses in the first supported language specified.  These

+    responses will be in UTF-8 [RFC3629].  The server MUST send a

+    LANGUAGE response specifying the language used, and the change takes

+    effect immediately after the LANGUAGE response.

+

+    If the command fails, the server continues to return human-readable

+    responses in the language it was previously using.

+

+    The special "default" language range argument indicates a request to

+    use a language designated as preferred by the server administrator.

+    The preferred language MAY vary based on the currently active user.

+

+    If a language range does not match a known language tag exactly but

+

+

+

+Newman & Co                Expires August 2008                FF[Page 4]

+

+

+

+

+

+Internet-draft                                             February 2008

+

+

+    does match a language by the rules of [RFC4647], the server MUST

+    send an untagged LANGUAGE response indicating the language selected.

+

+    If there aren't any arguments, the server SHOULD send an untagged

+    LANGUAGE response listing the languages it supports.  If the server

+    is unable to enumerate the list of languages it supports it MAY

+    return a tagged NO response to the enumeration request.

+

+        < The server defaults to using English i-default responses until

+          the user explicitly changes the language. >

+

+        C: A001 LOGIN KAREN PASSWORD

+        S: A001 OK LOGIN completed

+

+        < Client requested MUL language, which no server supports. >

+

+        C: A002 LANGUAGE MUL

+        S: A002 NO Unsupported language MUL

+

+        < A LANGUAGE command with no arguments is a request to enumerate

+          the list of languages the server supports. >

+

+        C: A003 LANGUAGE

+        S: * LANGUAGE (EN DE IT i-default)

+        S: A003 OK Supported languages have been enumerated

+

+        C: B001 LANGUAGE

+        S: B001 NO Server is unable to enumerate supported languages

+

+        < Once the client changes the language, all responses will be in

+          that language starting after the LANGUAGE response. Note that

+          this includes the NAMESPACE response. Because RFCs are in US-

+          ASCII, this document uses an ASCII transcription rather than

+          UTF-8 text, e.g. ue in the word "ausgefuehrt" >

+

+        C: C001 LANGUAGE DE

+        S: * LANGUAGE (DE)

+        S: * NAMESPACE (("" "/")) (("Other Users/" "/" "TRANSLATION"

+              ("Andere Ben&APw-tzer/"))) (("Public Folders/" "/"

+              "TRANSLATION" ("Gemeinsame Postf&AM8-cher/")))

+        S: C001 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt

+

+        < If a server does not support the requested primary language,

+          responses will continue to be returned in the current language

+          the server is using. >

+

+        C: D001 LANGUAGE FR

+        S: D001 NO Diese Sprache ist nicht unterstuetzt

+

+

+

+Newman & Co                Expires August 2008                FF[Page 5]

+

+

+

+

+

+Internet-draft                                             February 2008

+

+

+        C: D002 LANGUAGE DE-IT

+        S: * LANGUAGE (DE-IT)

+        S: * NAMESPACE (("" "/"))(("Other Users/" "/" "TRANSLATION"

+              ("Andere Ben&APw-tzer/"))) (("Public Folders/" "/"

+              "TRANSLATION" ("Gemeinsame Postf&AM8-cher/")))

+        S: D002 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt

+        C: D003 LANGUAGE "default"

+        S: * LANGUAGE (DE)

+        S: D003 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt

+

+        < Server does not speak French, but does speak English. User

+          speaks Canadian French and Canadian English. >

+

+        C: E001 LANGUAGE FR-CA EN-CA

+        S: * LANGUAGE (EN)

+        S: E001 OK Now speaking English

+

+

+

+3.3 LANGUAGE Response

+

+    Contents:  A list of one or more language tags.

+

+    The LANGUAGE response occurs as a result of a LANGUAGE command.  A

+    LANGUAGE response with a list containing a single language tag

+    indicates that the server is now using that language.  A LANGUAGE

+    response with a list containing multiple language tags indicates the

+    server is communicating a list of available languages to the client,

+    and no change in the active language has been made.

+

+

+3.4 TRANSLATION Extension to the NAMESPACE Response

+

+    If localized representations of the namespace prefixes are available

+    in the selected language, the server SHOULD include these in the

+    TRANSLATION extension to the NAMESPACE response.

+

+    The TRANSLATION extension to the NAMESPACE response returns a single

+    string, containing the modified UTF-7 [RFC3501] encoded translation

+    of the namespace prefix.  It is the responsibility of the client to

+    convert between the namespace prefix and the translation of the

+    namespace prefix when presenting mailbox names to the user.

+

+    In this example a server supports the IMAP4 NAMESPACE command. It

+    uses no prefix to the user's Personal Namespace, a prefix of "Other

+    Users" to its Other Users' Namespace and a prefix of "Public

+    Folders" to its only Shared Namespace.  Since a client will often

+    display these prefixes to the user, the server includes a

+

+

+

+Newman & Co                Expires August 2008                FF[Page 6]

+

+

+

+

+

+Internet-draft                                             February 2008

+

+

+    translation of them that can be presented to the user.

+

+        C: A001 LANGUAGE DE-IT

+        S: * NAMESPACE (("" "/")) (("Other Users/" "/" "TRANSLATION"

+              ("Andere Ben&APw-tzer/"))) (("Public Folders/" "/"

+              "TRANSLATION" ("Gemeinsame Postf&AM8-cher/")))

+        S: A001 OK LANGUAGE-Befehl ausgefuehrt

+

+

+3.5 Formal Syntax

+

+    The following syntax specification inherits ABNF [RFC4234] rules

+    from IMAP4rev1 [RFC3501], IMAP4 Namespace [RFC2342], Tags for the

+    Identifying Languages [RFC4646], UTF-8 [RFC3629] and Collected

+    Extensions to IMAP4 ABNF [RFC4466].

+

+    command-any     =/ language-cmd

+        ; LANGUAGE command is valid in all states

+

+    language-cmd    = "LANGUAGE" *(SP lang-range-quoted)

+

+    response-payload  =/ language-data

+

+    language-data     = "LANGUAGE" SP "(" lang-tag-quoted *(SP

+                      lang-tag-quoted) ")"

+

+    namespace-trans   = SP DQUOTE "TRANSLATION" DQUOTE SP "(" string ")"

+        ; the string is encoded in Modified UTF-7.

+        ; this is a subset of the syntax permitted by

+        ; the Namespace-Response-Extension rule in [RFC4466]

+

+    lang-range-quoted = astring

+        ; Once any literal wrapper or quoting is removed, this

+        ; follows the language-range rule in [RFC4647]

+

+    lang-tag-quoted = astring

+        ; Once any literal wrapper or quoting is removed, this follows

+        ; the Language-Tag rule in [RFC4646]

+

+    resp-text       = ["[" resp-text-code "]" SP ] UTF8-TEXT-CHAR

+                      *(UTF8-TEXT-CHAR / "[")

+        ; After the server is changed to a language other than

+        ; i-default, this resp-text rule replaces the resp-text

+        ; rule from [RFC3501].

+

+    UTF8-TEXT-CHAR  = %x20-5A / %x5C-7E / UTF8-2 / UTF8-3 / UTF8-4

+        ; UTF-8 excluding 7-bit control characters and "["

+

+

+

+

+Newman & Co                Expires August 2008                FF[Page 7]

+

+

+

+

+

+Internet-draft                                             February 2008

+

+

+4.  I18NLEVEL=1 and I18NLEVEL=2 Extensions

+

+

+4.1 Introduction and Overview

+

+    IMAP4rev1 [RFC3501] includes the SEARCH command which can be used to

+    locate messages matching criteria including human-readable text.

+    The SORT extension [SORT] to IMAP allows the client to ask the

+    server to determine the order of messages based on criteria

+    including human-readable text.  These mechanisms require the ability

+    to support non-English search and sort functions.

+

+    Section 4 defines two IMAP extensions for internationalizing IMAP

+    SEARCH, SORT and THREAD [SORT] using the comparator framework

+    [RFC4790].

+

+    The I18NLEVEL=1 extension updates SEARCH/SORT/THREAD to use

+    i;unicode-casemap comparator, as defined in [UCM]. See Sections 4.2

+    and 4.3 for more details.

+

+    The I18NLEVEL=2 extension is a superset of the I18NLEVEL=1

+    extension. It adds to I18NLEVEL=1 extension the ability to determine

+    the active comparator (see definition below) and negotiate use of

+    comparators using the COMPARATOR command. It also adds the

+    COMPARATOR response that indicates the active comparator and

+    possibly other available comparators. See Sections 4.2 and 4.4 for

+    more details.

+

+

+4.2 Requirements common to both I18NLEVEL=1 and I18NLEVEL=2

+

+    The term "default comparator" refers to the comparator which is used

+    by SEARCH and SORT absent any negotiation using the COMPARATOR (see

+    Section 4.7) command.  The term "active comparator" refers to the

+    comparator which will be used within a session e.g. by SEARCH and

+    SORT.  The COMPARATOR command is used to change the active

+    comparator.

+

+    The active comparator applies to the following SEARCH keys: "BCC",

+    "BODY", "CC", "FROM", "SUBJECT", "TEXT", "TO" and "HEADER".  If the

+    server also advertises the "SORT" extension, then the active

+    comparator applies to the following SORT keys: "CC", "FROM",

+    "SUBJECT" and "TO".  If the server advertises THREAD=ORDEREDSUBJECT,

+    then the active comparator applies to the ORDEREDSUBJECT threading

+    algorithm.  If the server advertises THREAD=REFERENCES, then the

+    active comparator applies to the subject field comparisons done by

+    REFERENCES threading algorithm.  Future extensions may choose to

+    apply the active comparator to their SEARCH keys.

+

+

+

+Newman & Co                Expires August 2008                FF[Page 8]

+

+

+

+

+

+Internet-draft                                             February 2008

+

+

+    For SORT and THREAD, the pre-processing necessary to extract the

+    base subject text from a Subject header occurs prior to the

+    application of a comparator.

+

+    A server that advertises I18NLEVEL=1 or I18NLEVEL=2 extension MUST

+    implement the i;unicode-casemap comparator, as defined in [UCM].

+

+    A server that advertises I18NLEVEL=1 or I18NLEVEL=2 extension MUST

+    support UTF-8 as a SEARCH charset.

+

+

+4.3 I18NLEVEL=1 Extension Requirements

+

+    An IMAP server that satisfies all requirements specified in sections

+    4.2 and 4.6 (and doesn't support/advertise any other I18NLEVEL=<n>

+    extension, where n > 1) MUST list the keyword I18NLEVEL=1 in its

+    CAPABILITY data once IMAP enters the authenticated state, and MAY

+    list that keyword in other states.

+

+

+

+4.4 I18NLEVEL=2 Extension Requirements

+

+    IMAP server that satisfies all requirements specified in sections

+    4.2, 4.4, 4.6-4.10 (and doesn't support/advertise any other

+    I18NLEVEL=<n> extension, where n > 2) MUST list the keyword

+    I18NLEVEL=2 in its CAPABILITY data once IMAP enters the

+    authenticated state, and MAY list that keyword in other states.

+

+    A server that advertises this extension MUST implement the

+    i;unicode-casemap comparator, as defined in [UCM]. It MAY implement

+    other comparators from the IANA registry established by [RFC4790].

+    See also section 4.5 of this document.

+

+    A server that advertises this extension SHOULD use i;unicode-casemap

+    as the default comparator. (Note that i;unicode-casemap is the

+    default comparator for I18NLEVEL=1, but not necessarily the default

+    for I18NLEVEL=2.) The selection of the default comparator MAY be

+    adjustable by the server administrator, and MAY be sensitive to the

+    current user.  Once the IMAP connection enters authenticated state,

+    the default comparator MUST remain static for the remainder of that

+    connection.

+

+    Note that since SEARCH uses the substring operation, IMAP servers

+    can only implement collations that offer the substring operation

+    (see [RFC4790 section 4.2.2). Since SORT uses ordering operation

+    (and by implication equality), IMAP servers which advertise the SORT

+    extension can only implement collations that offer all three

+

+

+

+Newman & Co                Expires August 2008                FF[Page 9]

+

+

+

+

+

+Internet-draft                                             February 2008

+

+

+    operations (see [RFC4790] sections 4.2.2-4).

+

+    If the active collation does not provide the operations needed by an

+    IMAP command, the server MUST respond with a tagged BAD.

+

+

+4.5 Compatibility Notes

+

+    Several server implementations deployed prior to the publication of

+    this specification comply with I18NLEVEL=1 (see section 4.3), but do

+    not advertise that.  Other legacy servers use the i;ascii-casemap

+    (see [RFC4790]) comparator.

+

+    There is no good way for a client to know which comparator that a

+    legacy server uses.  If the client has to assume the worst, it may

+    end up doing expensive local operations to obtain i;unicode-casemap

+    comparisons even though the server implements it.

+

+    Legacy server implementations which comply with I18NLEVEL=1 should

+    be updated to advertise I18NLEVEL=1.  All server implementations

+    should eventually be updated to comply with the I18NLEVEL=2

+    extension.

+

+

+4.6 Comparators and Character Encodings

+

+    RFC 3501, section 6.4.4 says:

+

+               In all search keys that use strings, a message matches

+               the key if the string is a substring of the field.  The

+               matching is case-insensitive.

+

+    When performing the SEARCH operation, the active comparator is

+    applied instead of the case-insensitive matching specified above.

+

+    An IMAP server which performs collation operations (e.g., as part of

+    commands such as SEARCH, SORT, THREAD) does so according to the

+    following procedure:

+

+    (a) MIME encoding (for example see [RFC2047] for headers and

+        [RFC2045] for body parts) MUST be removed in the texts being

+        collated.

+

+        If MIME encoding removal fails for a message (e.g., a body part

+        of the message has an unsupported Content-Transfer-Encoding,

+        uses characters not allowed by the Content-Transfer-Encoding,

+        etc.), the collation of this message is undefined by this

+        specification, and is handled in an implementation-dependent

+

+

+

+Newman & Co                Expires August 2008               FF[Page 10]

+

+

+

+

+

+Internet-draft                                             February 2008

+

+

+        manner.

+

+    (b) The decoded text from (a) MUST be converted to the charset

+        expected by the active comparator.

+

+    (c) For the substring operation:

+        If step (b) failed (e.g., the text is in an unknown charset,

+        contains a sequence which is not valid according in that

+        charset, etc.), the original decoded text from (a) (i.e.,

+        before the charset conversion attempt) is collated using the

+        i;octet comparator (see [RFC4790]).

+

+        If step (b) was successful, the converted text from (b) is

+        collated according to the active comparator.

+

+

+        For the ordering operation:

+

+        All strings that were successfully converted by step (b) are

+        separated from all strings that failed step (b). Strings in

+        each group are collated independently.  All strings successfully

+        converted by step (b) are then validated by the active

+        comparator. Strings that pass validation are collated using the

+        active comparator. All strings that either fail step (b) or fail

+        the active collation's validity operation are collated (after

+        applying step (a)) using the i;octet comparator (see [RFC4790]).

+        The resulting sorted list is produced by appending all collated

+        "failed" strings after all strings collated using the active

+        comparator.

+

+

+        Example: The following example demonstrates ordering of 4

+        different strings using i;unicode-casemap [UCM] comparator.

+        Strings are represented using hexadecimal notation used by

+        ABNF [RFC4234].

+

+        (1) %xD0 %xC0 %xD0 %xBD %xD0 %xB4 %xD1 %x80 %xD0 %xB5

+            %xD0 %xB9 (labeled with charset=UTF-8)

+        (2) %xD1 %x81 %xD0 %x95 %xD0 %xA0 %xD0 %x93 %xD0 %x95

+            %xD0 %x99 (labeled with charset=UTF-8)

+        (3) %xD0 %x92 %xD0 %xB0 %xD1 %x81 %xD0 %xB8 %xD0 %xBB

+            %xD0 %xB8 %xFF %xB9 (labeled with charset=UTF-8)

+        (4) %xE1 %xCC %xC5 %xCB %xD3 %xC5 %xCA (labeled with

+            charset=KOI8-R)

+

+        Step (b) will convert string # 4 to the following

+        sequence of octets (in UTF-8):

+

+

+

+

+Newman & Co                Expires August 2008               FF[Page 11]

+

+

+

+

+

+Internet-draft                                             February 2008

+

+

+        %xD0 %x90 %xD0 %xBB %xD0 %xB5 %xD0 %xBA %xD1 %x81 %xD0

+        %xB5 %xD0 %xB9

+

+        and will reject strings (1) and (3), as they contain

+        octets not allowed in charset=UTF-8.

+        After that, using the i;unicode-casemap collation,

+        string (4) will collate before string (2). Using the

+        i;octet collation on the original strings, string (3)

+        will collate before string (1). So the final ordering

+        is as follows: (4) (2) (3) (1).

+

+    If the substring operation (e.g., IMAP SEARCH) of the active

+    comparator returns the "undefined" result (see section 4.2.3 of

+    [RFC4790]) for either the text specified in the SEARCH command or

+    the message text, then the operation is repeated on the result of

+    step (a) using the i;octet comparator.

+

+    The ordering operation (e.g., IMAP SORT and THREAD) SHOULD collate

+    the following together: strings encoded using unknown or invalid

+    character encodings, strings in unrecognized charsets, and invalid

+    input (as defined by the active collation).

+

+

+

+4.7 COMPARATOR Command

+

+    Arguments: Optional comparator order arguments.

+

+    Response:  A possible COMPARATOR response (see Section 4.8).

+

+    Result:    OK - Command completed

+               NO - No matching comparator found

+               BAD - arguments invalid

+

+    The COMPARATOR command is valid in authenticated and selected

+    states.

+

+    The COMPARATOR command is used to determine or change the active

+    comparator.  When issued with no arguments, it results in a

+    COMPARATOR response indicating the currently active comparator.

+

+    When issued with one or more comparator argument, it changes the

+    active comparator as directed. (If more than one installed

+    comparator is matched by an argument, the first argument wins.) The

+    COMPARATOR response lists all matching comparators if more than one

+    matches the specified patterns.

+

+    The argument "default" refers to the server's default comparator.

+

+

+

+Newman & Co                Expires August 2008               FF[Page 12]

+

+

+

+

+

+Internet-draft                                             February 2008

+

+

+    Otherwise each argument is an collation specification as defined in

+    the Internet Application Protocol Comparator Registry [RFC4790].

+

+        < The client requests activating a Czech comparator if possible,

+          or else a generic international comparator which it considers

+          suitable for Czech. The server picks the first supported

+          comparator. >

+

+        C: A001 COMPARATOR "cz;*" i;basic

+        S: * COMPARATOR i;basic

+        S: A001 OK Will use i;basic for collation

+

+

+4.8 COMPARATOR Response

+

+    Contents:  The active comparator.

+               An optional list of available matching comparators

+

+    The COMPARATOR response occurs as a result of a COMPARATOR command.

+    The first argument in the comparator response is the name of the

+    active comparator.  The second argument is a list of comparators

+    which matched any of the arguments to the COMPARATOR command and is

+    present only if more than one match is found.

+

+

+4.9 BADCOMPARATOR response code

+

+    This response code SHOULD be returned as a result of server failing

+    an IMAP command (returning NO), when the server knows that none of

+    the specified comparators match the requested comparator(s).

+

+

+4.10 Formal Syntax

+

+    The following syntax specification inherits ABNF [RFC4234] rules

+    from IMAP4rev1 [RFC3501], and Internet Application Protocol

+    Comparator Registry [RFC4790].

+

+        command-auth      =/ comparator-cmd

+

+        resp-text-code    =/ "BADCOMPARATOR"

+

+        comparator-cmd    = "COMPARATOR" *(SP comp-order-quoted)

+

+      response-payload  =/ comparator-data

+

+        comparator-data   = "COMPARATOR" SP comp-sel-quoted [SP "("

+                        comp-id-quoted *(SP comp-id-quoted) ")"]

+

+

+

+Newman & Co                Expires August 2008               FF[Page 13]

+

+

+

+

+

+Internet-draft                                             February 2008

+

+

+        comp-id-quoted  = astring

+            ; Once any literal wrapper or quoting is removed, this

+            ; follows the collation-id rule from [RFC4790]

+

+        comp-order-quoted = astring

+            ; Once any literal wrapper or quoting is removed, this

+            ; follows the collation-order rule from [RFC4790]

+

+        comp-sel-quoted   = astring

+            ; Once any literal wrapper or quoting is removed, this

+            ; follows the collation-selected rule from [RFC4790]

+

+

+5.  Other IMAP Internationalization Issues

+

+    The following sections provide an overview of various other IMAP

+    internationalization issues.  These issues are not resolved by this

+    specification, but could be resolved by other standards work, such

+    as that being done by the EAI group (see [IMAP-EAI]).

+

+

+5.1 Unicode Userids and Passwords

+

+    IMAP4rev1 currently restricts the userid and password fields of the

+    LOGIN command to US-ASCII. The "userid" and "password" fields of the

+    IMAP LOGIN command are restricted to US-ASCII only until a future

+    standards track RFC states otherwise.  Servers are encouraged to

+    validate both fields to make sure they conform to the formal syntax

+    of UTF-8 and to reject the LOGIN command if that syntax is violated.

+    Servers MAY reject the use of any 8-bit in the "userid" or

+    "password" field.

+

+    When AUTHENTICATE is used, some servers may support userids and

+    passwords in Unicode [RFC3490] since SASL (see [RFC4422]) allows

+    that. However, such userids cannot be used as part of email

+    addresses.

+

+

+5.2 UTF-8 Mailbox Names

+

+    The modified UTF-7 mailbox naming convention described in section

+    5.1.3 of RFC 3501 is best viewed as an transition from the status

+    quo in 1996 when modified UTF-7 was first specified.  At that time,

+    there was widespread unofficial use of local character sets such as

+    ISO-8859-1 and Shift-JIS for non-ASCII mailbox names, with resultant

+    non-interoperability.

+

+    The requirements in section 5.1 of RFC 3501 are very important if

+

+

+

+Newman & Co                Expires August 2008               FF[Page 14]

+

+

+

+

+

+Internet-draft                                             February 2008

+

+

+    we're ever going to be able to deploy UTF-8 mailbox names. Servers

+    are encouraged to enforce them.

+

+

+5.3 UTF-8 Domains, Addresses and Mail Headers

+

+    There is now an IETF standard for Internationalizing Domain Names in

+    Applications [RFC3490].  While IMAP clients are free to support this

+    standard, an argument can be made that it would be helpful to simple

+    clients if the IMAP server could perform this conversion (the same

+    argument would apply to MIME header encoding [RFC2047]).  However,

+    it would be unwise to move forward with such work until the work in

+    progress to define the format of international email addresses is

+    complete.

+

+

+6.  IANA Considerations

+

+    The IANA is requested to add LANGUAGE, I18NLEVEL=1 and I18NLEVEL=2

+    to the IMAP4 Capabilities Registry.  [Note to IANA:

+    http://www.iana.org/assignments/imap4-capabilities]

+

+

+7.  Security Considerations

+

+    The LANGUAGE extension makes a new command available in "Not

+    Authenticated" state in IMAP.  Some IMAP implementations run with

+    root privilege when the server is in "Not Authenticated" state and

+    do not revoke that privilege until after authentication is complete.

+    Such implementations are particularly vulnerable to buffer overflow

+    security errors at this stage and need to implement parsing of this

+    command with extra care.

+

+    A LANGUAGE command issued prior to activation of a security layer is

+    subject to an active attack which suppresses or modifies the

+    negotiation and thus makes STARTTLS or authentication error messages

+    more difficult to interpret.  This is not a new attack as the error

+    messages themselves are subject to active attack.  Clients MUST re-

+    issue the LANGUAGE command once a security layer is active, so this

+    does not impact subsequent protocol operations.

+

+    LANGUAGE, I18NLEVEL=1 and I18NLEVEL=2 extensions use the UTF-8

+    charset, thus the security considerations for UTF-8 [RFC3629] are

+    relevent.  However, neither uses UTF-8 for identifiers so the most

+    serious concerns do not apply.

+

+

+8.  Acknowledgements

+

+

+

+Newman & Co                Expires August 2008               FF[Page 15]

+

+

+

+

+

+Internet-draft                                             February 2008

+

+

+    The LANGUAGE extension is based on a previous Internet draft by Mike

+    Gahrns, a substantial portion of the text in that section was

+    written by him.  Many people have participated in discussions about

+    an IMAP Language extension in the various fora of the IETF and

+    Internet working groups, so any list of contributors is bound to be

+    incomplete.  However, the authors would like to thank Andrew McCown

+    for early work on the original proposal, John Myers for suggestions

+    regarding the namespace issue, along with Jutta Degener, Mark

+    Crispin, Mark Pustilnik, Larry Osterman, Cyrus Daboo, Martin Duerst,

+    Timo Sirainen, Ben Campbell and Magnus Nystrom for their many

+    suggestions that have been incorporated into this document.

+

+    Initial discussion of the I18NLEVEL=2 extension involved input from

+    Mark Crispin and other participants of the IMAP Extensions WG.

+

+

+9.  Relevant Standards for i18n IMAP Implementations

+

+    This is a non-normative list of standards to consider when

+    implementing i18n aware IMAP software.

+

+      o The LANGUAGE and I18NLEVEL=2 extensions to IMAP (this

+        specification).

+      o The 8-bit rules for mailbox naming in section 5.1 of RFC 3501.

+      o The Mailbox International Naming Convention in section 5.1.3 of

+        RFC 3501.

+      o MIME [RFC2045] for message bodies.

+      o MIME header encoding [RFC2047] for message headers.

+      o The IETF EAI working group.

+      o MIME Parameter Value and Encoded Word Extensions [RFC2231] for

+        filenames.  Quality IMAP server implementations will

+        automatically combine multipart parameters when generating the

+        BODYSTRUCTURE. There is also some deployed non-standard use of

+        MIME header encoding inside double-quotes for filenames.

+      o IDNA [RFC3490] and punycode [RFC3492] for domain names

+        (currently only relevant to IMAP clients).

+      o The UTF-8 charset [RFC3629].

+      o The IETF policy on Character Sets and Languages [RFC2277].

+

+

+Normative References

+

+    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate

+               Requirement Levels", BCP 14, RFC 2119, March 1997.

+

+    [RFC2277]  Alvestrand, "IETF Policy on Character Sets and

+               Languages", BCP 18, RFC 2277, January 1998.

+

+

+

+

+Newman & Co                Expires August 2008               FF[Page 16]

+

+

+

+

+

+Internet-draft                                             February 2008

+

+

+    [RFC2342]  Gahrns, Newman, "IMAP4 Namespace", RFC 2342, May 1998.

+

+    [RFC3501]  Crispin, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION

+               4rev1", RFC 3501, March 2003.

+

+    [RFC3629]  Yergeau, "UTF-8, a transformation format of ISO 10646",

+               STD 63, RFC 3629, November 2003.

+

+    [RFC4234]  Crocker, Overell, "Augmented BNF for Syntax

+               Specifications: ABNF", RFC 4234, Brandenburg

+               Internetworking, Demon Internet Ltd, October 2005.

+

+    [RFC4422]  Melnikov, Zeilenga, "Simple Authentication and Security

+               Layer (SASL)", RFC 4422, June 2006.

+

+    [RFC4466]  Melnikov, Daboo, "Collected Extensions to IMAP4 ABNF",

+               RFC 4466, Isode Ltd., April 2006.

+

+    [RFC4646]  Philips, Davis, "Tags for Identifying Languages", BCP 47,

+               RFC 4646, September 2006.

+

+    [RFC4647]  Philips, Davis, "Matching of Language Tags", BCP 47, RFC

+               4647, September 2006.

+

+    [RFC4790]  Newman, Duerst, Gulbrandsen, "Internet Application

+               Protocol Comparator Registry", RFC 4790, February 2007.

+

+    [SORT]     Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS

+               PROTOCOL - SORT AND THREAD EXTENSION", draft-ietf-

+               imapext-sort-19 (work in progress), November 2006.

+

+    [UCM]      Crispin, "i;unicode-casemap - Simple Unicode Collation

+               Algorithm", RFC 5051, October 2007.

+

+    [RFC2045]  Freed, Borenstein, "Multipurpose Internet Mail Extensions

+               (MIME) Part One: Format of Internet Message Bodies", RFC

+               2045, November 1996.

+

+    [RFC2047]  Moore, "MIME (Multipurpose Internet Mail Extensions) Part

+               Three: Message Header Extensions for Non-ASCII Text", RFC

+               2047, November 1996.

+

+

+Informative References

+

+

+    [RFC2231]  Freed, Moore, "MIME Parameter Value and Encoded Word

+               Extensions: Character Sets, Languages, and

+

+

+

+Newman & Co                Expires August 2008               FF[Page 17]

+

+

+

+

+

+Internet-draft                                             February 2008

+

+

+               Continuations", RFC 2231, November 1997.

+

+    [RFC3490]  Faltstrom, Hoffman, Costello, "Internationalizing Domain

+               Names in Applications (IDNA)", RFC 3490, March 2003.

+

+    [RFC3492]  Costello, "Punycode: A Bootstring encoding of Unicode for

+               Internationalized Domain Names in Applications (IDNA)",

+               RFC 3492, March 2003.

+

+    [METADATA] Daboo, C., "IMAP METADATA Extension", draft-daboo-imap-

+               annotatemore-12 (work in progress), December 2007.

+

+    [IMAP-EAI] Resnick, Newman, "IMAP Support for UTF-8", draft-ietf-

+               eai-imap-utf8 (work in progress), May 2006.

+

+

+

+Authors' Addresses

+

+    Chris Newman

+    Sun Microsystems

+    3401 Centrelake Dr., Suite 410

+    Ontario, CA 91761

+    US

+

+    Email: chris.newman@sun.com

+

+

+    Arnt Gulbrandsen

+    Oryx Mail Systems GmbH

+    Schweppermannstr. 8

+    D-81671 Muenchen

+    Germany

+

+    Email: arnt@oryx.com

+

+    Fax: +49 89 4502 9758

+

+

+    Alexey Melnikov

+    Isode Limited

+    5 Castle Business Village, 36 Station Road,

+    Hampton, Middlesex, TW12 2BX, UK

+

+    Email: Alexey.Melnikov@isode.com

+

+

+

+

+

+

+Newman & Co                Expires August 2008               FF[Page 18]

+

+

+

+

+

+Internet-draft                                             February 2008

+

+

+Intellectual Property Statement

+

+    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.

+

+

+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.

+

+

+Acknowledgment

+

+    Funding for the RFC Editor function is currently provided by the

+    Internet Society.

+

+

+

+

+

+

+Newman & Co                Expires August 2008               FF[Page 19]

+

+

diff --git a/imap/docs/draft/sort.txt b/imap/docs/draft/sort.txt
new file mode 100644
index 00000000..4453bb4d
--- /dev/null
+++ b/imap/docs/draft/sort.txt
@@ -0,0 +1,885 @@
+IMAP Extensions Working Group                                 M. Crispin
+Internet-Draft                                              K. Murchison
+Intended status: Proposed Standard                        March 10, 2008
+Expires: September 10, 2008
+Document: internet-drafts/draft-ietf-imapext-sort-20.txt
+
+     INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS
+
+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.
+
+   A revised version of this draft document will be submitted to the RFC
+   editor as a Proposed Standard for the Internet Community.  Discussion
+   and suggestions for improvement are requested, and should be sent to
+   ietf-imapext@IMC.ORG.
+
+   Distribution of this memo is unlimited.
+
+Abstract
+
+   This document describes the base-level server-based sorting and
+   threading extensions to the [IMAP] protocol.  These extensions
+   provide substantial performance improvements for IMAP clients which
+   offer sorted and threaded views.
+
+1. Introduction
+
+   The SORT and THREAD extensions to the [IMAP] protocol provide a means
+   of server-based sorting and threading of messages, without requiring
+   that the client download the necessary data to do so itself.  This is
+   particularly useful for online clients as described in [IMAP-MODELS].
+
+   A server which supports the base-level SORT extension indicates this
+   with a capability name which starts with "SORT".  Future,
+   upwards-compatible extensions to the SORT extension will all start
+   with "SORT", indicating support for this base level.
+
+   A server which supports the THREAD extension indicates this with one
+   or more capability names consisting of "THREAD=" followed by a
+   supported threading algorithm name as described in this document.
+   This provides for future upwards-compatible extensions.
+
+   A server which implements the SORT and/or THREAD extensions MUST
+   collate strings in accordance with the requirements of I18NLEVEL=1,
+   as described in [IMAP-I18N], and SHOULD implement and advertise the
+   I18NLEVEL=1 extension.  Alternatively, a server MAY implement
+   I18NLEVEL=2 (or higher) and comply with the rules of that level.
+
+      Discussion: the SORT and THREAD extensions predate [IMAP-I18N] by
+      several years.  At the time of this writing, all known server
+      implementations of SORT and THREAD comply with the rules of
+      I18NLEVEL=1, but do not necessarily advertise it.  As discussed
+      in [IMAP-I18N] section 4.5, all server implementations should
+      eventually be updated to comply with the I18NLEVEL=2 extension.
+
+   Historical note: the REFERENCES threading algorithm is based on the
+   [THREADING] algorithm written used in "Netscape Mail and News"
+   versions 2.0 through 3.0.  
+
+2. 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 [KEYWORDS].
+
+   The word "can" (not "may") is used to refer to a possible
+   circumstance or situation, as opposed to an optional facility of the
+   protocol.
+
+   "User" is used to refer to a human user, whereas "client" refers to
+   the software being run by the user.
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.
+
+2.1 Base Subject
+
+   Subject sorting and threading use the "base subject," which has
+   specific subject artifacts removed.  Due to the complexity of these
+   artifacts, the formal syntax for the subject extraction rules is
+   ambiguous.  The following procedure is followed to determine the
+   "base subject", using the [ABNF] formal syntax rules described in
+   section 5:
+
+        (1) Convert any RFC 2047 encoded-words in the subject to
+        UTF-8 as described in "internationalization
+        considerations."  Convert all tabs and continuations to
+        space.  Convert all multiple spaces to a single space.
+
+        (2) Remove all trailing text of the subject that matches
+        the subj-trailer ABNF, repeat until no more matches are
+        possible.
+
+        (3) Remove all prefix text of the subject that matches the
+        subj-leader ABNF.
+
+        (4) If there is prefix text of the subject that matches the
+        subj-blob ABNF, and removing that prefix leaves a non-empty
+        subj-base, then remove the prefix text.
+
+        (5) Repeat (3) and (4) until no matches remain.
+
+   Note: it is possible to defer step (2) until step (6), but this
+   requires checking for subj-trailer in step (4).
+
+        (6) If the resulting text begins with the subj-fwd-hdr ABNF
+        and ends with the subj-fwd-trl ABNF, remove the
+        subj-fwd-hdr and subj-fwd-trl and repeat from step (2).
+
+        (7) The resulting text is the "base subject" used in the
+        SORT.
+
+   All servers and disconnected (as described in [IMAP-MODELS]) clients
+   MUST use exactly this algorithm to determine the "base subject".
+   Otherwise there is potential for a user to get inconsistent results
+   based on whether they are running in connected or disconnected mode.
+
+2.2 Sent Date
+
+   As used in this document, the term "sent date" refers to the date and
+   time from the Date: header, adjusted by time zone to normalize to
+   UTC.  For example, "31 Dec 2000 16:01:33 -0800" is equivalent to the
+   UTC date and time of "1 Jan 2001 00:01:33 +0000".
+
+   If the time zone is invalid, the date and time SHOULD be treated as
+   UTC.  If the time is also invalid, the time SHOULD be treated as
+   00:00:00.  If there is no valid date or time, the date and time
+   SHOULD be treated as 00:00:00 on the earliest possible date.
+
+   This differs from the date-related criteria in the SEARCH command
+   (described in [IMAP] section 6.4.4), which use just the date and not
+   the time, and are not adjusted by time zone.
+
+   If the sent date can not be determined (a Date: header is missing or
+   can not be parsed), the INTERNALDATE for that message is used as the
+   sent date.
+
+   When comparing two sent dates that match exactly, the order in which
+   the two messages appear in the mailbox (that is, by sequence number)
+   is used as a tie-breaker to determine the order.
+
+3. Additional Commands
+
+   These commands are extension to the [IMAP] base protocol.
+
+   The section headings are intended to correspond with where they would
+   be located in the main document if they were part of the base
+   specification.
+
+BASE.6.4.SORT. SORT Command
+
+   Arguments:  sort program
+               charset specification
+               searching criteria (one or more)
+
+   Data:       untagged responses: SORT
+
+   Result:     OK - sort completed
+               NO - sort error: can't sort that charset or
+                    criteria
+               BAD - command unknown or arguments invalid
+
+      The SORT command is a variant of SEARCH with sorting semantics for
+      the results.  Sort has two arguments before the searching criteria
+      argument; a parenthesized list of sort criteria, and the searching
+      charset.
+
+      The charset argument is mandatory (unlike SEARCH) and indicates
+      the [CHARSET] of the strings that appear in the searching
+      criteria.  The US-ASCII and UTF-8 charsets MUST be implemented.
+      All other charsets are optional.
+
+      There is also a UID SORT command which returns unique identifiers
+      instead of message sequence numbers.  Note that there are separate
+      searching criteria for message sequence numbers and UIDs; thus the
+      arguments to UID SORT are interpreted the same as in SORT.  This
+      is analogous to the behavior of UID SEARCH, as opposed to UID
+      COPY, UID FETCH, or UID STORE.
+
+      The SORT command first searches the mailbox for messages that
+      match the given searching criteria using the charset argument for
+      the interpretation of strings in the searching criteria.  It then
+      returns the matching messages in an untagged SORT response, sorted
+      according to one or more sort criteria.
+
+      Sorting is in ascending order.  Earlier dates sort before later
+      dates; smaller sizes sort before larger sizes; and strings are
+      sorted according to ascending values established by their
+      collation algorithm (see under "Internationalization
+      Considerations").
+
+      If two or more messages exactly match according to the sorting
+      criteria, these messages are sorted according to the order in
+      which they appear in the mailbox.  In other words, there is an
+      implicit sort criterion of "sequence number".
+
+      When multiple sort criteria are specified, the result is sorted in
+      the priority order that the criteria appear.  For example,
+      (SUBJECT DATE) will sort messages in order by their base subject
+      text; and for messages with the same base subject text will sort
+      by their sent date.
+
+      Untagged EXPUNGE responses are not permitted while the server is
+      responding to a SORT command, but are permitted during a UID SORT
+      command.
+
+      The defined sort criteria are as follows.  Refer to the Formal
+      Syntax section for the precise syntactic definitions of the
+      arguments.  If the associated RFC-822 header for a particular
+      criterion is absent, it is treated as the empty string.  The empty
+      string always collates before non-empty strings.
+
+      ARRIVAL
+         Internal date and time of the message.  This differs from the
+         ON criteria in SEARCH, which uses just the internal date.
+
+      CC
+         [IMAP] addr-mailbox of the first "cc" address.
+
+      DATE
+         Sent date and time, as described in section 2.2.
+
+      FROM
+         [IMAP] addr-mailbox of the first "From" address.
+
+      REVERSE
+         Followed by another sort criterion, has the effect of that
+         criterion but in reverse (descending) order.
+            Note: REVERSE only reverses a single criterion, and does not
+            affect the implicit "sequence number" sort criterion if all
+            other criteria are identicial.  Consequently, a sort of
+            REVERSE SUBJECT is not the same as a reverse ordering of a
+            SUBJECT sort.  This can be avoided by use of additional
+            criteria, e.g. SUBJECT DATE vs. REVERSE SUBJECT REVERSE
+            DATE.  In general, however, it's better (and faster, if the
+            client has a "reverse current ordering" command) to reverse
+            the results in the client instead of issuing a new SORT.
+
+      SIZE
+         Size of the message in octets.
+
+      SUBJECT
+         Base subject text.
+
+      TO
+         [IMAP] addr-mailbox of the first "To" address.
+
+   Example:    C: A282 SORT (SUBJECT) UTF-8 SINCE 1-Feb-1994
+               S: * SORT 2 84 882
+               S: A282 OK SORT completed
+               C: A283 SORT (SUBJECT REVERSE DATE) UTF-8 ALL
+               S: * SORT 5 3 4 1 2
+               S: A283 OK SORT completed
+               C: A284 SORT (SUBJECT) US-ASCII TEXT "not in mailbox"
+               S: * SORT
+               S: A284 OK SORT completed
+
+BASE.6.4.THREAD. THREAD Command
+
+Arguments:  threading algorithm
+            charset specification
+            searching criteria (one or more)
+
+Data:       untagged responses: THREAD
+
+Result:     OK - thread completed
+            NO - thread error: can't thread that charset or
+                 criteria
+            BAD - command unknown or arguments invalid
+
+      The THREAD command is a variant of SEARCH with threading semantics
+      for the results.  Thread has two arguments before the searching
+      criteria argument; a threading algorithm, and the searching
+      charset.
+
+      The charset argument is mandatory (unlike SEARCH) and indicates
+      the [CHARSET] of the strings that appear in the searching
+      criteria.  The US-ASCII and UTF-8 charsets MUST be implemented.
+      All other charsets are optional.
+
+      There is also a UID THREAD command which returns unique
+      identifiers instead of message sequence numbers.  Note that there
+      are separate searching criteria for message sequence numbers and
+      UIDs; thus the arguments to UID THREAD are interpreted the same as
+      in THREAD.  This is analogous to the behavior of UID SEARCH, as
+      opposed to UID COPY, UID FETCH, or UID STORE.
+
+      The THREAD command first searches the mailbox for messages that
+      match the given searching criteria using the charset argument for
+      the interpretation of strings in the searching criteria.  It then
+      returns the matching messages in an untagged THREAD response,
+      threaded according to the specified threading algorithm.
+
+      All collation is in ascending order.  Earlier dates collate before
+      later dates and strings are collated according to ascending values
+      established by their collation algorithm (see under
+      "Internationalization Considerations").
+
+      Untagged EXPUNGE responses are not permitted while the server is
+      responding to a THREAD command, but are permitted during a UID
+      THREAD command.
+
+      The defined threading algorithms are as follows:
+
+      ORDEREDSUBJECT
+
+         The ORDEREDSUBJECT threading algorithm is also referred to as
+         "poor man's threading."  The searched messages are sorted by
+         base subject and then by the sent date.  The messages are then
+         split into separate threads, with each thread containing
+         messages with the same base subject text.  Finally, the threads
+         are sorted by the sent date of the first message in the thread.
+
+         The first message of each thread are siblings of each other
+         (the "root").  The second message of a thread is the child of
+         the first message, and subsequent messages of the thread are
+         siblings of the second message and hence children of the
+         message at the root.  Hence, there are no grandchildren in
+         ORDEREDSUBJECT threading.
+
+         Children in ORDEREDSUBJECT threading do not have descendents.
+         Client implementations SHOULD treat descendents of a child in
+         a server response as being siblings of that child.
+
+      REFERENCES
+
+         The REFERENCES threading algorithm threads the searched
+         messages by grouping them together in parent/child
+         relationships based on which messages are replies to others.
+         The parent/child relationships are built using two methods:
+         reconstructing a message's ancestry using the references
+         contained within it; and checking the original (not base)
+         subject of a message to see if it is a reply to (or forward of)
+         another message.
+
+            Note: "Message ID" in the following description refers to a
+            normalized form of the msg-id in [RFC-2822].  The actual
+            text in an RFC 2822 may use quoting, resulting in multiple
+            ways of expressing the same Message ID.  Implementations of
+            the REFERENCES threading algorithm MUST normalize any msg-id
+            in order to avoid false non-matches due to differences in
+            quoting.
+
+            For example, the msg-id
+               <"01KF8JCEOCBS0045PS"@xxx.yyy.com>
+            and the msg-id
+               <01KF8JCEOCBS0045PS@xxx.yyy.com>
+            MUST be interpreted as being the same Message ID.
+
+         The references used for reconstructing a message's ancestry are
+         found using the following rules:
+
+            If a message contains a References header line, then use the
+            Message IDs in the References header line as the references.
+
+            If a message does not contain a References header line, or
+            the References header line does not contain any valid
+            Message IDs, then use the first (if any) valid Message ID
+            found in the In-Reply-To header line as the only reference
+            (parent) for this message.
+
+               Note: Although [RFC-2822] permits multiple Message IDs in
+               the In-Reply-To header, in actual practice this
+               discipline has not been followed.  For example,
+               In-Reply-To headers have been observed with message
+               addresses after the Message ID, and there are no good
+               heuristics for software to determine the difference.
+               This is not a problem with the References header however.
+
+            If a message does not contain an In-Reply-To header line, or
+            the In-Reply-To header line does not contain a valid Message
+            ID, then the message does not have any references (NIL).
+
+         A message is considered to be a reply or forward if the base
+         subject extraction rules, applied to the original subject,
+         remove any of the following: a subj-refwd, a "(fwd)"
+         subj-trailer, or a subj-fwd-hdr and subj-fwd-trl.
+
+         The REFERENCES algorithm is significantly more complex than
+         ORDEREDSUBJECT and consists of six main steps.  These steps are
+         outlined in detail below.
+
+         (1) For each searched message:
+
+            (A) Using the Message IDs in the message's references, link
+            the corresponding messages (those whose Message-ID header
+            line contains the given reference Message ID) together as
+            parent/child.  Make the first reference the parent of the
+            second (and the second a child of the first), the second the
+            parent of the third (and the third a child of the second),
+            etc.  The following rules govern the creation of these
+            links:
+
+               If a message does not contain a Message-ID header line,
+               or the Message-ID header line does not contain a valid
+               Message ID, then assign a unique Message ID to this
+               message.
+
+               If two or more messages have the same Message ID, then
+               only use that Message ID in the first (lowest sequence
+               number) message, and assign a unique Message ID to each
+               of the subsequent messages with a duplicate of that
+               Message ID.
+
+               If no message can be found with a given Message ID,
+               create a dummy message with this ID.  Use this dummy
+               message for all subsequent references to this ID.
+
+               If a message already has a parent, don't change the
+               existing link.  This is done because the References
+               header line may have been truncated by a MUA.  As a
+               result, there is no guarantee that the messages
+               corresponding to adjacent Message IDs in the References
+               header line are parent and child.
+
+               Do not create a parent/child link if creating that link
+               would introduce a loop.  For example, before making
+               message A the parent of B, make sure that A is not a
+               descendent of B.
+
+                  Note: Message ID comparisons are case-sensitive.
+
+            (B) Create a parent/child link between the last reference
+            (or NIL if there are no references) and the current message.
+            If the current message already has a parent, it is probably
+            the result of a truncated References header line, so break
+            the current parent/child link before creating the new
+            correct one.  As in step 1.A, do not create the parent/child
+            link if creating that link would introduce a loop.  Note
+            that if this message has no references, that it will now
+            have no parent.
+
+               Note: The parent/child links created in steps 1.A and 1.B
+               MUST be kept consistent with one another at ALL times.
+
+         (2) Gather together all of the messages that have no parents
+         and make them all children (siblings of one another) of a dummy
+         parent (the "root").  These messages constitute the first
+         (head) message of the threads created thus far.
+
+         (3) Prune dummy messages from the thread tree.  Traverse each
+         thread under the root, and for each message:
+
+            If it is a dummy message with NO children, delete it.
+
+            If it is a dummy message with children, delete it, but
+            promote its children to the current level.  In other words,
+            splice them in with the dummy's siblings.
+
+            Do not promote the children if doing so would make them
+            children of the root, unless there is only one child.
+
+         (4) Sort the messages under the root (top-level siblings only)
+         by sent date as described in section 2.2.  In the case of a
+         dummy message, sort its children by sent date and then use the
+         first child for the top-level sort.
+
+         (5) Gather together messages under the root that have the same
+         base subject text.
+
+            (A) Create a table for associating base subjects with
+            messages, called the subject table.
+
+            (B) Populate the subject table with one message per each
+            base subject.  For each child of the root:
+
+               (i) Find the subject of this thread, by using the base
+               subject from either the current message or its first
+               child if the current message is a dummy.  This is the
+               thread subject.
+
+               (ii) If the thread subject is empty, skip this message.
+
+               (iii) Look up the message associated with the thread
+               subject in the subject table.
+
+               (iv) If there is no message in the subject table with the
+               thread subject, add the current message and the thread
+               subject to the subject table.
+
+               Otherwise, if the message in the subject table is not a
+               dummy, AND either of the following criteria are true:
+
+                  The current message is a dummy, OR
+
+                  The message in the subject table is a reply or forward
+                  and the current message is not.
+
+            then replace the message in the subject table with the
+            current message.
+
+            (C) Merge threads with the same thread subject.  For each
+            child of the root:
+
+               (i) Find the message's thread subject as in step 5.B.i
+               above.
+
+               (ii) If the thread subject is empty, skip this message.
+
+               (iii) Lookup the message associated with this thread
+               subject in the subject table.
+
+               (iv) If the message in the subject table is the current
+               message, skip this message.
+
+               Otherwise, merge the current message with the one in the
+               subject table using the following rules:
+
+                  If both messages are dummies, append the current
+                  message's children to the children of the message in
+                  the subject table (the children of both messages
+                  become siblings), and then delete the current message.
+
+                  If the message in the subject table is a dummy and the
+                  current message is not, make the current message a
+                  child of the message in the subject table (a sibling
+                  of its children).
+
+                  If the current message is a reply or forward and the
+                  message in the subject table is not, make the current
+                  message a child of the message in the subject table (a
+                  sibling of its children).
+
+                  Otherwise, create a new dummy message and make both
+                  the current message and the message in the subject
+                  table children of the dummy.  Then replace the message
+                  in the subject table with the dummy message.
+
+                     Note: Subject comparisons are case-insensitive, as
+                     described under "Internationalization
+                     Considerations."
+
+         (6) Traverse the messages under the root and sort each set of
+         siblings by sent date as described in section 2.2.  Traverse
+         the messages in such a way that the "youngest" set of siblings
+         are sorted first, and the "oldest" set of siblings are sorted
+         last (grandchildren are sorted before children, etc).  In the
+         case of a dummy message (which can only occur with top-level
+         siblings), use its first child for sorting.
+
+   Example:    C: A283 THREAD ORDEREDSUBJECT UTF-8 SINCE 5-MAR-2000
+               S: * THREAD (166)(167)(168)(169)(172)(170)(171)
+                  (173)(174 (175)(176)(178)(181)(180))(179)(177
+                  (183)(182)(188)(184)(185)(186)(187)(189))(190)
+                  (191)(192)(193)(194 195)(196 (197)(198))(199)
+                  (200 202)(201)(203)(204)(205)(206 207)(208)
+               S: A283 OK THREAD completed
+               C: A284 THREAD ORDEREDSUBJECT US-ASCII TEXT "gewp"
+               S: * THREAD
+               S: A284 OK THREAD completed
+               C: A285 THREAD REFERENCES UTF-8 SINCE 5-MAR-2000
+               S: * THREAD (166)(167)(168)(169)(172)((170)(179))
+                  (171)(173)((174)(175)(176)(178)(181)(180))
+                  ((177)(183)(182)(188 (184)(189))(185 186)(187))
+                  (190)(191)(192)(193)((194)(195 196))(197 198)
+                  (199)(200 202)(201)(203)(204)(205 206 207)(208)
+               S: A285 OK THREAD completed
+
+        Note: The line breaks in the first and third server
+        responses are for editorial clarity and do not appear in
+        real THREAD responses.
+
+4. Additional Responses
+
+   These responses are extensions to the [IMAP] base protocol.
+
+   The section headings of these responses are intended to correspond
+   with where they would be located in the main document.
+
+BASE.7.2.SORT. SORT Response
+
+   Data:       zero or more numbers
+
+      The SORT response occurs as a result of a SORT or UID SORT
+      command.  The number(s) refer to those messages that match the
+      search criteria.  For SORT, these are message sequence numbers;
+      for UID SORT, these are unique identifiers.  Each number is
+      delimited by a space.
+
+   Example:    S: * SORT 2 3 6
+
+BASE.7.2.THREAD. THREAD Response
+
+   Data:       zero or more threads
+
+      The THREAD response occurs as a result of a THREAD or UID THREAD
+      command.  It contains zero or more threads.  A thread consists of
+      a parenthesized list of thread members.
+
+      Thread members consist of zero or more message numbers, delimited
+      by spaces, indicating successive parent and child.  This continues
+      until the thread splits into multiple sub-threads, at which point
+      the thread nests into multiple sub-threads with the first member
+      of each subthread being siblings at this level.  There is no limit
+      to the nesting of threads.
+
+      The messages numbers refer to those messages that match the search
+      criteria.  For THREAD, these are message sequence numbers; for UID
+      THREAD, these are unique identifiers.
+
+   Example:    S: * THREAD (2)(3 6 (4 23)(44 7 96))
+
+      The first thread consists only of message 2.  The second thread
+      consists of the messages 3 (parent) and 6 (child), after which it
+      splits into two subthreads; the first of which contains messages 4
+      (child of 6, sibling of 44) and 23 (child of 4), and the second of
+      which contains messages 44 (child of 6, sibling of 4), 7 (child of
+      44), and 96 (child of 7).  Since some later messages are parents
+      of earlier messages, the messages were probably moved from some
+      other mailbox at different times.
+
+      -- 2
+
+      -- 3
+         \-- 6
+             |-- 4
+             |   \-- 23
+             |
+             \-- 44
+                  \-- 7
+                      \-- 96
+
+   Example:    S: * THREAD ((3)(5))
+
+      In this example, 3 and 5 are siblings of a parent which does not
+      match the search criteria (and/or does not exist in the mailbox);
+      however they are members of the same thread.
+
+5. Formal Syntax of SORT and THREAD Commands and Responses
+
+   The following syntax specification uses the Augmented Backus-Naur
+   Form (ABNF) notation as specified in [ABNF].  It also uses [ABNF]
+   rules defined in [IMAP].
+
+sort            = ["UID" SP] "SORT" SP sort-criteria SP search-criteria
+
+sort-criteria   = "(" sort-criterion *(SP sort-criterion) ")"
+
+sort-criterion  = ["REVERSE" SP] sort-key
+
+sort-key        = "ARRIVAL" / "CC" / "DATE" / "FROM" / "SIZE" /
+                  "SUBJECT" / "TO"
+
+thread          = ["UID" SP] "THREAD" SP thread-alg SP search-criteria
+
+thread-alg      = "ORDEREDSUBJECT" / "REFERENCES" / thread-alg-ext
+
+thread-alg-ext  = atom
+                    ; New algorithms MUST be registered with IANA
+
+search-criteria = charset 1*(SP search-key)
+
+charset         = atom / quoted
+                    ; CHARSET values MUST be registered with IANA
+
+sort-data       = "SORT" *(SP nz-number)
+
+thread-data     = "THREAD" [SP 1*thread-list]
+
+thread-list     = "(" (thread-members / thread-nested) ")"
+
+thread-members  = nz-number *(SP nz-number) [SP thread-nested]
+
+thread-nested   = 2*thread-list
+
+   The following syntax describes base subject extraction rules (2)-(6):
+
+subject         = *subj-leader [subj-middle] *subj-trailer
+
+subj-refwd      = ("re" / ("fw" ["d"])) *WSP [subj-blob] ":"
+
+subj-blob       = "[" *BLOBCHAR "]" *WSP
+
+subj-fwd        = subj-fwd-hdr subject subj-fwd-trl
+
+subj-fwd-hdr    = "[fwd:"
+
+subj-fwd-trl    = "]"
+
+subj-leader     = (*subj-blob subj-refwd) / WSP
+
+subj-middle     = *subj-blob (subj-base / subj-fwd)
+                    ; last subj-blob is subj-base if subj-base would
+                    ; otherwise be empty
+
+subj-trailer    = "(fwd)" / WSP
+
+subj-base       = NONWSP *(*WSP NONWSP)
+                    ; can be a subj-blob
+
+BLOBCHAR        = %x01-5a / %x5c / %x5e-ff
+                    ; any CHAR8 except '[' and ']'
+
+NONWSP          = %x01-08 / %x0a-1f / %x21-ff
+                    ; any CHAR8 other than WSP
+
+6. Security Considerations
+
+   The SORT and THREAD extensions do not raise any security
+   considerations that are not present in the base [IMAP] protocol, and
+   these issues are discussed in [IMAP].  Nevertheless, it is important
+   to remember that [IMAP] protocol transactions, including message
+   data, are sent in the clear over the network unless protection from
+   snooping is negotiated, either by the use of STARTTLS, privacy
+   protection is negotiated in the AUTHENTICATE command, or some other
+   protection mechanism.
+
+   Although not a security consideration, it is important to recognize
+   that sorting by REFERENCES can lead to misleading threading trees.
+   For example, a message with false References: header data will cause
+   a thread to be incorporated into another thread.
+
+   The process of extracting the base subject may lead to incorrect
+   collation if the extracted data was significant text as opposed to
+   a subject artifact.
+
+7. Internationalization Considerations
+
+   As stated in the introduction, the rules of I18NLEVEL=1 as described
+   in [IMAP-I18N] MUST be followed; that is, the SORT and THREAD
+   extensions MUST collate strings according to the i;unicode-casemap
+   collation described in [UNICASEMAP].  Servers SHOULD also advertise
+   the I18NLEVEL=1 extension.  Alternatively, a server MAY implement
+   I18NLEVEL=2 (or higher) and comply with the rules of that level.
+
+   As discussed in [IMAP-I18N] section 4.5, all server implementations
+   should eventually be updated to support the [IMAP-I18N] I18NLEVEL=2
+   extension.
+
+   Translations of the "re" or "fw"/"fwd" tokens are not specified for
+   removal in the base subject extraction process.  An attempt to add
+   such translated tokens would result in a geometrically complex, and
+   ultimately unimplementable, task.
+
+   Instead, note that [RFC-2822] section 3.6.5 recommends that "re:"
+   (from the Latin "res", in the matter of) be used to identify a reply.
+   Although it is evident that, from the multiple forms of token to
+   identify a forwarded message, there is considerable variation found
+   in the wild, the variations are (still) manageable.  Consequently, it
+   is suggested that "re:" and one of the variations of the tokens for
+   forward supported by the base subject extraction rules be adopted for
+   Internet mail messages, since doing so makes it a simple display time
+   task to localize the token language for the user.
+
+8. IANA Considerations
+
+   [IMAP] capabilities are registered by publishing a standards track or
+   IESG approved experimental RFC.  This document constitutes
+   registration of the SORT and THREAD capabilities in the [IMAP]
+   capabilities registry.
+
+   This document creates a new [IMAP] threading algorithms registry,
+   which registers threading algorithms by publishing a standards track
+   or IESG approved experimental RFC.  This document constitutes
+   registration of the ORDEREDSUBJECT and REFERENCES algorithms in that
+   registry.
+
+9. Normative References
+
+   The following documents are normative to this document:
+
+   [ABNF]                Crocker, D. and Overell, P. "Augmented BNF
+                         for Syntax Specifications: ABNF", RFC 5234
+                         January 2008
+
+   [CHARSET]             Freed, N. and Postel, J. "IANA Character Set
+                         Registration Procedures", RFC 2978, October
+                         2000.
+
+   [IMAP]                Crispin, M. "Internet Message Access Protocol -
+                         Version 4rev1", RFC 3501, March 2003.
+
+   [IMAP-I18N]           Newman, C. and Gulbrandsen, A. "Internet
+                         Message Access Protocol Internationalization",
+                         Work in Progress.
+
+   [KEYWORDS]            Bradner, S. "Key words for use in RFCs to
+                         Indicate Requirement Levels", BCP 14, RFC 2119,
+                         March 1997.
+
+   [RFC-2822]            Resnick, P. "Internet Message Format", RFC
+                         2822, April 2001.
+
+   [UNICASEMAP]          Crispin, M. "i;unicode-casemap - Simple Unicode
+                         Collation Algorithm", RFC 5051.
+
+10. Informative References
+
+   The following documents are informative to this document:
+
+   [IMAP-MODELS]         Crispin, M. "Distributed Electronic Mail Models
+                         in IMAP4", RFC 1733, December 1994.
+
+   [THREADING]           Zawinski, J. "Message Threading",
+                         http://www.jwz.org/doc/threading.html,
+                         1997-2002.
+
+Appendices
+
+Author's Address
+
+   Mark R. Crispin
+   Networks and Distributed Computing
+   University of Washington
+   4545 15th Avenue NE
+   Seattle, WA  98105-4527
+
+   Phone: +1 (206) 543-5762
+
+   EMail: MRC@CAC.Washington.EDU
+
+   Kenneth Murchison
+   Carnegie Mellon University
+   5000 Forbes Avenue
+   Cyert Hall 285
+   Pittsburgh, PA  15213
+
+   Phone: +1 (412) 268-2638
+   Email: murch@andrew.cmu.edu
+
+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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.