Internet Message Access Protocol - SORT and THREAD Extensions
updated by
- rfc-5957 — Display-Based Address Sorting for the IMAP4 SORT Extension
Extracted elements (27)
In the REFERENCES algorithm, if a message already has a parent when processing step 1.A, the existing link is not changed, because the References header may have been truncated by an MUA. If a message already has a parent in step 1.B, the existing link is broken in favor of the new one, as this is more likely to be the correct immediate parent.
The REVERSE sort criterion only reverses a single criterion and does not affect the implicit sequence-number tie-breaker. Consequently, reversing a multi-criterion sort requires placing REVERSE before each criterion individually. In general, it is faster and simpler for the client to reverse the final result list rather than issuing a new SORT command.
The SORT and THREAD extensions are designed for server-side computation to provide substantial performance improvements for clients offering sorted and threaded views, particularly for online (connected) clients, avoiding the need to download all necessary header data to the client.
Translations of 're' or 'fw'/'fwd' subject prefix tokens are not specified for removal in base subject extraction, because adding language-specific translated tokens would result in a geometrically complex and ultimately unimplementable task. Instead, [RFC2822] recommends adopting 're:' universally, with localization handled at display time by the client.
The REFERENCES threading algorithm is based on the algorithm written by Jamie Zawinski and used in Netscape Mail and News versions 2.0 through 3.0. Server capability names starting with 'SORT' or consisting of 'THREAD=' followed by an algorithm name indicate support, allowing 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.
All servers and disconnected clients MUST use exactly the specified base subject extraction algorithm to determine the 'base subject'. Otherwise, a user may get inconsistent results based on whether they are running in connected or disconnected mode.
If the time zone in a Date: header 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.
Implementations of the REFERENCES threading algorithm MUST normalize any msg-id to avoid false non-matches due to differences in quoting. For example, <"01KF8JCEOCBS0045PS"@xxx.yyy.com> and <[email protected]> MUST be interpreted as the same Message ID. Message ID comparisons are case-sensitive.
In the REFERENCES algorithm, the parent/child links created in steps 1.A and 1.B MUST be kept consistent with one another at ALL times. No parent/child link may be created if it would introduce a loop (i.e., making A the parent of B when A is already a descendant of B).
The charset argument to SORT and THREAD is mandatory (unlike SEARCH). The US-ASCII and UTF-8 charsets MUST be implemented; all other charsets are optional.
The SORT and THREAD extensions MUST collate strings according to the i;unicode-casemap collation described in [UNICASEMAP] (the requirement of I18NLEVEL=1). Subject comparisons in the REFERENCES algorithm are case-insensitive per this collation.
The 'base subject' is derived from a message's Subject header by applying a multi-step normalization procedure: converting encoded-words to UTF-8, collapsing whitespace, stripping subj-trailer suffixes, stripping subj-leader and subj-blob prefixes, and unwrapping subj-fwd-hdr/subj-fwd-trl forwarding wrappers. The resulting text is used for subject-based sorting and threading.
The defined SORT sort-key criteria are: ARRIVAL (internal date), CC (first cc address mailbox), DATE (sent date), FROM (first From address mailbox), SIZE (message size in octets), SUBJECT (base subject text), and TO (first To address mailbox). REVERSE followed by another criterion reverses that criterion's ordering.
The ORDEREDSUBJECT threading algorithm ('poor man's threading') sorts searched messages by base subject then sent date, groups them into threads by identical base subject, and sorts threads by the sent date of the first message. All children are at depth one; there are no grandchildren. Clients SHOULD treat any server-returned descendents of a child as siblings of that child.
The REFERENCES threading algorithm builds parent/child relationships from References and In-Reply-To headers. It consists of six steps: (1) link messages via reference chains; (2) gather parentless messages under a dummy root; (3) prune dummy messages; (4) sort top-level threads by sent date; (5) merge threads with identical base subjects; (6) recursively sort sibling sets by sent date.
The 'sent date' is the date and time from the Date: header, adjusted by time zone to normalize to UTC. If no valid Date: header is present or parseable, the message's INTERNALDATE is used as the sent date. When two sent dates match exactly, sequence number order is used as a tie-breaker.
The SORT command is a variant of SEARCH with sorting semantics. Its arguments are a parenthesized list of sort criteria, a mandatory charset specification, and one or more searching criteria. It returns matching messages in an untagged SORT response sorted in ascending order by the specified criteria.
The THREAD command is a variant of SEARCH with threading semantics. Its arguments are a threading algorithm name, a mandatory charset, and one or more searching criteria. It returns matching messages in an untagged THREAD response organized as a parenthesized nested list reflecting parent/child relationships.
This document creates a new IMAP threading algorithms registry and registers the ORDEREDSUBJECT and REFERENCES algorithms within it. New threading algorithms are registered by publishing a standards-track or IESG-approved experimental RFC.
This document registers the 'SORT' and 'THREAD=<algorithm>' capability names in the IMAP capabilities registry. IMAP capabilities are registered by publishing a standards-track or IESG-approved experimental RFC.
Sorting by REFERENCES can lead to misleading threading trees. A message with false References: header data will cause its thread to be incorporated into another thread. The base subject extraction process may also lead to incorrect collation if extracted subject artifacts were significant text.
The SORT and THREAD extensions do not introduce security considerations beyond those present in the base IMAP protocol. However, IMAP protocol transactions including message data are sent in cleartext unless protection is negotiated via STARTTLS, privacy protection in AUTHENTICATE, or another mechanism.
The formal ABNF for SORT: 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'.
The formal ABNF for THREAD: 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.
The SORT response (sort-data) is 'SORT' followed by zero or more space-delimited non-zero numbers representing message sequence numbers (SORT) or unique identifiers (UID SORT) of matching messages in sorted order.
The THREAD response (thread-data) is 'THREAD' followed by zero or more thread-list items. A thread-list is a parenthesized list where space-delimited numbers indicate successive parent/child relationships. When a thread splits, sub-threads are represented as nested parenthesized lists; nesting is unlimited.