summaryrefslogtreecommitdiff
path: root/imap/docs/draft
diff options
context:
space:
mode:
authorEduardo Chappa <chappa@washington.edu>2013-11-02 02:51:18 -0600
committerEduardo Chappa <chappa@washington.edu>2013-11-02 02:51:18 -0600
commit7fe712882b909931088a318c08041b0e7974a000 (patch)
tree2770f9b084e2efc7fc55e96e9bf4352cf2ff33a3 /imap/docs/draft
parentbdfc834badee92ceeb2befe02f1d065ced5b9ddf (diff)
downloadalpine-7fe712882b909931088a318c08041b0e7974a000.tar.xz
* Update to version 2.19.1
* Upgrade UW-IMAP to Panda IMAP from https://github.com/jonabbey/panda-imap. * Replace tabs by spaces in From and Subject fields to control for size in screen of these fields. Change only in index screen display.
Diffstat (limited to 'imap/docs/draft')
-rw-r--r--imap/docs/draft/README19
-rw-r--r--imap/docs/draft/i18n.txt1140
-rw-r--r--imap/docs/draft/sort.txt885
3 files changed, 0 insertions, 2044 deletions
diff --git a/imap/docs/draft/README b/imap/docs/draft/README
deleted file mode 100644
index 9aec4719..00000000
--- a/imap/docs/draft/README
+++ /dev/null
@@ -1,19 +0,0 @@
-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
deleted file mode 100644
index f47c6cc7..00000000
--- a/imap/docs/draft/i18n.txt
+++ /dev/null
@@ -1,1140 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 4453bb4d..00000000
--- a/imap/docs/draft/sort.txt
+++ /dev/null
@@ -1,885 +0,0 @@
-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.