draft-ietf-imapext-sort-11.txt   draft-ietf-imapext-sort-12.txt 
IMAP Extensions Working Group M. Crispin IMAP Extensions Working Group M. Crispin
INTERNET-DRAFT: IMAP SORT K. Murchison INTERNET-DRAFT: IMAP SORT K. Murchison
Document: internet-drafts/draft-ietf-imapext-sort-11.txt December 2002 Document: internet-drafts/draft-ietf-imapext-sort-12.txt March 2003
INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSION INTERNET MESSAGE ACCESS PROTOCOL - SORT AND 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 36 skipping to change at page 1, line 36
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 document will be submitted to the RFC A revised version of this document will be submitted to the RFC
editor as an Informational Document for the Internet Community. editor as an Informational Document for the Internet Community.
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 12 June 2003. ietf-imapext@IMC.ORG. This document will expire before 24 September
Distribution of this memo is unlimited. 2003. Distribution of this memo is unlimited.
Abstract Abstract
This document describes the base-level server-based sorting and This document describes the base-level server-based sorting and
threading extension to the [IMAP] protocol. This extension provides threading extension to the [IMAP] protocol. This extension provides
substantial performance improvements for IMAP clients which offer substantial performance improvements for IMAP clients which offer
sorted and threaded views. sorted and threaded views.
A server which supports the base-level SORT extension indicates this A server which supports the base-level SORT extension indicates this
with a capability name which starts with "SORT". Future, upwards- with a capability name which starts with "SORT". Future,
compatible extensions to the SORT extension will all start with upwards-compatible extensions to the SORT extension will all start
"SORT", indicating support for this base level. with "SORT", indicating support for this base level.
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
provides for future upwards-compatible extensions. provides for future upwards-compatible extensions.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to
be interpreted as described in [KEYWORDS]. be interpreted as described in [KEYWORDS].
skipping to change at page 8, line 29 skipping to change at page 8, line 29
For example, the msg-id For example, the msg-id
<"01KF8JCEOCBS0045PS"@xxx.yyy.com> <"01KF8JCEOCBS0045PS"@xxx.yyy.com>
and the msg-id and the msg-id
<01KF8JCEOCBS0045PS@xxx.yyy.com> <01KF8JCEOCBS0045PS@xxx.yyy.com>
MUST be interpreted as being the same Message ID. 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 References header line, then use the
then use the Message IDs in the References header line as 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 2822] 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,
skipping to change at page 9, line 30 skipping to change at page 9, line 27
second (and the second a child of the first), the second the second (and the second a child of the first), the second the
parent of the third (and the third a child of the second), parent of the third (and the third a child of the second),
etc. The following rules govern the creation of these etc. The following rules govern the creation of these
links: links:
If a message does not contain a Message-ID header line, If a message does not contain a Message-ID header line,
or the Message-ID header line does not contain a valid or the Message-ID header line does not contain a valid
Message ID, then assign a unique Message ID to this Message ID, then assign a unique Message ID to this
message. message.
If two or more messages have the same Message ID, assign If two or more messages have the same Message ID, then
a unique Message ID to each of the duplicates. only use that Message ID in the first (lowest sequence
number) message, and assign a unique Message ID to each
of the subsequent messages with a duplicate of that
Message ID.
If no message can be found with a given Message ID, If no message can be found with a given Message ID,
create a dummy message with this ID. Use this dummy create a dummy message with this ID. Use this dummy
message for all subsequent references to this ID. message for all subsequent references to this ID.
If a message already has a parent, don't change the If a message already has a parent, don't change the
existing link. This is done because the References existing link. This is done because the References
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
skipping to change at page 16, line 7 skipping to change at page 16, line 7
\-- 96 \-- 96
Example: S: * THREAD ((3)(5)) Example: S: * THREAD ((3)(5))
In this example, 3 and 5 are siblings of a parent which does not 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); match the search criteria (and/or does not exist in the mailbox);
however they are members of the same thread. however they are members of the same thread.
Formal Syntax of SORT and THREAD commands and Responses Formal Syntax of SORT and THREAD commands and Responses
sort-data = "SORT" *(SP nz-number)
sort = ["UID" SP] "SORT" SP sort = ["UID" SP] "SORT" SP
"(" sort-criterion *(SP sort-criterion) ")" "(" sort-criterion *(SP sort-criterion) ")"
SP search-charset 1*(SP search-key) SP charset 1*(SP search-key)
sort-criterion = ["REVERSE" SP] sort-key sort-criterion = ["REVERSE" SP] sort-key
sort-key = "ARRIVAL" / "CC" / "DATE" / "FROM" / "SIZE" / sort-key = "ARRIVAL" / "CC" / "DATE" / "FROM" / "SIZE" /
"SUBJECT" / "TO" "SUBJECT" / "TO"
thread = ["UID" SP] "THREAD" SP thread-algorithm
SP charset 1*(SP search-key)
thread-algorithm = "ORDEREDSUBJECT" / "REFERENCES" / atom
charset = astring
; CHARSET argument to MUST be registered with IANA
sort-data = "SORT" *(SP nz-number)
thread-data = "THREAD" [SP 1*thread-list] thread-data = "THREAD" [SP 1*thread-list]
thread-list = "(" thread-members / thread-nested ")" thread-list = "(" thread-members / thread-nested ")"
thread-members = nz-number *(SP nz-number) [SP thread-nested] thread-members = nz-number *(SP nz-number) [SP thread-nested]
thread-nested = 2*thread-list thread-nested = 2*thread-list
thread = ["UID" SP] "THREAD" SP thread-algorithm
SP search-charset 1*(SP search-key)
thread-algorithm = "ORDEREDSUBJECT" / "REFERENCES" / atom
The following syntax describes base subject extraction rules (2)-(6): The following syntax describes base subject extraction rules (2)-(6):
subject = *subj-leader [subj-middle] *subj-trailer subject = *subj-leader [subj-middle] *subj-trailer
subj-refwd = ("re" / ("fw" ["d"])) *WSP [subj-blob] ":" subj-refwd = ("re" / ("fw" ["d"])) *WSP [subj-blob] ":"
subj-blob = "[" *BLOBCHAR "]" *WSP subj-blob = "[" *BLOBCHAR "]" *WSP
subj-fwd = subj-fwd-hdr subject subj-fwd-trl subj-fwd = subj-fwd-hdr subject subj-fwd-trl
skipping to change at page 17, line 26 skipping to change at page 17, line 32
considerations that are not present in the base [IMAP] protocol, and considerations that are not present in the base [IMAP] protocol, and
these issues are discussed in [IMAP]. Nevertheless, it is important these issues are discussed in [IMAP]. Nevertheless, it is important
to remember that IMAP4rev1 protocol transactions, including to remember that IMAP4rev1 protocol transactions, including
electronic mail data, are sent in the clear over the network unless electronic mail data, are sent in the clear over the network unless
protection from snooping is negotiated, either by the use of protection from snooping is negotiated, either by the use of
STARTTLS, privacy protection is negotiated in the AUTHENTICATE STARTTLS, privacy protection is negotiated in the AUTHENTICATE
command, or some other protection mechanism is in effect. command, or some other protection mechanism is in effect.
Internationalization Considerations Internationalization Considerations
Prior to doing any string collation, all strings must be prepared as Strings in charsets other than US-ASCII and UTF-8 must be converted
described in [STRINGPREP]. to UTF-8 prior to any comparisons. String comparisons used in SORT
;;; NEED TO DEFINE A STRINGPREP PROFILE HERE. and THREAD collations are performed as described in [IMAP-I18N].
By default, strings are sorted according to the "minimum sorting
collation algorithm". All implementations of SORT MUST implement the
minimum sorting collation algorithm.
In the minimum sorting collation algorithm, the Basic Latin
alphabetics (U+0041 to U+005A uppercase, U+0061 to U+007A lowercase)
are sorted in a case-insensitive fashion; that is, "A" (U+0041) and
"a" (U+0061) are treated as exact equals. The characters U+005B to
U+0060 are sorted after the Basic Latin alphabetics; for example,
U+005E is sorted after U+005A and U+007A. All other characters are
sorted according to their octet values, as expressed in UTF-8. No
attempt is made to treat composed characters specially, or to do
case-insensitive comparisons of composed characters.
Note: this means, among other things, that the composed
characters in the Latin-1 Supplement are not compared in
what would be considered an ISO 8859-1 "case-insensitive"
fashion. Case comparison rules for characters with
diacriticals differ between languages; the minimum sorting
collation does not attempt to deal with this at all. This
is reserved for other sorting collations, which may be
language-specific.
;;; THIS PROBLEM CAN BE AVOIDED WITH THE RIGHT STRINGPREP PROFILE.
Other sorting collations, and the ability to change the sorting
collation, will be defined in a separate document dealing with IMAP
internationalization.
Non-English translations of "Re" or "Fw"/"Fwd" are not specified for Non-English translations of "Re" or "Fw"/"Fwd" are not specified for
removal in the base subject extraction process. By specifying that removal in the base subject extraction process. By specifying that
only the English forms of the prefixes are used, it becomes a simple only the English forms of the prefixes are used, it becomes a simple
display time task to localize the prefix language for the user. If, display time task to localize the prefix language for the user. If,
on the other hand, prefixes in multiple languages are permitted, the on the other hand, prefixes in multiple languages are permitted, the
result is a geometrically complex, and ultimately unimplementable, result is a geometrically complex, and ultimately unimplementable,
task. In order to improve the ability to support non-English display task. In order to improve the ability to support non-English display
in Internet mail clients, only the English form of these prefixes in Internet mail clients, only the English form of these prefixes
should be transmitted in Internet mail messages. should be transmitted in Internet mail messages.
skipping to change at page 18, line 42 skipping to change at page 18, line 24
registered with IANA. registered with IANA.
A. References A. References
The following documents are normative to this document: The following documents are normative to this document:
[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.
[IMAP] Crispin, M., "Internet Message Access Protocol - Version [IMAP] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, December 1996. 4rev1", RFC 3501, March 2003.
[IMAP-I18N] Newman, C. "Internet Message Access Protocol
Internationalization", Work in Progress.
[KEYWORDS] Bradner, S. "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S. "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard University, March 1997. Requirement Levels", RFC 2119, Harvard University, March 1997.
[NEWS] Horton, M., and Adams, R., "Standard for interchange of USENET
messages", RFC-1036, AT&T Bell Laboratories and Center for Seismic
Studies, December, 1987.
[RFC-2822] Resnick, P. "Internet Message Format", RFC 2822, April [RFC-2822] Resnick, P. "Internet Message Format", RFC 2822, April
2001. 2001.
[STRINGPREP] Hoffman, P., and Blanchet, M. "Preparation of The following documents are informative to this document:
Internationalized Strings ("stringprep"), Work In Progress.
[THREADING] Zawinski, J. "message threading", [THREADING] Zawinski, J. "message threading",
http://www.jwz.org/doc/threading.html, 1997-2002. http://www.jwz.org/doc/threading.html, 1997-2002.
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
 End of changes. 

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