Internet Message Access Protocol - SORT and THREAD Extensions
RFC 5256
Document | Type |
RFC - Proposed Standard
(June 2008; No errata)
Updated by RFC 5957
|
|
---|---|---|---|
Authors | Kenneth Murchison , Mark Crispin | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5256 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Lisa Dusseault | ||
Send notices to | <ken@oceana.com> |
Network Working Group M. Crispin Request for Comments: 5256 Panda Programming Category: Standards Track K. Murchison Carnegie Mellon University June 2008 Internet Message Access Protocol - SORT and THREAD Extensions Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. 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 that 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 that 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 that 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 that 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. Crispin & Murchison Standards Track [Page 1] RFC 5256 IMAP Sort June 2008 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 and 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. Crispin & Murchison Standards Track [Page 2] RFC 5256 IMAP Sort June 2008 (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 andShow full document text