7Internet Engineering Task Force (IETF) D. Karp
8Request for Comments: 5957 Zimbra
10Category: Standards Track
14 Display-Based Address Sorting for the IMAP4 SORT Extension
18 This document describes an IMAP protocol extension enabling server-
19 side message sorting on the commonly displayed portion of the From
24 This is an Internet Standards Track document.
26 This document is a product of the Internet Engineering Task Force
27 (IETF). It represents the consensus of the IETF community. It has
28 received public review and has been approved for publication by the
29 Internet Engineering Steering Group (IESG). Further information on
30 Internet Standards is available in Section 2 of RFC 5741.
32 Information about the current status of this document, any errata,
33 and how to provide feedback on it may be obtained at
34 http://www.rfc-editor.org/info/rfc5957.
38 Copyright (c) 2010 IETF Trust and the persons identified as the
39 document authors. All rights reserved.
41 This document is subject to BCP 78 and the IETF Trust's Legal
42 Provisions Relating to IETF Documents
43 (http://trustee.ietf.org/license-info) in effect on the date of
44 publication of this document. Please review these documents
45 carefully, as they describe your rights and restrictions with respect
46 to this document. Code Components extracted from this document must
47 include Simplified BSD License text as described in Section 4.e of
48 the Trust Legal Provisions and are provided without warranty as
49 described in the Simplified BSD License.
58Karp IMAP4 Display-Based Address Sorting [Page 1]
65 1. Introduction ....................................................2
66 2. Conventions Used in This Document ...............................2
67 3. DISPLAY Sort Value for an Address ...............................2
68 4. The DISPLAYFROM and DISPLAYTO Sort Criteria .....................3
69 5. Formal Syntax ...................................................3
70 6. Security Considerations .........................................3
71 7. Internationalization Considerations .............................4
72 8. IANA Considerations .............................................4
73 9. Normative References ............................................4
77 The [SORT] extension to the [IMAP] protocol provides a means for the
78 server-based sorting of messages. It defines a set of sort criteria
79 and the mechanism for determining the sort value of a message for
82 The [SORT] FROM and TO orderings sort messages lexically on the
83 [IMAP] addr-mailbox of the first address in the message's From and To
84 headers, respectively. This document provides two alternative
85 orderings, DISPLAYFROM and DISPLAYTO, which sort messages based on
86 the first From or To address's [IMAP] addr-name (generally the same
87 as its [RFC5322] display-name), when present.
89 A server that supports the full [SORT] extension as well as both the
90 DISPLAYFROM and DISPLAYTO sort criteria indicates this by returning
91 "SORT=DISPLAY" in its CAPABILITY response.
932. Conventions Used in This Document
95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
97 document are to be interpreted as described in [RFC2119].
993. DISPLAY Sort Value for an Address
101 For the purposes of the sort criteria defined in this document, the
102 sort value for an [IMAP] address structure is defined as follows:
104 o If the address structure's [IMAP] addr-name is non-NIL, apply the
105 procedure from [RFC5255], Section 4.6. (That is, decode any
106 [RFC2047] encoded-words and convert the resulting character string
107 into a charset valid for the currently active [RFC4790] collation,
108 with a default of UTF-8.) If the resulting octet string is not
109 the empty string, use it as the sort value for the address.
114Karp IMAP4 Display-Based Address Sorting [Page 2]
119 o Otherwise, if the address structure's [IMAP] addr-mailbox and
120 [IMAP] addr-host are both non-NIL, the sort value for the address
121 is addr-mailbox@addr-host.
123 o Otherwise, if the address structure's [IMAP] addr-mailbox is non-
124 NIL, the sort value for the address is its addr-mailbox.
126 o If none of the above conditions are met, the sort value for the
127 address is the empty string.
1294. The DISPLAYFROM and DISPLAYTO Sort Criteria
131 This document introduces two new [SORT] sort criteria, DISPLAYFROM
132 and DISPLAYTO. A message's sort value under these orderings MUST be
135 A "derived-addr" value is created from the [IMAP] envelope structure
136 resulting from a FETCH ENVELOPE on the message. For DISPLAYFROM, the
137 derived-addr value is the [IMAP] env-from value. For DISPLAYTO, the
138 derived-addr value is the [IMAP] env-to value.
140 o If the derived-addr value is NIL, the message's sort value is the
143 o Otherwise, the message's sort value is the DISPLAY sort value of
144 the first [IMAP] address in the derived-addr value.
148 The following syntax specification uses the Augmented Backus-Naur
149 Form (ABNF) notation as specified in [RFC5234]. [IMAP] defines the
150 non-terminal "capability", and [SORT] defines "sort-key".
152 capability =/ "SORT=DISPLAY"
154 sort-key =/ "DISPLAYFROM" / "DISPLAYTO"
1566. Security Considerations
158 This document defines an additional IMAP4 capability. As such, it
159 does not change the underlying security considerations of [IMAP].
160 The author believes that no new security issues are introduced with
161 this additional IMAP4 capability.
170Karp IMAP4 Display-Based Address Sorting [Page 3]
1757. Internationalization Considerations
177 DISPLAYFROM and DISPLAYTO are string-based sort criteria. As stated
178 in [SORT], the active [RFC4790] collation as per [RFC5255] MUST be
179 used when sorting such strings.
181 The DISPLAYFROM and DISPLAYTO orderings sort on the full decoded
182 [IMAP] addr-name, when present. They do not attempt to parse this
183 string in a locale- or language-dependent manner in order to
184 determine and sort on some semantically meaningful substring such as
1878. IANA Considerations
189 [IMAP] capabilities are registered by publishing a Standards Track or
190 IESG-approved Experimental RFC. This document constitutes
191 registration of the SORT=DISPLAY capability in the [IMAP]
192 capabilities registry.
1949. Normative References
196 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
197 4rev1", RFC 3501, March 2003.
199 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
200 Part Three: Message Header Extensions for Non-ASCII Text",
201 RFC 2047, November 1996.
203 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
204 Requirement Levels", BCP 14, RFC 2119, March 1997.
206 [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
207 Application Protocol Collation Registry", RFC 4790, March
210 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
211 Syntax Specifications: ABNF", STD 68, RFC 5234, January
214 [RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet
215 Message Access Protocol Internationalization", RFC 5255,
218 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
226Karp IMAP4 Display-Based Address Sorting [Page 4]
231 [SORT] Crispin, M. and K. Murchison, "Internet Message Access
232 Protocol - SORT and THREAD Extensions", RFC 5256, June
243 EMail: dkarp@zimbra.com
244 URI: http://www.zimbra.com
282Karp IMAP4 Display-Based Address Sorting [Page 5]