IMAP $Important Keyword and \Important Special-Use Attribute
draft-ietf-extra-specialuse-important-01

Abstract

RFC 6154 created an IMAP Special-Use LIST extension and defined an initial set of attributes. This document defines a new attribute, "\Important", and establishes a new IANA registry for IMAP folder attributes, registering the attributes defined in RFCs 3348, 3501, and 6154. This document also defines a new IMAP keyword, "$Important", and registers it in the registry defined in RFC 5788.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on October 21, 2018.

Copyright Notice

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Conventions used in this document
• 2. Definition of the '$Important' Message Keyword
• 3. Definition of the 'Important' Mailbox Attribute
• 3.1. Formal Syntax
• 3.2. Examples
• 3.2.1. Example of a LIST Response
• 3.2.2. Examples of Creating a New Mailbox using \Important
• 4. Implementation Notes
• 5. Security Considerations
• 6. IANA Considerations
• 6.1. Registration of the $Important keyword
• 6.2. Creation of the IMAP Mailbox Name Attributes Registry
• 6.2.1. Instructions to the Designated Expert
• 6.3. Initial Entries for the IMAP Mailbox Name Attributes Registry
• 7. Changes During Document Development
• 8. Contributors
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Author's Address

1. Introduction

The Internet Message Access Protocol (IMAP) specification [RFC3501] defines the use of message keywords, and an IMAP Keywords registry is created in [RFC5788]. [RFC6154] defines an extension to the IMAP LIST command for special-use mailboxes. The extension allows servers to provide extra information (attributes) about the purpose of a mailbox and defines an initial set of special-use attributes.

This document does the following:

• Defines a new message keyword, "$Important", to apply to messages that are considered important for the user, by some externally defined criteria.
• Registers the "$Important" keyword in the IMAP Keywords registry.
• Defines a new special-use attribute, "\Important", to designate a mailbox that will hold messages that are considered important for the user, by some externally defined criteria.
• Creates a registry for IMAP mailbox attributes and registers the new attribute and those defined in [RFC3348], [RFC3501], and [RFC6154].

1.1. Conventions used in this document

In examples, "C:" indicates lines sent by a client that is connected to a server. "S:" indicates lines sent by the server to the client.

2. Definition of the '$Important' Message Keyword

The "$Important" keyword is a signal that a message is likely important to the user. The keyword is generally expected to be set automatically by the system based on available signals (such as who the message is from, who else the message is addressed to, evaluation of the subject or content, or other heuristics). While the keyword also can be set by the user, that is not expected to be the primary usage.

This is distinct from the "\Flagged" system flag in two ways:

1. "$Important" carries a meaning of general importance, as opposed to follow-up or urgency. It is meant to be used for a form of triage, with "\Flagged" remaining as a designation of special attention, need for follow-up, or time-sensitivity. In particular, the sense of "$Important" is that other messages that are "like this one" according to some server-applied heuristics will also be $Important.
2. The setting of "$Important" is expected to be based at least partly on heuristics, generally set automatically by the server, whereas "\Flagged" is only intended to be set by the user with some sort of "flag this message" or "put a star on this message" interface.

3. Definition of the 'Important' Mailbox Attribute

The "\Important" mailbox attribute is a signal that the mailbox contains messages that are likely important to the user. In an implementation that also supports the "$Important" keyword, this special use is likely to represent a virtual mailbox collecting messages (from other mailboxes) that are marked with the "$Important" keyword. In other implementations, the system might automatically put messages there based on the same sorts of heuristics that are noted for the "$Important" keyword (see Section 2). The distinction between "\Important" and "\Flagged" for mailboxes is similar to those between "$Important" and "\Flagged" for messages.

3.1. Formal Syntax

    use-attr      =/  "\Important"
          

The following syntax specification adds to the one in [RFC6154], Section 6, using Augmented Backus-Naur Form (ABNF) as described in [RFC5234]. Be sure to see the ABNF notes at the beginning of [RFC3501], Section 9.

3.2. Examples

3.2.1. Example of a LIST Response

    C: t1 LIST "" "Imp*"
    S: * LIST (\HasNoChildren \Important) "/" "Important Messages"
    S: * LIST (\HasNoChildren) "/" "Imported Wine"
    S: t1 OK Success
            

In the following example, the mailbox called "Important Messages" is the one designated with the "\Important" attribute.

3.2.2. Examples of Creating a New Mailbox using \Important

    C: t1 CREATE "Important Messages" (USE (\Important))
    S: t1 OK Mailbox created
            

In the following example, the mailbox called "Important Messages" is created with the "\Important" attribute on a server that advertises the "CREATE-SPECIAL-USE" capability string.

    C: t1 CREATE "Important Messages" (USE (\Important))
    S: t1 NO [USEATTR] Mailbox not created; an \Important mailbox already exists
            

The following example is similar to the previous one, but the server is not able to assign the \Important attribute to the new mailbox.

    C: t1 CREATE "Important Messages" (USE (\Important))
    S: t1 NO [USEATTR] Mailbox not created; unsupported use \Important
            

The following example is similar to the previous one, but the server does not support this extension.

In both of the failure-mode examples, the "USEATTR" response code lets the client know that the problem is in the "USE" parameters. Note that the same response code is given in both cases, and the human-readable text is the only way to tell the difference. That text is not parsable by the client (it can only be logged and/or reported to the user).

4. Implementation Notes

This section is non-normative and is intended to describe the intended (and current as of this publication) usage of "$Important" in contrast with "\Flagged" on a message.

On the server:

• \Flagged is set or cleared in response to an explicit command from the client.
• $Important is set via a heuristic process performed by the server, usually involving analysis of header fields, what mailbox the message is filed in, perhaps message content, attachments, and such. It may then be set or cleared in response to an explicit command from the client, and the server may use that to adjust the heuristics in the future. It's also possible that the server will re-evaluate this and make a message $Important later if the user accesses the message frequently, for example.

On the client:

• Typically, an icon such as a flag or a star, or an indication such as red or bold text, is associated with \Flagged, and the UI provides a way for the user to turn that icon or indication on or off. Manipulation of the this results in a command to the server.
• Typically, a lesser indication is used for $Important. The client might or might not provide the user with a way to manipulate it. If it does, manipulation results in a command to the server.

5. Security Considerations

The security considerations in [RFC6154], Section 7, apply equally to this extension. In particular, "Conveying special-use information to a client exposes a small bit of extra information that could be of value to an attacker." Moreover, identifying "important" messages or a place where important messages are kept could give an attacker a strategic starting point. If the algorithm by which messages are determined to be important is well known, still more information is exposed -- perhaps, for example, there is an implication that the senders of these messages are particularly significant to the mailbox owner, and perhaps that is information that should not be made public.

As noted in RFC 6154, it is wise to protect the IMAP channel from passive eavesdropping, and to defend against unauthorized discernment of the identity of a user's "\Important" mailbox or of a user's "$Important" messages.

6. IANA Considerations

This document contains 3 actions for IANA, specified in the sections below:

1. Registration of the "$Important" keyword.
2. Creation of a new "IMAP Mailbox Name Attributes" registry.
3. Registration of initial entries in the "IMAP Mailbox Name Attributes" registry.

6.1. Registration of the $Important keyword

IANA is asked to register the $Important keyword in the "IMAP Keywords" registry, as follows, using the template in [RFC5788].

IMAP keyword name:

$Important

Purpose (description):

The "$Important" keyword is a signal that a message is likely important to the user.

Private or Shared on a server:

PRIVATE

Is it an advisory keyword or may it cause an automatic action:

Advisory (but see the reference for details).

When/by whom the keyword is set/cleared:

The keyword can be set by the user, or automatically by the system based on available signals (such as who the message is from, who else the message is addressed to, evaluation of the subject or content, or other heuristics).

Related keywords:

None (but see the reference for the related mailbox name attribute).

Related IMAP capabilities:

None.

Security considerations:

See [[THIS RFC]], Section 5

Published specification:

[[THIS RFC]]

Person & email address to contact for further information:

IETF Applications and Real-Time Area <art@ietf.org>

Intended usage:

COMMON

Owner/Change controller:

IESG

Note:

None.

6.2. Creation of the IMAP Mailbox Name Attributes Registry

IANA is asked to create a new registry in the group "Internet Message Access Protocol (IMAP)". The new registry will be called "IMAP Mailbox Name Attributes", and will have two references: "RFC 3501, Section 7.2.2", and "[[THIS RFC]], Section 6". This registry will be shared with JMAP.

The registry entries will contain the following fields:

1. Attribute Name
2. Description
3. Reference
4. Usage Notes

IANA will keep this list in alphabetical order by Attribute Name, which is registered without the initial backslash ("\"). The names are generally registered with initial capital letters, but are treated as case-insensitive US-ASCII strings.

The "Usage Notes" field is free-form US-ASCII text that will normally be empty (and is empty if it's not specified in the registration request). It is intended to hold things such as "not used by JMAP" and "JMAP only". The field is for human use, and there is no need for a registry of strings that may appear here.

The registration policy for the new registry will be listed as "IETF Review or Expert Review" [RFC8126], and new registrations will be accepted in one of two ways:

1. For registrations requested in an IETF consensus document, the registration policy will be IETF Review, and the request will be made in the IANA Considerations section of the document, giving the requested values for each of the fields.
2. For other registrations, the policy will be Expert Review policy (see Section 6.2.1), and the request will be made by sending email to IANA asking for a new IMAP Mailbox Name Attribute and giving the requested values for each of the fields.

6.2.1. Instructions to the Designated Expert

The expert reviewer, who will be designated by the IESG, is expected to provide only a general review of the requested registration, checking that the reference and description are adequate for understanding the intent of the registered attribute. Efforts should also be made to generalize the intent of an attribute so that multiple implementations with the same requirements may reuse existing attributes. Except for this check, this is intended to be very close to a first come first served policy, and the expert should not block serious registration requests with a reasonable reference. The reference may be to any form of documentation, including a web page, but consideration should be given to providing one that is expected to be long-lived and stable.

6.3. Initial Entries for the IMAP Mailbox Name Attributes Registry

+===============+===================================+===========+
| Attribute     | Description                       | Reference |
| Name          |                                   |           |
+===============+===================================+===========+
| All           | All messages                      | [RFC6154] |
+---------------+-----------------------------------+-----------+
| Archive       | Archived messages                 | [RFC6154] |
+---------------+-----------------------------------+-----------+
| Drafts        | Messages that are working drafts  | [RFC6154] |
+---------------+-----------------------------------+-----------+
| Flagged       | Messages with the \Flagged flag   | [RFC6154] |
+---------------+-----------------------------------+-----------+
| HasChildren   | Has accessible child mailboxes    | [RFC3348] | *
+---------------+-----------------------------------+-----------+
| HasNoChildren | Has no accessible child mailboxes | [RFC3348] | *
+---------------+-----------------------------------+-----------+
| Important     | Messages deemed important to user | THIS RFC  |
+---------------+-----------------------------------+-----------+
| Junk          | Messages identified as Spam/Junk  | [RFC6154] |
+---------------+-----------------------------------+-----------+
| Marked        | Server has marked the mailbox as  | [RFC3501] | *
|               | "interesting"                     |           |
+---------------+-----------------------------------+-----------+
| NoInferiors   | No hierarchy under this name      | [RFC3501] | *
+---------------+-----------------------------------+-----------+
| Noselect      | The mailbox is not selectable     | [RFC3501] | *
+---------------+-----------------------------------+-----------+
| Sent          | Sent mail                         | [RFC6154] |
+---------------+-----------------------------------+-----------+
| Trash         | Messages the user has discarded   | [RFC6154] |
+---------------+-----------------------------------+-----------+
| Unmarked      | No new messages since last select | [RFC3501] | *
+===============+===================================+===========+
        

The registry will initially contain these entries:

7. Changes During Document Development

[CREF1]RFC Editor: Please remove this section prior to publication.

Changes in draft-ietf-extra-specialuse-important-00

• Removed "specific" from "a specific meaning of general importance" because it sounded stupid.
• Added a "Usage Notes" column to the registry table in 6.2, and called out some "not used by JMAP" in 6.3.

Changes in draft-leiba-extra-specialuse-important-01

• Updated "IETF Applications Area" to "IETF Applications and Real-Time Area".
• Changed some wording to make the distinction between \Flagged and \Important clearer.
• Added some text explaining how \Important is used in existing servers.
• Added a note in the ABNF section referring to the ABNF notes in the IMAP spec.

Changes in draft-leiba-extra-specialuse-important-00

• Reset status, moved Eric to "Contributors", changed Barry to "Editor"
• Updated BCP 26 reference to RFC 8126.

Changes in draft-iceman-imap-specialuse-important-02

• Added the definition and registration of $Important.
• Noted that \Important might be implemented as a virtual collection of $Important messages.

Changes in draft-iceman-imap-specialuse-important-01

• Expanded the new registry to all mailbox name attributes, and added the attributes from 3501 and 3348 (suggested by Alexey). This also adds those two documents to the "updates" list.
• Recorded Cyrus's suggestion to define $Important.

8. Contributors

The following author was an original contributor to this document in addition to the editor.

Eric "Iceman"
Google
iceman@google.com

9. References

9.1. Normative References

9.2. Informative References

Author's Address