diff options
Diffstat (limited to 'imap/docs/draft')
| -rw-r--r-- | imap/docs/draft/README | 19 | ||||
| -rw-r--r-- | imap/docs/draft/i18n.txt | 1140 | ||||
| -rw-r--r-- | imap/docs/draft/sort.txt | 885 |
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. |