draft-ietf-imapext-thread-08.txt   draft-ietf-imapext-thread-09.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-08.txt January 2002 Document: internet-drafts/draft-ietf-imapext-thread-09.txt March 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 4 July 2002. ietf-imapext@IMC.ORG. This document will expire before 21 August
Distribution of this memo is unlimited. 2002. 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 3, line 41 skipping to change at page 3, line 41
There is also a UID THREAD command which corresponds to THREAD the There is also a UID THREAD command which corresponds to THREAD the
way that UID SEARCH corresponds to SEARCH. way that UID SEARCH corresponds to SEARCH.
The THREAD command first searches the mailbox for messages that The THREAD command first searches the mailbox for messages that
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.
Sorting is in ascending order. Earlier dates sort before later
dates; smaller sizes sort before larger sizes; and strings are
sorted according to ascending values established by their
collation algorithm (see under "Internationalization
Considerations").
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 the sent date. The messages are then split subject and then by the sent date. The messages are then split
into separate threads, with each thread containing messages into separate threads, with each thread containing messages
with the same extracted subject text. Finally, the threads are with the same extracted subject text. Finally, the threads are
sorted by the sent date of the first message in the thread. sorted by the sent date of the first message in the thread.
skipping to change at page 4, line 20 skipping to change at page 4, line 32
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
built using two methods: reconstructing a message's ancestry built using two methods: reconstructing a message's ancestry
using the references contained within it; and checking the using the references contained within it; and checking the
subject of a message to see if it is a reply to (or forward of) subject of a message to see if it is a reply to (or forward of)
another. another.
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
<01KF8JCEOCBS0045PS@xxx.yyy.com>
MUST be interpreted as being the same Message ID.
The references used for reconstructing a message's ancestry are The references used for reconstructing a message's ancestry are
found using the following rules: found using the following rules:
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 2822] 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, discipline has not been followed. For example,
In-Reply-To headers have been observed with email In-Reply-To headers have been observed with email
addresses after the Message ID, and there are no good addresses after the Message ID, and there are no good
heuristics for software to determine the difference. heuristics for software to determine the difference.
This is not a 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).
skipping to change at page 13, line 23 skipping to change at page 14, line 23
should be transmitted in Internet mail messages. should be transmitted in Internet mail messages.
A. References A. References
[ABNF] Crocker, D., and Overell, P. "Augmented BNF for Syntax [ABNF] Crocker, D., and Overell, P. "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[NEWS] Horton, M., and Adams, R., "Standard for interchange of USENET [NEWS] Horton, M., and Adams, R., "Standard for interchange of USENET
messages", RFC-1036, AT&T Bell Laboratories and Center for Seismic messages", RFC-1036, AT&T Bell Laboratories and Center for Seismic
Studies, December, 1987. Studies, December, 1987.
[RFC-2822] Resnick, P. "Internet Message Format", RFC 2822, April
2001.
Author's Address Author's Address
Mark R. Crispin Mark R. Crispin
Networks and Distributed Computing Networks and Distributed Computing
University of Washington University of Washington
4545 15th Avenue NE 4545 15th Avenue NE
Seattle, WA 98105-4527 Seattle, WA 98105-4527
Phone: (206) 543-5762 Phone: (206) 543-5762
 End of changes. 

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