idnits 2.17.1 draft-ietf-morg-sortdisplay-00.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? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 (January 30, 2009) is 5537 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 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 4 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) January 30, 2009 5 Intended status: Standards Track 6 Expires: August 3, 2009 8 Display-based Address Sorting for the IMAP4 SORT Extension 9 draft-ietf-morg-sortdisplay-00 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 August 3, 2009. 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 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 This document describes an IMAP protocol extension enabling server- 49 side message sorting based on the commonly-displayed portion of the 50 From header. 52 Table of Contents 54 1. Conventions Used in This Document . . . . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. The DISPLAYFROM Sort Key . . . . . . . . . . . . . . . . . . . 3 57 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 59 6. Internationalization Considerations . . . . . . . . . . . . . . 4 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 61 8. Normative References . . . . . . . . . . . . . . . . . . . . . 4 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 address in the From header. This 79 document provides an alternate ordering, DISPLAYFROM, which sorts 80 messages lexically based on the From address's [RFC2822] display- 81 name, when present. 83 A server that supports the DISPLAYFROM sort criterion indicates this 84 by returning "SORT=DISPLAYFROM" in its CAPABILITY response. 86 3. The DISPLAYFROM Sort Key 88 This document introduces a new [SORT] sort-key, DISPLAYFROM. 90 A message's sort value under the DISPLAYFROM ordering MUST be derived 91 from the first [RFC2822] mailbox in its From header as follows: 93 o If the From header is absent or if the header contains no 94 mailboxes, the message's sort value is the empty string. 96 o If the mailbox contains an [RFC2822] display-name, replace each 97 instance of [RFC2822] CFWS in the display-name with a single 98 space, trim all leading and trailing whitespace, and decode any 99 [RFC2047] encoded-words. If the resulting string is not the empty 100 string, use it as the sort value for the message. 102 o Otherwise, completely remove all [RFC2822] CFWS from the mailbox's 103 [RFC2822] addr-spec and use the resulting string as the message's 104 sort value. 106 4. Formal Syntax 108 The following syntax specification uses the Augmented Backus-Naur 109 Form (ABNF) notation as specified in [RFC4234]. [IMAP] defines the 110 non-terminal "capability" and [SORT] defines "sort-key". 112 capability =/ "SORT=DISPLAYFROM" 114 sort-key =/ "DISPLAYFROM" 116 5. Security Considerations 118 This document defines an additional IMAP4 capability. As such, it 119 does not change the underlying security considerations of [IMAP]. 120 The author believes that no new security issues are introduced with 121 this additional IMAP4 capability. 123 6. Internationalization Considerations 125 DISPLAYFROM is a string-based sort criterion. As stated in [SORT], 126 the collations mandated by I18NLEVEL=1 or I18NLEVEL=2 from [RFC5255] 127 MUST be followed when sorting such strings. 129 The DISPLAYFROM ordering sorts on the full decoded [RFC2822] display- 130 name, when present. It does not attempt to parse this string in a 131 locale- or language-dependent manner in order to determine and sort 132 on some semantically meaningful substring such as the surname. 134 7. IANA Considerations 136 [IMAP] capabilities are registered by publishing a standards track or 137 IESG-approved experimental RFC. This document constitutes 138 registration of the SORT=DISPLAYFROM capability in the [IMAP] 139 capabilities registry. 141 8. Normative References 143 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 144 4rev1", RFC 3501, March 2003. 146 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 147 Part Three: Message Header Extensions for Non-ASCII Text", 148 RFC 2047, November 1996. 150 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 151 Requirement Levels", BCP 14, RFC 2119, March 1997. 153 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 154 April 2001. 156 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 157 Specifications: ABNF", RFC 4234, October 2005. 159 [RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet 160 Message Access Protocol Internationalization", RFC 5255, 161 June 2008. 163 [SORT] Crispin, M. and K. Murchison, "Internet Message Access 164 Protocol - SORT and THREAD Extensions", RFC 5256, 165 June 2008. 167 Author's Address 169 Dan Karp 170 Zimbra, a Yahoo! Company 171 701 First St. 172 Sunnyvale, CA 94089 173 USA 175 Email: dkarp@zimbra.com 176 URI: http://www.zimbra.com