< draft-ietf-imapext-sort-16.txt		draft-ietf-imapext-sort-17.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-16.txt May 2004		Document: internet-drafts/draft-ietf-imapext-sort-17.txt May 2004
	INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS		INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS
	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 line 35 ¶		skipping to change at line 35 ¶
	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 3 November 2004.		ietf-imapext@IMC.ORG. This document will expire before 23 November 2004.
	Distribution of this memo is unlimited.		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 extensions to the [IMAP] protocol. These extensions		threading extensions to the [IMAP] protocol. These extensions
	provide substantial performance improvements for IMAP clients which		provide substantial performance improvements for IMAP clients which
	offer sorted and threaded views.		offer sorted and threaded views.
	1. Introduction		1. Introduction
	skipping to change at line 729 ¶		skipping to change at line 729 ¶
	protection is negotiated in the AUTHENTICATE command, or some other		protection is negotiated in the AUTHENTICATE command, or some other
	protection mechanism is in effect.		protection mechanism is in effect.
	7. Internationalization Considerations		7. Internationalization Considerations
	As described in [IMAP-I18N], strings in charsets other than US-ASCII		As described in [IMAP-I18N], strings in charsets other than US-ASCII
	and UTF-8 MUST be converted to UTF-8 and compared in ascending order		and UTF-8 MUST be converted to UTF-8 and compared in ascending order
	according to the selected or active collation algorithm. If the server		according to the selected or active collation algorithm. If the server
	does not support the [IMAP-I18N] COMPARATOR extension, the collation		does not support the [IMAP-I18N] COMPARATOR extension, the collation
	algorithm used is the "en;ascii-casemap" collation described in		algorithm used is the "en;ascii-casemap" collation described in
	[COLLATION].		[COMPARATOR].
	Translations of the "re" or "fw"/"fwd" tokens are not specified for		Translations of the "re" or "fw"/"fwd" tokens are not specified for
	removal in the base subject extraction process. An attempt to add such		removal in the base subject extraction process. An attempt to add such
	translated tokens would result in a geometrically complex, and		translated tokens would result in a geometrically complex, and
	ultimately unimplementable, task.		ultimately unimplementable, task.
	Instead, note that [RFC-2822] section 3.6.5 recommends that "re:" (from		Instead, note that [RFC-2822] section 3.6.5 recommends that "re:" (from
	the Latin "res", in the matter of) be used to identify a reply.		the Latin "res", in the matter of) be used to identify a reply.
	Although it is evident that, from the multiple forms of token to		Although it is evident that, from the multiple forms of token to
	identify a forwarded message, there is considerable variation found in		identify a forwarded message, there is considerable variation found in
End of changes. 3 change blocks.
	3 lines changed or deleted		3 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/