idnits 2.17.1 draft-ietf-morg-sortdisplay-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5256, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5256, updated by this document, for RFC5378 checks: 2000-02-07) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 29, 2009) is 5316 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Message Organization Working Group D. Karp 3 Internet-Draft Zimbra 4 Updates: 5256 (if approved) September 29, 2009 5 Intended status: Standards Track 6 Expires: April 2, 2010 8 Display-based Address Sorting for the IMAP4 SORT Extension 9 draft-ietf-morg-sortdisplay-01 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 2, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document describes an IMAP protocol extension enabling server- 48 side message sorting based on the commonly-displayed portion of the 49 From and To header fields. 51 Table of Contents 53 1. Conventions Used in This Document . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. DISPLAY Sort Value for a Mailbox . . . . . . . . . . . . . . . 3 56 4. The DISPLAYFROM and DISPLAYTO Sort Keys . . . . . . . . . . . . 3 57 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 59 7. Internationalization Considerations . . . . . . . . . . . . . . 4 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 61 9. Normative References . . . . . . . . . . . . . . . . . . . . . 5 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 1. Conventions Used in This Document 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in [RFC2119]. 70 2. Introduction 72 The [SORT] extension to the [IMAP] protocol provides a means for 73 server-based sorting of messages. It defines a set of sort criteria 74 and the mechanism for determining the sort value of a message for 75 each such ordering. 77 The [SORT] extension's FROM ordering sorts messages lexically on the 78 [IMAP] addr-part of the first mailbox in the From header. Likewise, 79 its TO ordering sorts on the [IMAP] addr-part of the first address in 80 the message's To header. This document provides two alternate 81 orderings, DISPLAYFROM and DISPLAYTO, which sort messages lexically 82 based on the first From or To address's [RFC5322] display-name, when 83 present. 85 A server that supports the full [SORT] extension as well as the 86 DISPLAYFROM and DISPLAYTO sort criteria indicates this by returning 87 "SORT=DISPLAY" in its CAPABILITY response. 89 3. DISPLAY Sort Value for a Mailbox 91 For the purposes of the sort keys defined in this document, the sort 92 value for an [RFC5322] mailbox is defined as follows: 94 o If the mailbox contains an [RFC5322] display-name, replace each 95 instance of [RFC5322] CFWS in the display-name with a single 96 space, trim leading and trailing whitespace, and decode any 97 quoted-strings and [RFC2047] encoded-words. If the resulting 98 string is not the empty string, use it as the sort value for the 99 mailbox. 101 o Otherwise, completely remove all [RFC5322] FWS and CFWS from the 102 mailbox's [RFC5322] addr-spec and use the resulting string as the 103 mailbox's sort value. 105 4. The DISPLAYFROM and DISPLAYTO Sort Keys 107 This document introduces two new [SORT] sort-keys, DISPLAYFROM and 108 DISPLAYTO. 110 A message's sort value under the DISPLAYFROM ordering MUST be derived 111 as follows: 113 o If the message's From header is absent or if the header contains 114 no [RFC5322] mailboxes, the message's sort value is the empty 115 string. 117 o Otherwise, the message's sort value is the DISPLAY sort value of 118 the first mailbox in its From header. 120 A message's sort value under the DISPLAYTO ordering MUST be derived 121 as follows: 123 o If the message's To header is absent or if the header contains no 124 [RFC5322] addresses, the message's sort value is the empty string. 126 o If the first address in the message's To header is an [RFC5322] 127 group, the message's sort value is the group's display-name. 129 o Otherwise, the message's sort value is the DISPLAY sort value of 130 the first [RFC5322] mailbox in its To header. 132 5. Formal Syntax 134 The following syntax specification uses the Augmented Backus-Naur 135 Form (ABNF) notation as specified in [RFC4234]. [IMAP] defines the 136 non-terminal "capability" and [SORT] defines "sort-key". 138 capability =/ "SORT=DISPLAY" 140 sort-key =/ "DISPLAYFROM" | "DISPLAYTO" 142 6. Security Considerations 144 This document defines an additional IMAP4 capability. As such, it 145 does not change the underlying security considerations of [IMAP]. 146 The author believes that no new security issues are introduced with 147 this additional IMAP4 capability. 149 7. Internationalization Considerations 151 DISPLAYFROM and DISPLAYTO are string-based sort criteria. As stated 152 in [SORT], the collations mandated by I18NLEVEL=1 or I18NLEVEL=2 from 153 [RFC5255] MUST be followed when sorting such strings. 155 The DISPLAYFROM and DISPLAYTO orderings sort on the full decoded 156 [RFC5322] display-name, when present. They do not attempt to parse 157 this string in a locale- or language-dependent manner in order to 158 determine and sort on some semantically meaningful substring such as 159 the surname. 161 8. IANA Considerations 163 [IMAP] capabilities are registered by publishing a standards track or 164 IESG-approved experimental RFC. This document constitutes 165 registration of the SORT=DISPLAY capability in the [IMAP] 166 capabilities registry. 168 9. Normative References 170 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 171 4rev1", RFC 3501, March 2003. 173 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 174 Part Three: Message Header Extensions for Non-ASCII Text", 175 RFC 2047, November 1996. 177 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 178 Requirement Levels", BCP 14, RFC 2119, March 1997. 180 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 181 Specifications: ABNF", RFC 4234, October 2005. 183 [RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet 184 Message Access Protocol Internationalization", RFC 5255, 185 June 2008. 187 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 188 October 2008. 190 [SORT] Crispin, M. and K. Murchison, "Internet Message Access 191 Protocol - SORT and THREAD Extensions", RFC 5256, 192 June 2008. 194 Author's Address 196 Dan Karp 197 Zimbra 198 701 First St. 199 Sunnyvale, CA 94089 200 USA 202 Email: dkarp@zimbra.com 203 URI: http://www.zimbra.com