draft-ietf-imapext-thread-03.txt   draft-ietf-imapext-thread-04.txt 
IMAP Extensions Working Group M. Crispin IMAP Extensions Working Group M. Crispin
Internet Draft: IMAP THREAD K. Murchison Internet Draft: IMAP THREAD K. Murchison
September 2000 Document: internet-drafts/draft-ietf-imapext-thread-04.txt October 2000
Document: internet-drafts/draft-ietf-imapext-thread-03.txt
INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 34
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
A revised version of this draft document will be submitted to the RFC A revised version of this draft document will be submitted to the RFC
editor as a Proposed Standard for the Internet Community. editor as a Proposed Standard for the Internet Community.
Discussion and suggestions for improvement are requested, and should Discussion and suggestions for improvement are requested, and should
be sent to ietf-imapext@IMC.ORG. This document will expire before 20 be sent to ietf-imapext@IMC.ORG. This document will expire before 10
March 2001. Distribution of this memo is unlimited. April 2001. Distribution of this memo is unlimited.
Abstract Abstract
This document describes the server-based threading extension to the This document describes the server-based threading extension to the
IMAP4rev1 protocol. This extension provides substantial performance IMAP4rev1 protocol. This extension provides substantial performance
improvements for IMAP clients which offer threaded views. improvements for IMAP clients which offer threaded views.
A server which supports this extension indicates this with one or A server which supports this extension indicates this with one or
more capability names consisting of "THREAD=" followed by a supported more capability names consisting of "THREAD=" followed by a supported
threading algorithm name as described in this document. This threading algorithm name as described in this document. This
skipping to change at page 2, line 30 skipping to change at page 2, line 30
(3) Remove all prefix text of the subject that matches the (3) Remove all prefix text of the subject that matches the
subj-leader ABNF. subj-leader ABNF.
(4) If there is prefix text of the subject that matches the (4) If there is prefix text of the subject that matches the
subj-blob ABNF, and removing that prefix leaves a non-empty subj-blob ABNF, and removing that prefix leaves a non-empty
subj-base, then remove the prefix text. subj-base, then remove the prefix text.
(5) Repeat (3) and (4) until no matches remain. (5) Repeat (3) and (4) until no matches remain.
Note: it is possible to defer step (2) until step (6), but this Note: it is possible to defer step (2) until step (6),
requires checking for subj-trailer in step (4). but this requires checking for subj-trailer in step (4).
(6) If the resulting text begins with the subj-fwd-hdr ABNF (6) If the resulting text begins with the subj-fwd-hdr ABNF
and ends with the subj-fwd-trl ABNF, remove the and ends with the subj-fwd-trl ABNF, remove the
subj-fwd-hdr and subj-fwd-trl and repeat from step (2). subj-fwd-hdr and subj-fwd-trl and repeat from step (2).
(7) The resulting text is the "base subject" used in (7) The resulting text is the "base subject" used in
threading. threading.
All servers and disconnected clients MUST use exactly this algorithm All servers and disconnected clients MUST use exactly this algorithm
when threading. Otherwise there is potential for a user to get when threading. Otherwise there is potential for a user to get
inconsistent results based on whether they are running in connected inconsistent results based on whether they are running in connected
or disconnected IMAP mode. or disconnected IMAP mode.
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. This differs from
date-related criteria in SEARCH, which use just the date and not the
time, nor adjusts by time zone.
Additional Commands Additional Commands
This command is an extension to the IMAP4rev1 base protocol. This command is an extension to the IMAP4rev1 base protocol.
The section header is intended to correspond with where it would be The section header is intended to correspond with where it would be
located in the main document if it was part of the base located in the main document if it was part of the base
specification. specification.
6.3.THREAD. THREAD Command 6.3.THREAD. THREAD Command
skipping to change at page 3, line 46 skipping to change at page 3, line 46
match the given searching criteria using the charset argument for match the given searching criteria using the charset argument for
the interpretation of strings in the searching criteria. It then the interpretation of strings in the searching criteria. It then
returns the matching messages in an untagged THREAD response, returns the matching messages in an untagged THREAD response,
threaded according to the specified threading algorithm. threaded according to the specified threading algorithm.
The defined threading algorithms are as follows: The defined threading algorithms are as follows:
ORDEREDSUBJECT ORDEREDSUBJECT
The ORDEREDSUBJECT threading algorithm is also referred to as The ORDEREDSUBJECT threading algorithm is also referred to as
"poor man's threading." The searched messages are sorted by "poor man's threading." The searched messages are sorted by
subject and then by sent date, equivalent to a "SORT (SUBJECT subject and then by the sent date. The messages are then split
DATE)". The messages are then split into separate threads, into separate threads, with each thread containing messages
with each thread containing messages with the same extracted with the same extracted subject text. Finally, the threads are
subject text. Finally, the threads are sorted by the sent date sorted by the sent date of the first message in the thread.
of the first message in the thread.
Note that each message in a thread is a child (as opposed to a Note that each message in a thread is a child (as opposed to a
sibling) of the previous message. sibling) of the previous message.
REFERENCES REFERENCES
The REFERENCES threading algorithm is based on the algorithm The REFERENCES threading algorithm is based on the algorithm
written by Jamie Zawinski which was used in "Netscape Mail and written by Jamie Zawinski which was used in "Netscape Mail and
News" versions 2.0 through 3.0. For details, see News" versions 2.0 through 3.0. For details, see
http://www.jwz.org/docs/threading.html. http://www.jwz.org/docs/threading.html.
skipping to change at page 4, line 35 skipping to change at page 4, line 33
If a message contains a [NEWS]-style References header line, If a message contains a [NEWS]-style References header line,
then use the Message IDs in the References header line as then use the Message IDs in the References header line as
the references. the references.
If a message does not contain a References header line, or If a message does not contain a References header line, or
the References header line does not contain any valid the References header line does not contain any valid
Message IDs, then use the first (if any) valid Message ID Message IDs, then use the first (if any) valid Message ID
found in the In-Reply-To header line as the only reference found in the In-Reply-To header line as the only reference
(parent) for this message. (parent) for this message.
NOTE: Although RFC 822 permits multiple Message IDs in Note: Although RFC 822 permits multiple Message IDs in
the In-Reply-To header, in actual practice this the In-Reply-To header, in actual practice this
discipline has not been followed. For example, In- discipline has not been followed. For example,
Reply-To headers have been observed with email addresses In-Reply-To headers have been observed with email
after the Message ID, and there are no good heuristics addresses after the Message ID, and there are no good
for software to determine the difference. This is not a heuristics for software to determine the difference.
problem with the References header however. This is not a problem with the References header however.
If a message does not contain an In-Reply-To header line, or 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 the In-Reply-To header line does not contain a valid Message
ID, then the message does not have any references (NIL). ID, then the message does not have any references (NIL).
The REFERENCES algorithm is significantly more complex than The REFERENCES algorithm is significantly more complex than
ORDEREDSUBJECT and consists of five main steps. These steps ORDEREDSUBJECT and consists of five main steps. These steps
are outlined in detail below. are outlined in detail below.
(1) For each searched message: (1) For each searched message:
skipping to change at page 5, line 38 skipping to change at page 5, line 36
header line may have been truncated by a MUA. As a header line may have been truncated by a MUA. As a
result, there is no guarantee that the messages result, there is no guarantee that the messages
corresponding to adjacent Message IDs in the References corresponding to adjacent Message IDs in the References
header line are parent and child. header line are parent and child.
Do not create a parent/child link if creating that link Do not create a parent/child link if creating that link
would introduce a loop. For example, before making would introduce a loop. For example, before making
message A the parent of B, make sure that A is not a message A the parent of B, make sure that A is not a
descendent of B. descendent of B.
Note: Message ID comparisons are case-sensitive.
(B) Create a parent/child link between the last reference (B) Create a parent/child link between the last reference
(or NIL if there are no references) and the current message. (or NIL if there are no references) and the current message.
If the current message already has a parent, it is probably If the current message already has a parent, it is probably
the result of a truncated References header line, so break the result of a truncated References header line, so break
the current parent/child link before creating the new the current parent/child link before creating the new
correct one. As in step 1.A, do not create the parent/child correct one. As in step 1.A, do not create the parent/child
link if creating that link would introduce a loop. Note link if creating that link would introduce a loop. Note
that if this message has no references, that it will now that if this message has no references, that it will now
have no parent. have no parent.
NOTE: The parent/child links created in steps 1.A and 1.B Note: The parent/child links created in steps 1.A and 1.B
MUST be kept consistent with one another at ALL times. MUST be kept consistent with one another at ALL times.
(2) Gather together all of the messages that have no parents (2) Gather together all of the messages that have no parents
and make them all children (siblings of one another) of a dummy and make them all children (siblings of one another) of a dummy
parent (the "root"). These messages constitute the first parent (the "root"). These messages constitute the first
(head) message of the threads created thus far. (head) message of the threads created thus far.
(3) Prune dummy messages from the thread tree. Traverse each (3) Prune dummy messages from the thread tree. Traverse each
thread under the root, and for each message: thread under the root, and for each message:
skipping to change at page 7, line 42 skipping to change at page 7, line 43
If the current message is a reply or forward and the If the current message is a reply or forward and the
message in the table is not, make the current message message in the table is not, make the current message
a child of the message in the table (a sibling of it's a child of the message in the table (a sibling of it's
children). children).
Otherwise, create a new dummy message and make both Otherwise, create a new dummy message and make both
the current message and the message in the table the current message and the message in the table
children of the dummy. Then replace the message in children of the dummy. Then replace the message in
the table with the dummy message. the table with the dummy message.
Note: Subject comparisons are case-insensitive, as
described under "Internationalization
Considerations."
(5) Traverse the messages under the root and sort each set of (5) Traverse the messages under the root and sort each set of
siblings by date. Traverse the messages in such a way that the siblings by sent date. Traverse the messages in such a way
"youngest" set of siblings are sorted first, and the "oldest" that the "youngest" set of siblings are sorted first, and the
set of siblings are sorted last (grandchildren are sorted "oldest" set of siblings are sorted last (grandchildren are
before children, etc). In the case of an exact match on date, sorted before children, etc). In the case of an exact match on
use the order in which the messages appear in the mailbox (that sent date, use the order in which the messages appear in the
is, by sequence number) to determine the order. In the case of mailbox (that is, by sequence number) to determine the order.
a dummy message (which can only occur with top-level siblings), In the case of a dummy message (which can only occur with top-
use its first child for sorting. level siblings), use its first child for sorting.
Example: C: A283 THREAD ORDEREDSUBJECT UTF-8 SINCE 5-MAR-2000 Example: C: A283 THREAD ORDEREDSUBJECT UTF-8 SINCE 5-MAR-2000
S: * THREAD (166)(167)(168)(169)(172)(170)(171) S: * THREAD (166)(167)(168)(169)(172)(170)(171)
(173)(174 175 176 178 181 180)(179)(177 183 (173)(174 175 176 178 181 180)(179)(177 183
182 188 184 185 186 187 189)(190)(191)(192) 182 188 184 185 186 187 189)(190)(191)(192)
(193)(194 195)(196 197 198)(199)(200 202)(201) (193)(194 195)(196 197 198)(199)(200 202)(201)
(203)(204)(205)(206 207)(208) (203)(204)(205)(206 207)(208)
S: A283 OK THREAD completed S: A283 OK THREAD completed
C: A284 THREAD ORDEREDSUBJECT US-ASCII TEXT "gewp" C: A284 THREAD ORDEREDSUBJECT US-ASCII TEXT "gewp"
S: * THREAD S: * THREAD
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/