sort.txt

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

   Data:       zero or more numbers

      The SORT response occurs as a result of a SORT or UID SORT
      command.  The number(s) refer to those messages that match the
      search criteria.  For SORT, these are message sequence numbers;
      for UID SORT, these are unique identifiers.  Each number is
      delimited by a space.

   Example:    S: * SORT 2 3 6

BASE.7.2.THREAD. THREAD Response

   Data:       zero or more threads

      The THREAD response occurs as a result of a THREAD or UID THREAD
      command.  It contains zero or more threads.  A thread consists of
      a parenthesized list of thread members.

      Thread members consist of zero or more message numbers, delimited
      by spaces, indicating successive parent and child.  This continues
      until the thread splits into multiple sub-threads, at which point
      the thread nests into multiple sub-threads with the first member
      of each subthread being siblings at this level.  There is no limit
      to the nesting of threads.

      The messages numbers refer to those messages that match the search
      criteria.  For THREAD, these are message sequence numbers; for UID
      THREAD, these are unique identifiers.

   Example:    S: * THREAD (2)(3 6 (4 23)(44 7 96))

      The first thread consists only of message 2.  The second thread
      consists of the messages 3 (parent) and 6 (child), after which it
      splits into two subthreads; the first of which contains messages 4
      (child of 6, sibling of 44) and 23 (child of 4), and the second of
      which contains messages 44 (child of 6, sibling of 4), 7 (child of
      44), and 96 (child of 7).  Since some later messages are parents
      of earlier messages, the messages were probably moved from some
      other mailbox at different times.

      -- 2

      -- 3
         \-- 6
             |-- 4
             |   \-- 23
             |
             \-- 44
                  \-- 7
                      \-- 96

   Example:    S: * THREAD ((3)(5))

      In this example, 3 and 5 are siblings of a parent which does not
      match the search criteria (and/or does not exist in the mailbox);
      however they are members of the same thread.

5. Formal Syntax of SORT and THREAD Commands and Responses

   The following syntax specification uses the Augmented Backus-Naur
   Form (ABNF) notation as specified in [ABNF].  It also uses [ABNF]
   rules defined in [IMAP].

sort            = ["UID" SP] "SORT" SP sort-criteria SP search-criteria

sort-criteria   = "(" sort-criterion *(SP sort-criterion) ")"

sort-criterion  = ["REVERSE" SP] sort-key

sort-key        = "ARRIVAL" / "CC" / "DATE" / "FROM" / "SIZE" /
                  "SUBJECT" / "TO"

thread          = ["UID" SP] "THREAD" SP thread-alg SP search-criteria

thread-alg      = "ORDEREDSUBJECT" / "REFERENCES" / thread-alg-ext

thread-alg-ext  = atom
                    ; New algorithms MUST be registered with IANA

search-criteria = charset 1*(SP search-key)

charset         = atom / quoted
                    ; CHARSET values MUST be registered with IANA

sort-data       = "SORT" *(SP nz-number)

thread-data     = "THREAD" [SP 1*thread-list]

thread-list     = "(" (thread-members / thread-nested) ")"

thread-members  = nz-number *(SP nz-number) [SP thread-nested]

thread-nested   = 2*thread-list

   The following syntax describes base subject extraction rules (2)-(6):

subject         = *subj-leader [subj-middle] *subj-trailer

subj-refwd      = ("re" / ("fw" ["d"])) *WSP [subj-blob] ":"

subj-blob       = "[" *BLOBCHAR "]" *WSP

subj-fwd        = subj-fwd-hdr subject subj-fwd-trl

subj-fwd-hdr    = "[fwd:"

subj-fwd-trl    = "]"

subj-leader     = (*subj-blob subj-refwd) / WSP

subj-middle     = *subj-blob (subj-base / subj-fwd)
                    ; last subj-blob is subj-base if subj-base would
                    ; otherwise be empty

subj-trailer    = "(fwd)" / WSP

subj-base       = NONWSP *(*WSP NONWSP)
                    ; can be a subj-blob

BLOBCHAR        = %x01-5a / %x5c / %x5e-ff
                    ; any CHAR8 except '[' and ']'

NONWSP          = %x01-08 / %x0a-1f / %x21-ff
                    ; any CHAR8 other than WSP

6. Security Considerations

   The SORT and THREAD extensions do not raise any security
   considerations that are not present in the base [IMAP] protocol, and
   these issues are discussed in [IMAP].  Nevertheless, it is important
   to remember that [IMAP] protocol transactions, including message
   data, are sent in the clear over the network unless protection from
   snooping is negotiated, either by the use of STARTTLS, privacy
   protection is negotiated in the AUTHENTICATE command, or some other
   protection mechanism.

   Although not a security consideration, it is important to recognize
   that sorting by REFERENCES can lead to misleading threading trees.
   For example, a message with false References: header data will cause
   a thread to be incorporated into another thread.

   The process of extracting the base subject may lead to incorrect
   collation if the extracted data was significant text as opposed to
   a subject artifact.

7. Internationalization Considerations

   As stated in the introduction, the rules of I18NLEVEL=1 as described
   in [IMAP-I18N] MUST be followed; that is, the SORT and THREAD
   extensions MUST collate strings according to the i;unicode-casemap
   collation described in [UNICASEMAP].  Servers SHOULD also advertise
   the I18NLEVEL=1 extension.  Alternatively, a server MAY implement
   I18NLEVEL=2 (or higher) and comply with the rules of that level.

   As discussed in [IMAP-I18N] section 4.5, all server implementations
   should eventually be updated to support the [IMAP-I18N] I18NLEVEL=2
   extension.

   Translations of the "re" or "fw"/"fwd" tokens are not specified for
   removal in the base subject extraction process.  An attempt to add
   such translated tokens would result in a geometrically complex, and
   ultimately unimplementable, task.

   Instead, note that [RFC-2822] section 3.6.5 recommends that "re:"
   (from the Latin "res", in the matter of) be used to identify a reply.
   Although it is evident that, from the multiple forms of token to
   identify a forwarded message, there is considerable variation found
   in the wild, the variations are (still) manageable.  Consequently, it
   is suggested that "re:" and one of the variations of the tokens for
   forward supported by the base subject extraction rules be adopted for
   Internet mail messages, since doing so makes it a simple display time
   task to localize the token language for the user.

8. IANA Considerations

   [IMAP] capabilities are registered by publishing a standards track or
   IESG approved experimental RFC.  This document constitutes
   registration of the SORT and THREAD capabilities in the [IMAP]
   capabilities registry.

   This document creates a new [IMAP] threading algorithms registry,
   which registers threading algorithms by publishing a standards track
   or IESG approved experimental RFC.  This document constitutes
   registration of the ORDEREDSUBJECT and REFERENCES algorithms in that
   registry.

9. Normative References

   The following documents are normative to this document:

   [ABNF]                Crocker, D. and Overell, P. "Augmented BNF
                         for Syntax Specifications: ABNF", RFC 5234
                         January 2008

   [CHARSET]             Freed, N. and Postel, J. "IANA Character Set
                         Registration Procedures", RFC 2978, October
                         2000.

   [IMAP]                Crispin, M. "Internet Message Access Protocol -
                         Version 4rev1", RFC 3501, March 2003.

   [IMAP-I18N]           Newman, C. and Gulbrandsen, A. "Internet
                         Message Access Protocol Internationalization",
                         Work in Progress.

   [KEYWORDS]            Bradner, S. "Key words for use in RFCs to
                         Indicate Requirement Levels", BCP 14, RFC 2119,
                         March 1997.

   [RFC-2822]            Resnick, P. "Internet Message Format", RFC
                         2822, April 2001.

   [UNICASEMAP]          Crispin, M. "i;unicode-casemap - Simple Unicode
                         Collation Algorithm", RFC 5051.

10. Informative References

   The following documents are informative to this document:

   [IMAP-MODELS]         Crispin, M. "Distributed Electronic Mail Models
                         in IMAP4", RFC 1733, December 1994.

   [THREADING]           Zawinski, J. "Message Threading",
                         http://www.jwz.org/doc/threading.html,
                         1997-2002.

Appendices

Author's Address

   Mark R. Crispin
   Networks and Distributed Computing
   University of Washington
   4545 15th Avenue NE
   Seattle, WA  98105-4527

   Phone: [phone]

   EMail: [e-mail]

   Kenneth Murchison
   Carnegie Mellon University
   5000 Forbes Avenue
   Cyert Hall 285
   Pittsburgh, PA  15213

   Phone: [phone]
   Email: [e-mail]

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   [e-mail].

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.