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
datatracker.ietf.org