idnits 2.17.1 draft-iceman-imap-specialuse-important-02.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (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 (April 15, 2013) is 4028 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 (~~), 2 warnings (==), 5 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: 3501,6154 (if approved) E. Iceman 5 Intended status: Standards Track Google, Inc. 6 Expires: October 15, 2013 April 15, 2013 8 IMAP $Important Keyword and \Important Special-Use Attribute 9 draft-iceman-imap-specialuse-important-02 11 Abstract 13 RFC 6154 created an IMAP Special-Use LIST extension and defined an 14 initial set of attributes. This document defines a new attribute, 15 "\Important", and establishes a new IANA registry for IMAP folder 16 attributes, registering the attributes defined in RFCs 3348, 3501, 17 and 6154. This document also defines a new IMAP keyword, 18 "$Important", and registers it in the registry defined in RFC 5788. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on October 15, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Conventions used in this document . . . . . . . . . . . . . 2 55 2. Definition of the '$Important' Message Keyword . . . . . . . . 2 56 3. Definition of the 'Important' Mailbox Attribute . . . . . . . 3 57 3.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 5.1. Registration of the $Important keyword . . . . . . . . . . . 4 62 5.2. Creation of the IMAP Mailbox Name Attributes Registry . . . 5 63 5.2.1. Instructions to the Designated Expert . . . . . . . . . . 5 64 5.3. Initial Entries for the IMAP Mailbox Name Attributes Registry 5 65 6. Changes During Document Development . . . . . . . . . . . . . 6 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 7.1. Normative References . . . . . . . . . . . . . . . . . . . . 7 68 7.2. Informative References . . . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 The Internet Message Access Protocol (IMAP) specification [RFC3501] 74 defines the use of message keywords, and an IMAP Keywords registry is 75 created in [RFC5788]. [RFC6154] defines an extension to the IMAP 76 LIST command for special-use mailboxes. The extension allows servers 77 to provide extra information (attributes) about the purpose of a 78 mailbox and defines an initial set of special-use attributes. 80 This document does the following: 82 o Defines a new message keyword, "$Important", to apply to messages 83 that are considered important for the user, by some externally 84 defined criteria. 86 o Registers the "$Important" keyword in the IMAP Keywords registry. 88 o Defines a new special-use attribute, "\Important", to designate a 89 mailbox that will hold messages that are considered important for 90 the user, by some externally defined criteria. 92 o Creates a registry for IMAP mailbox attributes and registers the 93 new attribute and those defined in [RFC3348], [RFC3501], and 94 [RFC6154]. 96 1.1. Conventions used in this document 98 In examples, "C:" indicates lines sent by a client that is connected 99 to a server. "S:" indicates lines sent by the server to the client. 101 2. Definition of the '$Important' Message Keyword 103 The "$Important" keyword is a signal that a message is likely 104 important to the user. The keyword can be set by the user, or 105 automatically by the system based on available signals (such as who 106 the message is from, who else the message is addressed to, evaluation 107 of the subject or content, or other heuristics). 109 This is distinct from the "\Flagged" system flag in two ways: 111 1. "$Important" carries a specific meaning of importance, as opposed 112 to urgency. It is meant to be used for a form of triage, with 113 "\Flagged" remaining as a designation of special attention or 114 particular urgency. 116 2. The setting of "$Important" is expected to be based at least 117 partly on heuristics, whereas "\Flagged" is intended to be set by 118 the user. 120 3. Definition of the 'Important' Mailbox Attribute 122 The "\Important" mailbox attribute is a signal that the mailbox 123 contains messages that are likely important to the user. In an 124 implementation that also supports the "$Important" keyword, this 125 special use is likely to represent a virtual mailbox collecting 126 messages (from other mailboxes) that are marked with the "$Important" 127 keyword. In other implementations, the system might automatically 128 put messages there based on the same sorts of heuristics that are 129 noted for the "$Important" keyword (see Section 2). The distinction 130 between "\Important" and "\Flagged" for mailboxes is similar to those 131 between "$Important" and "\Flagged" for messages. 133 3.1. Formal Syntax 135 The following syntax specification adds to the one in [RFC6154], 136 Section 6, using Augmented Backus-Naur Form (ABNF) as described in 137 [RFC5234]. 139 use-attr =/ "\Important" 141 3.2. Example 143 In the following example, the mailbox called "Important Messages" is 144 the one designated with the "\Important" attribute. 146 C: t1 list "" "Imp*" 147 S: * LIST (\HasNoChildren \Important) "/" "Important Messages" 148 S: * LIST (\HasNoChildren) "/" "Imported Wine" 149 S: t1 OK Success 151 4. Security Considerations 153 The security considerations in [RFC6154], Section 7, apply equally to 154 this extension. In particular, "Conveying special-use information to 155 a client exposes a small bit of extra information that could be of 156 value to an attacker." Moreover, identifying "important" messages or 157 a place where important messages are kept could give an attacker a 158 strategic starting point. If the algorithm by which messages are 159 determined to be important is well known, still more information is 160 exposed -- perhaps, for example, there is an implication that the 161 senders of these messages are particularly significant to the mailbox 162 owner, and perhaps that is information that should not be made 163 public. 165 As noted in RFC 6154, it is wise to protect the IMAP channel from 166 passive eavesdropping, and to defend against unauthorized discernment 167 of the identity of a user's "\Important" mailbox or of a user's 168 "$Important" messages. 170 5. IANA Considerations 172 This document contains 3 actions for IANA, specified in the sections 173 below: 175 1. Registration of the "$Important" keyword. 177 2. Creation of a new "IMAP Mailbox Name Attributes" registry. 179 3. Registration of initial entries in the "IMAP Mailbox Name 180 Attributes" registry. 182 5.1. Registration of the $Important keyword 184 IANA is asked to register the $Important keyword in the "IMAP 185 Keywords" registry, as follows, using the template in [RFC5788]. 187 IMAP keyword name: $Important 189 Purpose (description): The "$Important" keyword is a signal that a 190 message is likely important to the user. 192 Private or Shared on a server: PRIVATE 194 Is it an advisory keyword or may it cause an automatic action: Adviso 195 ry (but see the reference for details). 197 When/by whom the keyword is set/cleared: The keyword can be set by 198 the user, or automatically by the system based on available 199 signals (such as who the message is from, who else the message 200 is addressed to, evaluation of the subject or content, or other 201 heuristics). 203 Related keywords: None (but see the reference for the related mailbox 204 name attribute). 206 Related IMAP capabilities: None. 208 Security considerations: See [[THIS RFC]], Section 4 210 Published specification: [[THIS RFC]] 212 Person & email address to contact for further information: IETF Appli 213 cations Area 215 Intended usage: COMMON 217 Owner/Change controller: IESG 218 Note: None. 220 5.2. Creation of the IMAP Mailbox Name Attributes Registry 222 IANA is asked to create a new registry in the group "Internet Message 223 Access Protocol (IMAP)". The new registry will be called "IMAP 224 Mailbox Name Attributes", and will have two references: "RFC 3501, 225 Section 7.2.2", and "[[THIS RFC]], Section 5". 227 The registry entries will contain three fields: 229 1. Attribute Name 231 2. Description 233 3. Reference 235 IANA will keep this list in alphabetical order by Attribute Name, 236 which is registered without the initial backslash ("\"). 238 The registration policy for the new registry will be listed as "IETF 239 Review or Expert Review" [RFC5226], and new registrations will be 240 accepted in one of two ways: 242 1. For registrations requested in an IETF consensus document, the 243 registration policy will be IETF Review, and the request will be 244 made in the IANA Considerations section of the document, giving 245 the requested values for each of the three fields. 247 2. For other registrations, the policy will be Expert Review policy 248 (see Section 5.2.1), and the request will be made by sending 249 email to IANA asking for a new IMAP Mailbox Name Attribute and 250 giving the requested values for each of the three fields. 252 5.2.1. Instructions to the Designated Expert 254 The expert reviewer, who will be designated by the IESG, is expected 255 to provide only a general review of the requested registration, 256 checking that the reference and description are adequate for 257 understanding the intent of the registered attribute. Efforts should 258 also be made to generalize the intent of an attribute so that 259 multiple implementations with the same requirements may reuse 260 existing attributes. Except for this check, this is intended to be 261 very close to a first come first served policy, and the expert should 262 not block serious registration requests with a reasonable reference. 263 The reference may be to any form of documentation, including a web 264 page, but consideration should be given to providing one that is 265 expected to be long-lived and stable. 267 5.3. Initial Entries for the IMAP Mailbox Name Attributes Registry 269 The registry will initially contain these entries: 271 +===============+===================================+===========+ 272 | Attribute | Description | Reference | 273 | Name | | | 274 +===============+===================================+===========+ 275 | All | All messages | [RFC6154] | 276 +---------------+-----------------------------------+-----------+ 277 | Archive | Archived messages | [RFC6154] | 278 +---------------+-----------------------------------+-----------+ 279 | Drafts | Messages that are working drafts | [RFC6154] | 280 +---------------+-----------------------------------+-----------+ 281 | Flagged | Messages with the \Flagged flag | [RFC6154] | 282 +---------------+-----------------------------------+-----------+ 283 | HasChildren | Has accessible child mailboxes | [RFC3348] | 284 +---------------+-----------------------------------+-----------+ 285 | HasNoChildren | Has no accessible child mailboxes | [RFC3348] | 286 +---------------+-----------------------------------+-----------+ 287 | Important | Messages deemed important to user | THIS RFC | 288 +---------------+-----------------------------------+-----------+ 289 | Junk | Messages identified as Spam/Junk | [RFC6154] | 290 +---------------+-----------------------------------+-----------+ 291 | Marked | Server has marked the mailbox as | [RFC3501] | 292 | | "interesting" | | 293 +---------------+-----------------------------------+-----------+ 294 | NoInferiors | No hierarchy under this name | [RFC3501] | 295 +---------------+-----------------------------------+-----------+ 296 | Noselect | The mailbox is not selectable | [RFC3501] | 297 +---------------+-----------------------------------+-----------+ 298 | Sent | Sent mail | [RFC6154] | 299 +---------------+-----------------------------------+-----------+ 300 | Trash | Messages the user has discarded | [RFC6154] | 301 +---------------+-----------------------------------+-----------+ 302 | Unmarked | No new messages since last select | [RFC3501] | 303 +===============+===================================+===========+ 305 6. Changes During Document Development 307 [[RFC Editor: Please remove this section prior to publication.]] 309 Changes in -02 311 o Added the definition and registration of $Important. 313 o Noted that \Important might be implemented as a virtual collection 314 of $Important messages. 316 Changes in -01 318 o Expanded the new registry to all mailbox name attributes, and 319 added the attributes from 3501 and 3348 (suggested by Alexey). 320 This also adds those two documents to the "updates" list. 322 o Recorded Cyrus's suggestion to define $Important. 324 7. References 326 7.1. Normative References 328 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 329 4rev1", RFC 3501, March 2003. 331 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 332 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 333 May 2008. 335 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 336 Specifications: ABNF", STD 68, RFC 5234, January 2008. 338 [RFC6154] Leiba, B. and J. Nicolson, "IMAP LIST Extension for 339 Special-Use Mailboxes", RFC 6154, March 2011. 341 7.2. Informative References 343 [RFC3348] Gahrns, M. and R. Cheng, "The Internet Message Action 344 Protocol (IMAP4) Child Mailbox Extension", RFC 3348, July 345 2002. 347 [RFC5788] Melnikov, A. and D. Cridland, "IMAP4 Keyword Registry", 348 RFC 5788, March 2010. 350 Authors' Addresses 352 Barry Leiba 353 Huawei Technologies 355 Phone: +1 646 827 0648 356 Email: barryleiba@computer.org 357 URI: http://internetmessagingtechnology.org/ 359 Eric Iceman 360 Google, Inc. 362 Email: iceman@google.com