idnits 2.17.1 draft-ietf-morg-sortdisplay-02.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 (October 18, 2009) is 5303 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) October 18, 2009 5 Intended status: Standards Track 6 Expires: April 21, 2010 8 Display-based Address Sorting for the IMAP4 SORT Extension 9 draft-ietf-morg-sortdisplay-02 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 21, 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 an Address . . . . . . . . . . . . . . . 3 56 4. The DISPLAYFROM and DISPLAYTO Sort Keys . . . . . . . . . . . . 4 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-mailbox of the first mailbox in the From header. 79 Likewise, its TO ordering sorts on the [IMAP] addr-mailbox of the 80 first address in the message's To header. This document provides two 81 alternate orderings, DISPLAYFROM and DISPLAYTO, which sort messages 82 lexically based on the first From or To address's [IMAP] addr-name 83 (generally the same as its [RFC5322] display-name), when 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 an Address 91 For the purposes of the sort keys defined in this document, the sort 92 value for an [IMAP] address structure is defined as follows: 94 o If the address structure's [IMAP] addr-name is non-NIL, decode any 95 [RFC2047] encoded-words. If the resulting string is not the empty 96 string, use it as the sort value for the address. 98 o Otherwise, if the address structure's [IMAP] addr-mailbox and 99 [IMAP] addr-host are both non-NIL, the sort value for the address 100 is addr-mailbox@addr-host. 102 o Otherwise, if the address structure's [IMAP] addr-mailbox is non- 103 NIL, the sort value for the address is its addr-mailbox. 105 o If none of the above conditions are met, the sort value for the 106 address is the empty string. 108 4. The DISPLAYFROM and DISPLAYTO Sort Keys 110 This document introduces two new [SORT] sort-keys, DISPLAYFROM and 111 DISPLAYTO. 113 A message's sort value under the DISPLAYFROM ordering MUST be derived 114 as follows from the [IMAP] env-from value of the [IMAP] envelope 115 structure resulting from a FETCH ENVELOPE on the message: 117 o If the env-from value is NIL, the message's sort value is the 118 empty string. 120 o Otherwise, the message's sort value is the DISPLAY sort value of 121 the first [IMAP] address in the envelope structure's env-from. 123 A message's sort value under the DISPLAYTO ordering MUST be derived 124 as follows from the [IMAP] env-to value of the [IMAP] envelope 125 structure resulting from a FETCH ENVELOPE on the message: 127 o If the env-to value is NIL, the message's sort value is the empty 128 string. 130 o Otherwise, the message's sort value is the DISPLAY sort value of 131 the first [IMAP] address in the envelope structure's env-to. 133 5. Formal Syntax 135 The following syntax specification uses the Augmented Backus-Naur 136 Form (ABNF) notation as specified in [RFC4234]. [IMAP] defines the 137 non-terminal "capability" and [SORT] defines "sort-key". 139 capability =/ "SORT=DISPLAY" 141 sort-key =/ "DISPLAYFROM" | "DISPLAYTO" 143 6. Security Considerations 145 This document defines an additional IMAP4 capability. As such, it 146 does not change the underlying security considerations of [IMAP]. 147 The author believes that no new security issues are introduced with 148 this additional IMAP4 capability. 150 7. Internationalization Considerations 152 DISPLAYFROM and DISPLAYTO are string-based sort criteria. As stated 153 in [SORT], the collations mandated by I18NLEVEL=1 or I18NLEVEL=2 from 154 [RFC5255] MUST be followed when sorting such strings. 156 The DISPLAYFROM and DISPLAYTO orderings sort on the full decoded 157 [IMAP] addr-name, when present. They do not attempt to parse this 158 string in a locale- or language-dependent manner in order to 159 determine and sort on some semantically meaningful substring such as 160 the surname. 162 8. IANA Considerations 164 [IMAP] capabilities are registered by publishing a standards track or 165 IESG-approved experimental RFC. This document constitutes 166 registration of the SORT=DISPLAY capability in the [IMAP] 167 capabilities registry. 169 9. Normative References 171 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 172 4rev1", RFC 3501, March 2003. 174 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 175 Part Three: Message Header Extensions for Non-ASCII Text", 176 RFC 2047, November 1996. 178 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 179 Requirement Levels", BCP 14, RFC 2119, March 1997. 181 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 182 Specifications: ABNF", RFC 4234, October 2005. 184 [RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet 185 Message Access Protocol Internationalization", RFC 5255, 186 June 2008. 188 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 189 October 2008. 191 [SORT] Crispin, M. and K. Murchison, "Internet Message Access 192 Protocol - SORT and THREAD Extensions", RFC 5256, 193 June 2008. 195 Author's Address 197 Dan Karp 198 Zimbra 199 701 First St. 200 Sunnyvale, CA 94089 201 USA 203 Email: dkarp@zimbra.com 204 URI: http://www.zimbra.com