284 lines
8.5 KiB
Plaintext
284 lines
8.5 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Internet Engineering Task Force (IETF) D. Karp
|
||
Request for Comments: 5957 Zimbra
|
||
Updates: 5256 July 2010
|
||
Category: Standards Track
|
||
ISSN: 2070-1721
|
||
|
||
|
||
Display-Based Address Sorting for the IMAP4 SORT Extension
|
||
|
||
Abstract
|
||
|
||
This document describes an IMAP protocol extension enabling server-
|
||
side message sorting on the commonly displayed portion of the From
|
||
and To header fields.
|
||
|
||
Status of This Memo
|
||
|
||
This is an Internet Standards Track document.
|
||
|
||
This document is a product of the Internet Engineering Task Force
|
||
(IETF). It represents the consensus of the IETF community. It has
|
||
received public review and has been approved for publication by the
|
||
Internet Engineering Steering Group (IESG). Further information on
|
||
Internet Standards is available in Section 2 of RFC 5741.
|
||
|
||
Information about the current status of this document, any errata,
|
||
and how to provide feedback on it may be obtained at
|
||
http://www.rfc-editor.org/info/rfc5957.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (c) 2010 IETF Trust and the persons identified as the
|
||
document authors. All rights reserved.
|
||
|
||
This document is subject to BCP 78 and the IETF Trust's Legal
|
||
Provisions Relating to IETF Documents
|
||
(http://trustee.ietf.org/license-info) in effect on the date of
|
||
publication of this document. Please review these documents
|
||
carefully, as they describe your rights and restrictions with respect
|
||
to this document. Code Components extracted from this document must
|
||
include Simplified BSD License text as described in Section 4.e of
|
||
the Trust Legal Provisions and are provided without warranty as
|
||
described in the Simplified BSD License.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Karp IMAP4 Display-Based Address Sorting [Page 1]
|
||
|
||
RFC 5957 July 2010
|
||
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction ....................................................2
|
||
2. Conventions Used in This Document ...............................2
|
||
3. DISPLAY Sort Value for an Address ...............................2
|
||
4. The DISPLAYFROM and DISPLAYTO Sort Criteria .....................3
|
||
5. Formal Syntax ...................................................3
|
||
6. Security Considerations .........................................3
|
||
7. Internationalization Considerations .............................4
|
||
8. IANA Considerations .............................................4
|
||
9. Normative References ............................................4
|
||
|
||
1. Introduction
|
||
|
||
The [SORT] extension to the [IMAP] protocol provides a means for the
|
||
server-based sorting of messages. It defines a set of sort criteria
|
||
and the mechanism for determining the sort value of a message for
|
||
each such ordering.
|
||
|
||
The [SORT] FROM and TO orderings sort messages lexically on the
|
||
[IMAP] addr-mailbox of the first address in the message's From and To
|
||
headers, respectively. This document provides two alternative
|
||
orderings, DISPLAYFROM and DISPLAYTO, which sort messages based on
|
||
the first From or To address's [IMAP] addr-name (generally the same
|
||
as its [RFC5322] display-name), when present.
|
||
|
||
A server that supports the full [SORT] extension as well as both the
|
||
DISPLAYFROM and DISPLAYTO sort criteria indicates this by returning
|
||
"SORT=DISPLAY" in its CAPABILITY response.
|
||
|
||
2. Conventions Used in This Document
|
||
|
||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||
document are to be interpreted as described in [RFC2119].
|
||
|
||
3. DISPLAY Sort Value for an Address
|
||
|
||
For the purposes of the sort criteria defined in this document, the
|
||
sort value for an [IMAP] address structure is defined as follows:
|
||
|
||
o If the address structure's [IMAP] addr-name is non-NIL, apply the
|
||
procedure from [RFC5255], Section 4.6. (That is, decode any
|
||
[RFC2047] encoded-words and convert the resulting character string
|
||
into a charset valid for the currently active [RFC4790] collation,
|
||
with a default of UTF-8.) If the resulting octet string is not
|
||
the empty string, use it as the sort value for the address.
|
||
|
||
|
||
|
||
|
||
Karp IMAP4 Display-Based Address Sorting [Page 2]
|
||
|
||
RFC 5957 July 2010
|
||
|
||
|
||
o Otherwise, if the address structure's [IMAP] addr-mailbox and
|
||
[IMAP] addr-host are both non-NIL, the sort value for the address
|
||
is addr-mailbox@addr-host.
|
||
|
||
o Otherwise, if the address structure's [IMAP] addr-mailbox is non-
|
||
NIL, the sort value for the address is its addr-mailbox.
|
||
|
||
o If none of the above conditions are met, the sort value for the
|
||
address is the empty string.
|
||
|
||
4. The DISPLAYFROM and DISPLAYTO Sort Criteria
|
||
|
||
This document introduces two new [SORT] sort criteria, DISPLAYFROM
|
||
and DISPLAYTO. A message's sort value under these orderings MUST be
|
||
derived as follows:
|
||
|
||
A "derived-addr" value is created from the [IMAP] envelope structure
|
||
resulting from a FETCH ENVELOPE on the message. For DISPLAYFROM, the
|
||
derived-addr value is the [IMAP] env-from value. For DISPLAYTO, the
|
||
derived-addr value is the [IMAP] env-to value.
|
||
|
||
o If the derived-addr value is NIL, the message's sort value is the
|
||
empty string.
|
||
|
||
o Otherwise, the message's sort value is the DISPLAY sort value of
|
||
the first [IMAP] address in the derived-addr value.
|
||
|
||
5. Formal Syntax
|
||
|
||
The following syntax specification uses the Augmented Backus-Naur
|
||
Form (ABNF) notation as specified in [RFC5234]. [IMAP] defines the
|
||
non-terminal "capability", and [SORT] defines "sort-key".
|
||
|
||
capability =/ "SORT=DISPLAY"
|
||
|
||
sort-key =/ "DISPLAYFROM" / "DISPLAYTO"
|
||
|
||
6. Security Considerations
|
||
|
||
This document defines an additional IMAP4 capability. As such, it
|
||
does not change the underlying security considerations of [IMAP].
|
||
The author believes that no new security issues are introduced with
|
||
this additional IMAP4 capability.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Karp IMAP4 Display-Based Address Sorting [Page 3]
|
||
|
||
RFC 5957 July 2010
|
||
|
||
|
||
7. Internationalization Considerations
|
||
|
||
DISPLAYFROM and DISPLAYTO are string-based sort criteria. As stated
|
||
in [SORT], the active [RFC4790] collation as per [RFC5255] MUST be
|
||
used when sorting such strings.
|
||
|
||
The DISPLAYFROM and DISPLAYTO orderings sort on the full decoded
|
||
[IMAP] addr-name, when present. They do not attempt to parse this
|
||
string in a locale- or language-dependent manner in order to
|
||
determine and sort on some semantically meaningful substring such as
|
||
the surname.
|
||
|
||
8. IANA Considerations
|
||
|
||
[IMAP] capabilities are registered by publishing a Standards Track or
|
||
IESG-approved Experimental RFC. This document constitutes
|
||
registration of the SORT=DISPLAY capability in the [IMAP]
|
||
capabilities registry.
|
||
|
||
9. Normative References
|
||
|
||
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
|
||
4rev1", RFC 3501, March 2003.
|
||
|
||
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
|
||
Part Three: Message Header Extensions for Non-ASCII Text",
|
||
RFC 2047, November 1996.
|
||
|
||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
|
||
Application Protocol Collation Registry", RFC 4790, March
|
||
2007.
|
||
|
||
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
|
||
Syntax Specifications: ABNF", STD 68, RFC 5234, January
|
||
2008.
|
||
|
||
[RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet
|
||
Message Access Protocol Internationalization", RFC 5255,
|
||
June 2008.
|
||
|
||
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
|
||
October 2008.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Karp IMAP4 Display-Based Address Sorting [Page 4]
|
||
|
||
RFC 5957 July 2010
|
||
|
||
|
||
[SORT] Crispin, M. and K. Murchison, "Internet Message Access
|
||
Protocol - SORT and THREAD Extensions", RFC 5256, June
|
||
2008.
|
||
|
||
Author's Address
|
||
|
||
Dan Karp
|
||
Zimbra
|
||
3401 Hillview Avenue
|
||
Palo Alto, CA 94304
|
||
USA
|
||
|
||
EMail: dkarp@zimbra.com
|
||
URI: http://www.zimbra.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Karp IMAP4 Display-Based Address Sorting [Page 5]
|
||
|