draft-ietf-imapext-sort-05.txt   draft-ietf-imapext-sort-06.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-05.txt August 2000 Document: internet-drafts/draft-ietf-imapext-sort-06.txt December 2000
INTERNET MESSAGE ACCESS PROTOCOL - SORT EXTENSION INTERNET MESSAGE ACCESS PROTOCOL - SORT 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 38 skipping to change at page 1, line 38
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, describing an expanded A revised version of this draft document, describing an expanded
version of this protocol extension, will be submitted to the RFC version of this protocol extension, 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 1 be sent to ietf-imapext@IMC.ORG. This document will expire before 29
March 2001. Distribution of this memo is unlimited. June 2001. Distribution of this memo is unlimited.
Abstract Abstract
This document describes an experimental server-based sorting This document describes an experimental server-based sorting
extension to the IMAP4rev1 protocol, as implemented by the University extension to the IMAP4rev1 protocol, as implemented by the University
of Washington's IMAP toolkit. This extension provides substantial of Washington's IMAP toolkit. This extension provides substantial
performance improvements for IMAP clients which offer sorted views. performance improvements for IMAP clients which offer sorted views.
A server which supports this extension indicates this with a A server which supports this extension indicates this with a
capability name of "SORT". Client implementations SHOULD accept any capability name of "SORT". Client implementations SHOULD accept any
capability name which begins with "SORT" as indicating support for capability name which begins with "SORT" as indicating support for
the extension described in this document. This provides for future the extension described in this document. This provides for future
upwards-compatible extensions. upwards-compatible extensions.
At the time of this document was written, the IMAP Extensions Working At the time of this document was written, the IMAP Extensions Working
Group (IETF-IMAPEXT) was considering upwards-compatible additions to Group (IETF-IMAPEXT) was considering upwards-compatible additions to
the SORT extension described in this document, tenatively called the the SORT extension described in this document, tentatively called the
SORT2 extension. SORT2 extension.
Extracted Subject Text Extracted Subject Text
The "SUBJECT" SORT criteria uses a version of the subject which has The "SUBJECT" SORT criteria uses a version of the subject which has
specific subject artifacts of deployed Internet mail software specific subject artifacts of deployed Internet mail software
removed. Due to the complexity of these artifacts, the formal syntax removed. Due to the complexity of these artifacts, the formal syntax
for the subject extraction rules is ambiguous. The following for the subject extraction rules is ambiguous. The following
procedure is followed to determing the actual "base subject" which is procedure is followed to determine the actual "base subject" which is
used to sort by subject: used to sort by subject:
(1) Convert any RFC 2047 encoded-words in the subject to (1) Convert any RFC 2047 encoded-words in the subject to
UTF-8. Convert all tabs and continuations to space. UTF-8. Convert all tabs and continuations to space.
Convert all multiple spaces to a single space. Convert all multiple spaces to a single space.
(2) Remove all trailing text of the subject that matches (2) Remove all trailing text of the subject that matches
the subj-trailer ABNF, repeat until no more matches are the subj-trailer ABNF, repeat until no more matches are
possible. possible.
skipping to change at page 3, line 43 skipping to change at page 3, line 43
(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 the (7) The resulting text is the "base subject" used in the
SORT. SORT.
All servers and disconnected clients MUST use exactly this algorithm All servers and disconnected clients MUST use exactly this algorithm
when sorting by subject. Otherwise there is potential for a user to when sorting by subject. Otherwise there is potential for a user to
get inconsistant results based on whether they are running in get inconsistent results based on whether they are running in
connected or disconnected IMAP mode. connected or disconnected IMAP mode.
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.
skipping to change at page 5, line 35 skipping to change at page 5, line 35
Sent date and time from the Date: header, adjusted by time Sent date and time from the Date: header, adjusted by time
zone. This differs from the SENTON criteria in SEARCH, which zone. This differs from the SENTON criteria in SEARCH, which
uses just the date and not the time, nor adjusts by time zone. uses just the date and not the time, nor adjusts by time zone.
FROM FROM
RFC-822 local-part of the "From" address. RFC-822 local-part of the "From" address.
REVERSE REVERSE
Followed by another sort criterion, has the effect of that Followed by another sort criterion, has the effect of that
criterion but in reverse order. criterion but in reverse order.
Note: REVERSE only reverses a single criterion, and does not
affect the implicit "sequence number" sort criterion if all
other criteria are identicial. Consequently, a sort of
REVERSE SUBJECT is not the same as a reverse ordering of a
SUBJECT sort.
This can be avoided by use of additional criteria, e.g.
SUBJECT DATE vs. REVERSE SUBJECT REVERSE DATE. In general,
however, it's better (and faster, if the client has a
"reverse current ordering" command) to reverse the results
in the client instead of issuing a new SORT.
SIZE SIZE
Size of the message in octets. Size of the message in octets.
SUBJECT SUBJECT
Extracted subject text. Extracted subject text.
TO TO
RFC-822 local-part of the first "To" address. RFC-822 local-part of the first "To" address.
skipping to change at page 9, line 18 skipping to change at page 9, line 18
Internationalization Considerations Internationalization Considerations
By default, strings are sorted according to the "minimum sorting By default, strings are sorted according to the "minimum sorting
collation algorithm". All implementations of SORT MUST implement the collation algorithm". All implementations of SORT MUST implement the
minimum sorting collation algorithm. minimum sorting collation algorithm.
In the minimum sorting collation algorithm, the Basic Latin In the minimum sorting collation algorithm, the Basic Latin
alphabetics (U+0041 to U+005A uppercase, U+0061 to U+007A lowercase) 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 are sorted in a case-insensitive fashion; that is, "A" (U+0041) and
"a" (U+0061) are treated as exact equals. All other characters are "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 sorted according to their octet values, as expressed in UTF-8. No
attempt is made to treat composed characters specially, or to do attempt is made to treat composed characters specially, or to do
case-insensitive comparisons of composed characters. case-insensitive comparisons of composed characters.
Note: this means, among other things, that the composed Note: this means, among other things, that the composed
characters in the Latin-1 Supplement are not compared in characters in the Latin-1 Supplement are not compared in
what would be considered an ISO 8859-1 "case-insensitive" what would be considered an ISO 8859-1 "case-insensitive"
fashion. Case comparison rules for characters with fashion. Case comparison rules for characters with
diacriticals differ between languages; the minimum sorting diacriticals differ between languages; the minimum sorting
collation does not attempt to deal with this at all. This collation does not attempt to deal with this at all. This
 End of changes. 

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