draft-ietf-imapext-thread-11.txt   draft-ietf-imapext-thread-12.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
Document: internet-drafts/draft-ietf-imapext-thread-11.txt June 2002 Document: internet-drafts/draft-ietf-imapext-thread-12.txt October 2002
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 33 skipping to change at page 1, line 33
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. Discussion editor as a Proposed Standard for the Internet Community. Discussion
and suggestions for improvement are requested, and should be sent to and suggestions for improvement are requested, and should be sent to
ietf-imapext@IMC.ORG. This document will expire before 22 December ietf-imapext@IMC.ORG. This document will expire before 7 April 2003.
2002. Distribution of this memo is unlimited. 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 4, line 15 skipping to change at page 4, line 15
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
base subject and then by the sent date. The messages are then base subject and then by the sent date. The messages are then
split into separate threads, with each thread containing split into separate threads, with each thread containing
messages with the same base subject text. Finally, the threads messages with the same base subject text. Finally, the threads
are sorted by the sent date of the first message in the thread. are sorted by the sent date of the first message in the thread.
Note that each message in a thread is a child (as opposed to a The first message of each thread are siblings of each other
sibling) of the previous message. (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.
Note: earlier versions of this specification specified
that each message in an ORDEREDSUBJECT thread is a child
(as opposed to a sibling) of the previous message. This
is now deprecated. For compatibility with servers which
may still use the old definition, client implementations
SHOULD treat descendents of a child as being siblings of
that child.
This is because the old definition mistakenly indicated
that there was a parent/child relationship between
successive messages in a thread; when in fact there was
only a chronological relationship. In clients which
indicate parent/child relationships in a thread tree,
this would indicate levels of descent which did not
exist.
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/doc/threading.html. http://www.jwz.org/doc/threading.html.
This algorithm threads the searched messages by grouping them This algorithm threads the searched messages by grouping them
together in parent/child relationships based on which messages together in parent/child relationships based on which messages
are replies to others. The parent/child relationships are are replies to others. The parent/child relationships are
skipping to change at page 9, line 7 skipping to change at page 9, line 28
sorted before children, etc). In the case of an exact match on sorted before children, etc). In the case of an exact match on
sent date or if either of the Date: headers used in a sent date or if either of the Date: headers used in a
comparison can not be parsed, use the order in which the comparison can not be parsed, use the order in which the
messages appear in the mailbox (that is, by sequence number) to messages appear in the mailbox (that is, by sequence number) to
determine the order. In the case of a dummy message (which can determine the order. In the case of a dummy message (which can
only occur with top-level siblings), use its first child for only occur with top-level siblings), use its first child for
sorting. 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
182 188 184 185 186 187 189)(190)(191)(192) (183)(182)(188)(184)(185)(186)(187)(189))(190)
(193)(194 195)(196 197 198)(199)(200 202)(201) (191)(192)(193)(194 195)(196 (197)(198))(199)
(203)(204)(205)(206 207)(208) (200 202)(201)(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
S: A284 OK THREAD completed S: A284 OK THREAD completed
C: A285 THREAD REFERENCES UTF-8 SINCE 5-MAR-2000 C: A285 THREAD REFERENCES UTF-8 SINCE 5-MAR-2000
S: * THREAD (166)(167)(168)(169)(172)((170)(179)) S: * THREAD (166)(167)(168)(169)(172)((170)(179))
(171)(173)((174)(175)(176)(178)(181)(180)) (171)(173)((174)(175)(176)(178)(181)(180))
((177)(183)(182)(188 (184)(189))(185 186)(187)) ((177)(183)(182)(188 (184)(189))(185 186)(187))
(190)(191)(192)(193)((194)(195 196))(197 198) (190)(191)(192)(193)((194)(195 196))(197 198)
(199)(200 202)(201)(203)(204)(205 206 207)(208) (199)(200 202)(201)(203)(204)(205 206 207)(208)
 End of changes. 

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