sort.txt

广泛使用的邮件服务器！同时

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
   [e-mail].

   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.