idnits 2.17.1 draft-iceman-imap-specialuse-important-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 RFC6154, but the abstract doesn't seem to directly say this. It does mention RFC6154 though, so this could be OK. -- The draft header indicates that this document updates RFC3501, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3348, 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 RFC3348, updated by this document, for RFC5378 checks: 1998-08-14) (Using the creation date from RFC3501, updated by this document, for RFC5378 checks: 1997-09-12) -- 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 17, 2013) is 4089 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 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 3348 (Obsoleted by RFC 5258) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Leiba 3 Internet-Draft Huawei Technologies 4 Updates: 3348,3501,6154 E. Iceman 5 (if approved) Google, Inc. 6 Intended status: Standards Track January 17, 2013 7 Expires: July 21, 2013 9 IMAP LIST Special-Use Attribute: \Important 10 draft-iceman-imap-specialuse-important-01 12 Abstract 14 RFC 6154 created an IMAP Special-Use LIST extension and defined an 15 initial set of attributes. This document defines a new attribute, 16 "\Important", and establishes a new IANA registry for IMAP folder 17 attributes, updating RFCs 3348, 3501, and 6154. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 21, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Conventions used in this document . . . . . . . . . . . . . . 3 56 2. Definition of the 'Important' Attribute . . . . . . . . . . . 3 57 2.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. Creation of the IMAP LIST Special-Use Attributes Registry . . 4 64 4.2. Initial entries for the registry . . . . . . . . . . . . . . 5 65 4.3. Instructions to the Designated Expert . . . . . . . . . . . . 6 67 5. Changes During Document Development . . . . . . . . . . . . . 7 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 6.1. Normative References . . . . . . . . . . . . . . . . . . . . 7 71 6.2. Informative References . . . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 [RFC6154] defines an extension to the Internet Message Access 78 Protocol (IMAP) LIST command [RFC3501] for special-use mailboxes. 79 The extension allows servers to provide extra information 80 (attributes) about the purpose of a mailbox and defines an initial 81 set of special-use attributes. There are now three RFCs that define 82 mailbox attributes, and no registry for those attributes. 84 This document defines a new special-use attribute, "\Important", to 85 designate a mailbox that will hold messages that are considered 86 important for the user, by some externally defined criteria. This 87 document also creates a registry for IMAP mailbox attributes and 88 registers both the new attribute and those defined earlier, updating 89 [RFC3348], [RFC3501], and [RFC6154]. 91 1.1. Conventions used in this document 93 In examples, "C:" indicates lines sent by a client that is connected 94 to a server. "S:" indicates lines sent by the server to the client. 96 2. Definition of the 'Important' Attribute 98 The "\Important" mailbox attribute is a signal that the mailbox 99 contains messages that are likely important to the user. For 100 example, the system might automatically put messages there based on 101 available signals (such as who the message is from, who else the 102 message is addressed to, evaluation of the subject or content). Or 103 it might be a way for users to train the system as to what messages 104 are important (the system can learn patterns from the messages the 105 user copies to that mailbox). 107 [[anchor4: Possible change here: Cyrus has suggested (1) removal of 108 the last sentence above, about learning, and (2) definition of an 109 $Important message keyword, and reference to \Important as a virtual 110 mailbox to collect all such messages (as \Flagged does).]] 112 This is distinct from the "\Flagged" attribute in that evaluation of 113 importance here is based on heuristics, whereas "\Flagged" is 114 typically based on the setting of the IMAP flag of the same name. 116 2.1. Formal Syntax 118 The following syntax specification updates the one in [RFC6154], 119 Section 6, using Augmented Backus-Naur Form (ABNF) as described in 120 [RFC5234]. 122 use-attr =/ "\Important" 124 2.2. Example 126 In the following example, the mailbox called "Important Messages" is 127 the one designated with the "\Important" attribute. 129 C: t1 list "" "Imp*" 130 S: * LIST (\HasNoChildren \Important) "/" "Important Messages" 131 S: * LIST (\HasNoChildren) "/" "Imported Wine" 132 S: t1 OK Success 134 3. Security Considerations 136 The security considerations in [RFC6154], Section 7, apply equally to 137 this extension. In particular, "Conveying special-use information to 138 a client exposes a small bit of extra information that could be of 139 value to an attacker." Moreover, identifying a place where 140 "important" messages are kept could give an attacker a strategic 141 starting point. If the algorithm by which messages are determined to 142 be important is well known, still more information is exposed -- 143 perhaps, for example, there is an implication that the senders of 144 these messages are particularly significant to the mailbox owner, and 145 perhaps that is information that should not be made public. 147 As noted in RFC 6154, it is wise to protect the IMAP channel from 148 passive eavesdropping, and to defend against unauthorized discernment 149 of the identity of a user's "\Important" mailbox. 151 4. IANA Considerations 153 [[RFC Editor: Please replace "THIS RFC" throughout this section with 154 the identification given to this document, and remove this 155 paragraph.]] 157 4.1. Creation of the IMAP LIST Special-Use Attributes Registry 159 IANA is asked to create a new registry in the group "Internet Message 160 Access Protocol (IMAP) 4 Registries". The new registry will be 161 called "IMAP Mailbox Name Attributes", and will have two references: 162 RFC 3501, Section 7.2.2, and THIS RFC, Section 4. 164 The registry entries will contain three fields: 166 1. Attribute Name 167 2. Description 168 3. Reference 170 IANA will keep this list in alphabetical order by Attribute Name, 171 which is registered without the initial backslash ("\"). 173 New registrations will be accepted through the Expert Review policy 174 [RFC5226] (and see Section 4.3). New registrations are requested 175 through the IANA Considerations section in an RFC, or, for requests 176 that do not come from an RFC, by sending email to IANA asking for a 177 new IMAP Mailbox Name Attribute and giving the requested values for 178 each of the three fields. 180 4.2. Initial entries for the registry 182 The registry will initially contain these entries: 184 +===============+===================================+===========+ 185 | Attribute | Description | Reference | 186 | Name | | | 187 +===============+===================================+===========+ 188 | All | All messages | [RFC6154] | 189 +---------------+-----------------------------------+-----------+ 190 | Archive | Archived messages | [RFC6154] | 191 +---------------+-----------------------------------+-----------+ 192 | Drafts | Messages that are working drafts | [RFC6154] | 193 +---------------+-----------------------------------+-----------+ 194 | Flagged | Messages with the \Flagged flag | [RFC6154] | 195 +---------------+-----------------------------------+-----------+ 196 | HasChildren | Has accessible child mailboxes | [RFC3348] | 197 +---------------+-----------------------------------+-----------+ 198 | HasNoChildren | Has no accessible child mailboxes | [RFC3348] | 199 +---------------+-----------------------------------+-----------+ 200 | Important | Messages deemed important to user | THIS RFC | 201 +---------------+-----------------------------------+-----------+ 202 | Junk | Messages identified as Spam/Junk | [RFC6154] | 203 +---------------+-----------------------------------+-----------+ 204 | Marked | Server has marked the mailbox as | [RFC3501] | 205 | | "interesting" | | 206 +---------------+-----------------------------------+-----------+ 207 | NoInferiors | No hierarchy under this name | [RFC3501] | 208 +---------------+-----------------------------------+-----------+ 209 | Noselect | The mailbox is not selectable | [RFC3501] | 210 +---------------+-----------------------------------+-----------+ 211 | Sent | Sent mail | [RFC6154] | 212 +---------------+-----------------------------------+-----------+ 213 | Trash | Messages the user has discarded | [RFC6154] | 214 +---------------+-----------------------------------+-----------+ 215 | Unmarked | No new messages since last select | [RFC3501] | 216 +===============+===================================+===========+ 218 4.3. Instructions to the Designated Expert 220 The expert reviewer, who will be designated by the IESG, is expected 221 to provide only a general review of the requested registration, 222 checking that the reference and description are adequate for 223 understanding the intent of the registered attribute. Efforts should 224 also be made to generalize the intent of an attribute so that 225 multiple implementations with the same requirements may reuse 226 existing attributes. Except for this check, this is intended to be 227 very close to a first come first served policy, and the expert should 228 not block serious registration requests with a reasonable reference. 229 The reference may be to any form of documentation, including a web 230 page, but consideration should be given to providing one that is 231 expected to be long-lived and stable. 233 5. Changes During Document Development 235 [[anchor11: RFC Editor: Please remove this section prior to 236 publication.]] 238 Changes in -01 239 o Expanded the new registry to all mailbox name attributes, and 240 added the attributes from 3501 and 3348 (suggested by Alexey). 241 This also adds those two documents to the "updates" list. 242 o Recorded Cyrus's suggestion to define $Important. 244 6. References 246 6.1. Normative References 248 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 249 4rev1", RFC 3501, March 2003. 251 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 252 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 253 May 2008. 255 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 256 Specifications: ABNF", STD 68, RFC 5234, January 2008. 258 [RFC6154] Leiba, B. and J. Nicolson, "IMAP LIST Extension for 259 Special-Use Mailboxes", RFC 6154, March 2011. 261 6.2. Informative References 263 [RFC3348] Gahrns, M. and R. Cheng, "The Internet Message Action 264 Protocol (IMAP4) Child Mailbox Extension", RFC 3348, 265 July 2002. 267 Authors' Addresses 269 Barry Leiba 270 Huawei Technologies 272 Phone: +1 646 827 0648 273 Email: barryleiba@computer.org 274 URI: http://internetmessagingtechnology.org/ 275 Eric Iceman 276 Google, Inc. 278 Email: iceman@google.com