idnits 2.17.1 draft-ietf-extra-specialuse-important-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 07, 2018) is 2143 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) == Unused Reference: 'I-D.ietf-jmap-mail' is defined on line 480, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) == Outdated reference: A later version (-16) exists of draft-ietf-jmap-mail-04 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Leiba, Ed. 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track June 07, 2018 5 Expires: December 07, 2018 7 IMAP $Important Keyword and \Important Special-Use Attribute 8 draft-ietf-extra-specialuse-important-04 10 Abstract 12 RFC 6154 created an IMAP Special-Use LIST extension and defined an 13 initial set of attributes. This document defines a new attribute, 14 "\Important", and establishes a new IANA registry for IMAP folder 15 attributes, registering the attributes defined in RFCs 5258, 3501, 16 and 6154. This document also defines a new IMAP keyword, 17 "$Important", and registers it in the registry defined in RFC 5788. 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 December 07, 2018. 36 Copyright Notice 38 Copyright (c) 2018 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 (http://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Conventions used in this document . . . . . . . . . . . . . 2 54 2. Definition of the '$Important' Message Keyword . . . . . . . . 2 55 3. Definition of the 'Important' Mailbox Attribute . . . . . . . 3 56 3.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.2.1. Example of a LIST Response . . . . . . . . . . . . . . . . 3 59 3.2.2. Examples of Creating a New Mailbox using \Important . . . 4 60 4. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 4 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 6.1. Registration of the $Important keyword . . . . . . . . . . . 5 64 6.2. Creation of the IMAP Mailbox Name Attributes Registry . . . 6 65 6.2.1. Instructions to the Designated Expert . . . . . . . . . . 7 66 6.3. Initial Entries for the IMAP Mailbox Name Attributes Registry 7 67 7. Changes During Document Development . . . . . . . . . . . . . 8 68 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . . 9 71 9.2. Informative References . . . . . . . . . . . . . . . . . . . 10 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Introduction 76 The Internet Message Access Protocol (IMAP) specification [RFC3501] 77 defines the use of message keywords, and an IMAP Keywords registry is 78 created in [RFC5788]. [RFC6154] defines an extension to the IMAP 79 LIST command for special-use mailboxes. The extension allows servers 80 to provide extra information (attributes) about the purpose of a 81 mailbox and defines an initial set of special-use attributes. 83 This document does the following: 85 o Defines a new message keyword, "$Important", to apply to messages 86 that are considered important for the user, by some externally 87 defined criteria. 89 o Registers the "$Important" keyword in the IMAP Keywords registry. 91 o Defines a new special-use attribute, "\Important", to designate a 92 mailbox that will hold messages that are considered important for 93 the user, by some externally defined criteria. 95 o Creates a registry for IMAP mailbox attributes and registers the 96 new attribute and those defined in [RFC5258], [RFC3501], and 97 [RFC6154]. 99 1.1. Conventions used in this document 101 In examples, "C:" indicates lines sent by a client that is connected 102 to a server. "S:" indicates lines sent by the server to the client. 104 2. Definition of the '$Important' Message Keyword 105 The "$Important" keyword is a signal that a message is likely 106 important to the user. The keyword is generally expected to be set 107 automatically by the system based on available signals (such as who 108 the message is from, who else the message is addressed to, evaluation 109 of the subject or content, or other heuristics). While the keyword 110 also can be set by the user, that is not expected to be the primary 111 usage. 113 This is distinct from the "\Flagged" system flag in two ways: 115 1. "$Important" carries a meaning of general importance, as opposed 116 to follow-up or urgency. It is meant to be used for a form of 117 triage, with "\Flagged" remaining as a designation of special 118 attention, need for follow-up, or time-sensitivity. In 119 particular, the sense of "$Important" is that other messages that 120 are "like this one" according to some server-applied heuristics 121 will also be $Important. 123 2. The setting of "$Important" is expected to be based at least 124 partly on heuristics, generally set automatically by the server, 125 whereas "\Flagged" is only intended to be set by the user with 126 some sort of "flag this message" or "put a star on this message" 127 interface. 129 3. Definition of the 'Important' Mailbox Attribute 131 The "\Important" mailbox attribute is a signal that the mailbox 132 contains messages that are likely important to the user. In an 133 implementation that also supports the "$Important" keyword, this 134 special use is likely to represent a virtual mailbox collecting 135 messages (from other mailboxes) that are marked with the "$Important" 136 keyword. In other implementations, the system might automatically 137 put messages there based on the same sorts of heuristics that are 138 noted for the "$Important" keyword (see Section 2). The distinction 139 between "\Important" and "\Flagged" for mailboxes is similar to those 140 between "$Important" and "\Flagged" for messages. 142 3.1. Formal Syntax 144 The following syntax specification adds to the one in [RFC6154], 145 Section 6, using Augmented Backus-Naur Form (ABNF) as described in 146 [RFC5234]. Be sure to see the ABNF notes at the beginning of 147 [RFC3501], Section 9. 149 use-attr =/ "\Important" 151 3.2. Examples 153 3.2.1. Example of a LIST Response 155 In the following example, the mailbox called "Important Messages" is 156 the one designated with the "\Important" attribute. 158 C: t1 LIST "" "Imp*" 159 S: * LIST (\HasNoChildren \Important) "/" "Important Messages" 160 S: * LIST (\HasNoChildren) "/" "Imported Wine" 161 S: t1 OK Success 163 3.2.2. Examples of Creating a New Mailbox using \Important 165 In the following example, the mailbox called "Important Messages" is 166 created with the "\Important" attribute on a server that advertises 167 the "CREATE-SPECIAL-USE" capability string. 169 C: t1 CREATE "Important Messages" (USE (\Important)) 170 S: t1 OK Mailbox created 172 The following example is similar to the previous one, but the server 173 is not able to assign the \Important attribute to the new mailbox. 175 C: t1 CREATE "Important Messages" (USE (\Important)) 176 S: t1 NO [USEATTR] Not created; an \Important mailbox already exists 178 The following example is similar to the previous one, but the server 179 does not support this extension. 181 C: t1 CREATE "Important Messages" (USE (\Important)) 182 S: t1 NO [USEATTR] Mailbox not created; unsupported use \Important 184 In both of the failure-mode examples, the "USEATTR" response code 185 lets the client know that the problem is in the "USE" parameters. 186 Note that the same response code is given in both cases, and the 187 human-readable text is the only way to tell the difference. That 188 text is not parsable by the client (it can only be logged and/or 189 reported to the user). 191 4. Implementation Notes 193 This section is non-normative and is intended to describe the 194 intended (and current as of this publication) usage of "$Important" 195 in contrast with "\Flagged" on a message. 197 On the server: 199 o \Flagged is set or cleared in response to an explicit command from 200 the client. 202 o $Important is set via a heuristic process performed by the server, 203 usually involving analysis of header fields, what mailbox the 204 message is filed in, perhaps message content, attachments, and 205 such. It may then be set or cleared in response to an explicit 206 command from the client, and the server may use that to adjust the 207 heuristics in the future. It's also possible that the server will 208 re-evaluate this and make a message $Important later if the user 209 accesses the message frequently, for example. 211 On the client: 213 o Typically, an icon such as a flag or a star, or an indication such 214 as red or bold text, is associated with \Flagged, and the UI 215 provides a way for the user to turn that icon or indication on or 216 off. Manipulation of the this results in a command to the server. 218 o Typically, a lesser indication is used for $Important. The client 219 might or might not provide the user with a way to manipulate it. 220 If it does, manipulation results in a command to the server. 222 5. Security Considerations 224 The security considerations in [RFC6154], Section 7, apply equally to 225 this extension. In particular, "Conveying special-use information to 226 a client exposes a small bit of extra information that could be of 227 value to an attacker." Moreover, identifying "important" messages or 228 a place where important messages are kept could give an attacker a 229 strategic starting point. If the algorithm by which messages are 230 determined to be important is well known, still more information is 231 exposed -- perhaps, for example, there is an implication that the 232 senders of these messages are particularly significant to the mailbox 233 owner, and perhaps that is information that should not be made 234 public. 236 As noted in RFC 6154, it is wise to protect the IMAP channel from 237 passive eavesdropping, and to defend against unauthorized discernment 238 of the identity of a user's "\Important" mailbox or of a user's 239 "$Important" messages. See [RFC3501], Section 11, for security 240 considerations about using the IMAP STARTTLS command to protect the 241 IMAP channel. 243 6. IANA Considerations 245 This document contains 3 actions for IANA, specified in the sections 246 below: 248 1. Registration of the "$Important" keyword. 250 2. Creation of a new "IMAP Mailbox Name Attributes" registry. 252 3. Registration of initial entries in the "IMAP Mailbox Name 253 Attributes" registry. 255 6.1. Registration of the $Important keyword 257 IANA is asked to register the $Important keyword in the "IMAP 258 Keywords" registry, as follows, using the template in [RFC5788]. 260 IMAP keyword name: $Important 261 Purpose (description): The "$Important" keyword is a signal that a 262 message is likely important to the user. 264 Private or Shared on a server: PRIVATE 266 Is it an advisory keyword or may it cause an automatic action: 267 Advisory (but see the reference for details). 269 When/by whom the keyword is set/cleared: The keyword can be set by 270 the user, or automatically by the system based on available 271 signals (such as who the message is from, who else the message 272 is addressed to, evaluation of the subject or content, or other 273 heuristics). 275 Related keywords: None (but see the reference for the related mailbox 276 name attribute). 278 Related IMAP capabilities: None. 280 Security considerations: See [[THIS RFC]], Section 5 282 Published specification: [[THIS RFC]] 284 Person & email address to contact for further information: 285 IETF Applications and Real-Time Area 287 Intended usage: COMMON 289 Owner/Change controller: IESG 291 Note: None. 293 6.2. Creation of the IMAP Mailbox Name Attributes Registry 295 IANA is asked to create a new registry in the group "Internet Message 296 Access Protocol (IMAP)". The new registry will be called "IMAP 297 Mailbox Name Attributes", and will have two references: "RFC 3501, 298 Section 7.2.2", and "[[THIS RFC]], Section 6". This registry will be 299 shared with the JSON Meta Application Protocol (JMAP) for Mail [I-D 300 .ietf-jmap-mail]. 302 The registry entries will contain the following fields: 304 1. Attribute Name 305 2. Description 306 3. Reference 307 4. Usage Notes 309 IANA will keep this list in alphabetical order by Attribute Name, 310 which is registered without the initial backslash ("\"). The names 311 are generally registered with initial capital letters, but are 312 treated as case-insensitive US-ASCII strings. 314 The "Usage Notes" field is free-form US-ASCII text that will normally 315 be empty (and is empty if it's not specified in the registration 316 request). It is intended to hold things such as "not used by JMAP" 317 and "JMAP only". The field is for human use, and there is no need 318 for a registry of strings that may appear here. 320 The registration policy for the new registry will be listed as "IETF 321 Review or Expert Review" [RFC8126], and new registrations will be 322 accepted in one of two ways: 324 1. For registrations requested in an IETF consensus document, the 325 registration policy will be IETF Review, and the request will be 326 made in the IANA Considerations section of the document, giving 327 the requested values for each of the fields. 329 2. For other registrations, the policy will be Expert Review policy 330 (see Section 6.2.1), and the request will be made by sending 331 email to IANA asking for a new IMAP Mailbox Name Attribute and 332 giving the requested values for each of the fields. While a 333 formal specification is not required, the reference document 334 should provide a description of the proposed attribute sufficient 335 for building interoperable implementations. An Informational RFC 336 (submitted through the IETF or Independent stream) is a fine way 337 to publish a reference document (see also Section 6.2.1). 339 6.2.1. Instructions to the Designated Expert 341 The expert reviewer, who will be designated by the IESG, is expected 342 to provide only a general review of the requested registration, 343 checking that the reference and description are adequate for 344 understanding the intent of the registered attribute. Efforts should 345 also be made to generalize the intent of an attribute so that 346 multiple implementations with the same requirements may reuse 347 existing attributes. Except for this check, this is intended to be 348 very close to a first come first served policy, and the expert should 349 not block serious registration requests with a reasonable reference. 350 The reference may be to any form of documentation, including a web 351 page, but consideration should be given to providing one that is 352 expected to be long-lived and stable. 354 6.3. Initial Entries for the IMAP Mailbox Name Attributes Registry 356 The registry will initially contain these entries: 358 +===============+===================================+===========+ 359 | Attribute | Description | Reference | 360 | Name | | | 361 +===============+===================================+===========+ 362 | All | All messages | [RFC6154] | 363 +---------------+-----------------------------------+-----------+ 364 | Archive | Archived messages | [RFC6154] | 365 +---------------+-----------------------------------+-----------+ 366 | Drafts | Messages that are working drafts | [RFC6154] | 367 +---------------+-----------------------------------+-----------+ 368 | Flagged | Messages with the \Flagged flag | [RFC6154] | 369 +---------------+-----------------------------------+-----------+ 370 | HasChildren | Has accessible child mailboxes | [RFC5258] | * 371 +---------------+-----------------------------------+-----------+ 372 | HasNoChildren | Has no accessible child mailboxes | [RFC5258] | * 373 +---------------+-----------------------------------+-----------+ 374 | Important | Messages deemed important to user | THIS RFC | 375 +---------------+-----------------------------------+-----------+ 376 | Junk | Messages identified as Spam/Junk | [RFC6154] | 377 +---------------+-----------------------------------+-----------+ 378 | Marked | Server has marked the mailbox as | [RFC3501] | * 379 | | "interesting" | | 380 +---------------+-----------------------------------+-----------+ 381 | NoInferiors | No hierarchy under this name | [RFC3501] | * 382 +---------------+-----------------------------------+-----------+ 383 | NonExistent | The mailbox name doesn't actually | [RFC5258] | * 384 | | exist | | 385 +---------------+-----------------------------------+-----------+ 386 | Noselect | The mailbox is not selectable | [RFC3501] | * 387 +---------------+-----------------------------------+-----------+ 388 | Remote | The mailbox exists on a remote | [RFC5258] | * 389 | | server | | 390 +---------------+-----------------------------------+-----------+ 391 | Sent | Sent mail | [RFC6154] | 392 +---------------+-----------------------------------+-----------+ 393 | Subscribed | The mailbox is subscribed to | [RFC5258] | 394 +---------------+-----------------------------------+-----------+ 395 | Trash | Messages the user has discarded | [RFC6154] | 396 +---------------+-----------------------------------+-----------+ 397 | Unmarked | No new messages since last select | [RFC3501] | * 398 +===============+===================================+===========+ 400 The rows marked with "*" at the end should have their Usage Notes 401 field set to "not used by JMAP". 403 7. Changes During Document Development 405 [[RFC Editor: Please remove this section prior to publication.]] 407 Changes in draft-ietf-extra-specialuse-important-00 409 o Removed "specific" from "a specific meaning of general importance" 410 because it sounded stupid. 412 o Added a "Usage Notes" column to the registry table in 6.2, and 413 called out some "not used by JMAP" in 6.3. 415 Changes in draft-leiba-extra-specialuse-important-01 417 o Updated "IETF Applications Area" to "IETF Applications and Real- 418 Time Area". 420 o Changed some wording to make the distinction between \Flagged and 421 \Important clearer. 423 o Added some text explaining how \Important is used in existing 424 servers. 426 o Added a note in the ABNF section referring to the ABNF notes in 427 the IMAP spec. 429 Changes in draft-leiba-extra-specialuse-important-00 431 o Reset status, moved Eric to "Contributors", changed Barry to 432 "Editor" 434 o Updated BCP 26 reference to RFC 8126. 436 Changes in draft-iceman-imap-specialuse-important-02 438 o Added the definition and registration of $Important. 440 o Noted that \Important might be implemented as a virtual collection 441 of $Important messages. 443 Changes in draft-iceman-imap-specialuse-important-01 445 o Expanded the new registry to all mailbox name attributes, and 446 added the attributes from 3501 and 5258 (suggested by Alexey). 447 This also adds those two documents to the "updates" list. 449 o Recorded Cyrus's suggestion to define $Important. 451 8. Contributors 453 The following author was an original contributor to this document in 454 addition to the editor. 456 Eric "Iceman" 457 Google 458 iceman@google.com 460 9. References 462 9.1. Normative References 464 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 465 4rev1", RFC 3501, March 2003. 467 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 468 Specifications: ABNF", STD 68, RFC 5234, January 2008. 470 [RFC6154] Leiba, B. and J. Nicolson, "IMAP LIST Extension for 471 Special-Use Mailboxes", RFC 6154, March 2011. 473 [RFC8126] Cotton, M., Leiba, B. and T. Narten, "Guidelines for 474 Writing an IANA Considerations Section in RFCs", BCP 26, 475 RFC 8126, DOI 10.17487/RFC8126, June 2017, . 478 9.2. Informative References 480 [I-D.ietf-jmap-mail] 481 Jenkins, N., "JMAP for Mail", Internet-Draft draft-ietf- 482 jmap-mail-04, March 2018. 484 [RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access 485 Protocol version 4 - LIST Command Extensions", RFC 5258, 486 DOI 10.17487/RFC5258, June 2008, . 489 [RFC5788] Melnikov, A. and D. Cridland, "IMAP4 Keyword Registry", 490 RFC 5788, March 2010. 492 Author's Address 494 Barry Leiba, editor 495 Huawei Technologies 497 Phone: +1 646 827 0648 498 Email: barryleiba@computer.org 499 URI: http://internetmessagingtechnology.org/