Internet Message Access Protocol - SORT and THREAD Extensions
RFC 5256

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 20

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 and