idnits 2.17.1 draft-karp-morg-sortdisplay-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 183. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 194. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 201. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 207. 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 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 (June 10, 2008) is 5797 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 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 8 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) June 10, 2008 5 Intended status: Standards Track 6 Expires: December 12, 2008 8 Display-based Address Sorting for the IMAP4 SORT Extension 9 draft-karp-morg-sortdisplay-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 12, 2008. 36 Abstract 38 This document describes an IMAP protocol extension enabling server- 39 side message sorting based on the commonly-displayed portion of the 40 From header. 42 Table of Contents 44 1. Conventions Used in This Document . . . . . . . . . . . . . . . 3 45 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 3. The DISPLAYFROM Sort Key . . . . . . . . . . . . . . . . . . . 3 47 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4 48 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 49 6. Internationalization Considerations . . . . . . . . . . . . . . 4 50 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 51 8. Normative References . . . . . . . . . . . . . . . . . . . . . 4 52 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 Intellectual Property and Copyright Statements . . . . . . . . . . 6 55 1. Conventions Used in This Document 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in [RFC2119]. 61 2. Introduction 63 The [SORT] extension to the [IMAP] protocol provides a means for 64 server-based sorting of messages. It defines a set of sort criteria 65 and the mechanism for determining the sort value of a message for 66 each such ordering. 68 The [SORT] extension's FROM ordering sorts messages lexically on the 69 [IMAP] addr-part of the first address in the From header. This 70 document provides an alternate ordering, DISPLAYFROM, which sorts 71 messages lexically based on the From address's [RFC2822] display- 72 name, when present. 74 A server that supports the DISPLAYFROM sort criterion indicates this 75 by returning "SORT=DISPLAYFROM" in its CAPABILITY response. 77 3. The DISPLAYFROM Sort Key 79 This document introduces a new [SORT] sort-key, DISPLAYFROM. 81 A message's sort value under the DISPLAYFROM ordering MUST be derived 82 from the first [RFC2822] mailbox in its From header as follows: 84 o If the From header is absent or if the header contains no 85 mailboxes, the message's sort value is the empty string. 87 o If the mailbox contains an [RFC2822] display-name, replace each 88 instance of [RFC2822] CFWS in the display-name with a single 89 space, trim all leading and trailing whitespace, and decode any 90 [RFC2047] encoded-words. If the resulting string is not the empty 91 string, use it as the sort value for the message. 93 o Otherwise, completely remove all [RFC2822] CFWS from the mailbox's 94 [RFC2822] addr-spec and use the resulting string as the message's 95 sort value. 97 4. Formal Syntax 99 The following syntax specification uses the Augmented Backus-Naur 100 Form (ABNF) notation as specified in [RFC2234]. [IMAP] defines the 101 non-terminal "capability" and [SORT] defines "sort-key". 103 capability =/ "SORT=DISPLAYFROM" 105 sort-key =/ "DISPLAYFROM" 107 5. Security Considerations 109 This document defines an additional IMAP4 capability. As such, it 110 does not change the underlying security considerations of [IMAP]. 111 The author believes that no new security issues are introduced with 112 this additional IMAP4 capability. 114 6. Internationalization Considerations 116 DISPLAYFROM is a string-based sort criterion. As stated in [SORT], 117 the collations mandated by I18NLEVEL=1 or I18NLEVEL=2 from [RFC5255] 118 MUST be followed when sorting such strings. 120 The DISPLAYFROM ordering sorts on the full decoded [RFC2822] display- 121 name, when present. It does not attempt to parse this string in a 122 locale- or language-dependent manner in order to determine and sort 123 on some semantically meaningful substring such as the surname. 125 7. IANA Considerations 127 [IMAP] capabilities are registered by publishing a standards track or 128 IESG-approved experimental RFC. This document constitutes 129 registration of the SORT=DISPLAYFROM capability in the [IMAP] 130 capabilities registry. 132 8. Normative References 134 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 135 4rev1", RFC 3501, March 2003. 137 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 138 Part Three: Message Header Extensions for Non-ASCII Text", 139 RFC 2047, November 1996. 141 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 142 Requirement Levels", BCP 14, RFC 2119, March 1997. 144 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 145 Specifications: ABNF", RFC 2234, November 1997. 147 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 148 April 2001. 150 [RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet 151 Message Access Protocol Internationalization", RFC 5255, 152 June 2008. 154 [SORT] Crispin, M. and K. Murchison, "Internet Message Access 155 Protocol - SORT and THREAD Extensions", RFC 5256, 156 June 2008. 158 Author's Address 160 Dan Karp 161 Zimbra, a Yahoo! Company 162 701 First St. 163 Sunnyvale, CA 94089 164 USA 166 Email: dkarp@zimbra.com 167 URI: http://www.zimbra.com 169 Full Copyright Statement 171 Copyright (C) The IETF Trust (2008). 173 This document is subject to the rights, licenses and restrictions 174 contained in BCP 78, and except as set forth therein, the authors 175 retain all their rights. 177 This document and the information contained herein are provided on an 178 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 179 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 180 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 181 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 182 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 183 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 185 Intellectual Property 187 The IETF takes no position regarding the validity or scope of any 188 Intellectual Property Rights or other rights that might be claimed to 189 pertain to the implementation or use of the technology described in 190 this document or the extent to which any license under such rights 191 might or might not be available; nor does it represent that it has 192 made any independent effort to identify any such rights. Information 193 on the procedures with respect to rights in RFC documents can be 194 found in BCP 78 and BCP 79. 196 Copies of IPR disclosures made to the IETF Secretariat and any 197 assurances of licenses to be made available, or the result of an 198 attempt made to obtain a general license or permission for the use of 199 such proprietary rights by implementers or users of this 200 specification can be obtained from the IETF on-line IPR repository at 201 http://www.ietf.org/ipr. 203 The IETF invites any interested party to bring to its attention any 204 copyrights, patents or patent applications, or other proprietary 205 rights that may cover technology that may be required to implement 206 this standard. Please address the information to the IETF at 207 ietf-ipr@ietf.org.