draft-ietf-imapext-sort-08.txt   draft-ietf-imapext-sort-09.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-08.txt January 2002 Document: internet-drafts/draft-ietf-imapext-sort-09.txt March 2002
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 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 4 July 2002. ietf-imapext@IMC.ORG. This document will expire before 21 September
Distribution of this memo is unlimited. 2002. 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
skipping to change at page 4, line 44 skipping to change at page 4, line 44
There is also a UID SORT command which corresponds to SORT the way There is also a UID SORT command which corresponds to SORT the way
that UID SEARCH corresponds to SEARCH. that UID SEARCH corresponds to SEARCH.
The SORT command first searches the mailbox for messages that The SORT 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 SORT response, sorted returns the matching messages in an untagged SORT response, sorted
according to one or more sort criteria. according to one or more sort criteria.
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").
If two or more messages exactly match according to the sorting If two or more messages exactly match according to the sorting
criteria, these messages are sorted according to the order in criteria, these messages are sorted according to the order in
which they appear in the mailbox. In other words, there is an which they appear in the mailbox. In other words, there is an
implicit sort criterion of "sequence number". implicit sort criterion of "sequence number".
When multiple sort criteria are specified, the result is sorted in When multiple sort criteria are specified, the result is sorted in
the priority order that the criteria appear. For example, the priority order that the criteria appear. For example,
(SUBJECT DATE) will sort messages in order by their subject text; (SUBJECT DATE) will sort messages in order by their subject text;
and for messages with the same subject text will sort by their and for messages with the same subject text will sort by their
sent date. sent date.
skipping to change at page 5, line 34 skipping to change at page 5, line 40
DATE DATE
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 first "From" address. RFC-822 local-part of the first "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 (descending) order.
Note: REVERSE only reverses a single criterion, and does not Note: REVERSE only reverses a single criterion, and does not
affect the implicit "sequence number" sort criterion if all affect the implicit "sequence number" sort criterion if all
other criteria are identicial. Consequently, a sort of other criteria are identicial. Consequently, a sort of
REVERSE SUBJECT is not the same as a reverse ordering of a REVERSE SUBJECT is not the same as a reverse ordering of a
SUBJECT sort. SUBJECT sort.
This can be avoided by use of additional criteria, e.g. This can be avoided by use of additional criteria, e.g.
SUBJECT DATE vs. REVERSE SUBJECT REVERSE DATE. In general, SUBJECT DATE vs. REVERSE SUBJECT REVERSE DATE. In general,
however, it's better (and faster, if the client has a however, it's better (and faster, if the client has a
"reverse current ordering" command) to reverse the results "reverse current ordering" command) to reverse the results
in the client instead of issuing a new SORT. in the client instead of issuing a new SORT.
 End of changes. 

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