sort.txt

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

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