draft-ietf-extra-specialuse-important-04.txt   rfc8457.txt 
Network Working Group B. Leiba, Ed. Internet Engineering Task Force (IETF) B. Leiba, Ed.
Internet-Draft Huawei Technologies Request for Comments: 8457 Huawei Technologies
Intended status: Standards Track June 07, 2018 Category: Standards Track September 2018
Expires: December 07, 2018 ISSN: 2070-1721
IMAP $Important Keyword and \Important Special-Use Attribute IMAP "$Important" Keyword and "\Important" Special-Use Attribute
draft-ietf-extra-specialuse-important-04
Abstract Abstract
RFC 6154 created an IMAP Special-Use LIST extension and defined an RFC 6154 created an IMAP special-use LIST extension and defined an
initial set of attributes. This document defines a new attribute, initial set of attributes. This document defines a new attribute,
"\Important", and establishes a new IANA registry for IMAP folder "\Important", and establishes a new IANA registry for IMAP folder
attributes, registering the attributes defined in RFCs 5258, 3501, attributes, which include the attributes defined in RFCs 5258, 3501,
and 6154. This document also defines a new IMAP keyword, and 6154. This document also defines a new IMAP keyword,
"$Important", and registers it in the registry defined in RFC 5788. "$Important", and registers it in the registry defined in RFC 5788.
Status of this Memo 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 This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on December 07, 2018. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8457.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Simplified BSD License text as described in Section 4.e of
provided without warranty as described in the Simplified BSD License. the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions used in this document . . . . . . . . . . . . . 2 1.1. Conventions Used in This Document . . . . . . . . . . . . . 3
2. Definition of the '$Important' Message Keyword . . . . . . . . 2 2. Definition of the "$Important" Message Keyword . . . . . . . 3
3. Definition of the 'Important' Mailbox Attribute . . . . . . . 3 3. Definition of the 'Important' Mailbox Attribute . . . . . . . 3
3.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.1. Example of a LIST Response . . . . . . . . . . . . . . . . 3 3.2.1. Example of a LIST Response . . . . . . . . . . . . . . . 4
3.2.2. Examples of Creating a New Mailbox using \Important . . . 4 3.2.2. Examples of Creating a New Mailbox Using "\Important" . . 4
4. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 4 4. Implementation Notes . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6.1. Registration of the $Important keyword . . . . . . . . . . . 5 6.1. Registration of the "$Important" Keyword . . . . . . . . . 6
6.2. Creation of the IMAP Mailbox Name Attributes Registry . . . 6 6.2. Creation of the IMAP Mailbox Name Attributes Registry . . . 7
6.2.1. Instructions to the Designated Expert . . . . . . . . . . 7 6.2.1. Instructions to the Designated Expert . . . . . . . . . . 8
6.3. Initial Entries for the IMAP Mailbox Name Attributes Registry 7 6.3. Initial Entries for the IMAP Mailbox Name Attributes
7. Changes During Document Development . . . . . . . . . . . . . 8 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . . 10 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The Internet Message Access Protocol (IMAP) specification [RFC3501] The Internet Message Access Protocol (IMAP) specification [RFC3501]
defines the use of message keywords, and an IMAP Keywords registry is defines the use of message keywords, and an "IMAP Keywords" registry
created in [RFC5788]. [RFC6154] defines an extension to the IMAP is created in [RFC5788]. [RFC6154] defines an extension to the IMAP
LIST command for special-use mailboxes. The extension allows servers LIST command for special-use mailboxes. The extension allows servers
to provide extra information (attributes) about the purpose of a to provide extra information (attributes) about the purpose of a
mailbox and defines an initial set of special-use attributes. mailbox and defines an initial set of special-use attributes.
This document does the following: This document does the following:
o Defines a new message keyword, "$Important", to apply to messages o defines a new message keyword, "$Important", to apply to messages
that are considered important for the user, by some externally that are considered important for the user by some externally
defined criteria. defined criteria;
o Registers the "$Important" keyword in the IMAP Keywords registry. o registers the "$Important" keyword in the "IMAP Keywords"
registry;
o Defines a new special-use attribute, "\Important", to designate a o defines a new special-use attribute, "\Important", to designate a
mailbox that will hold messages that are considered important for mailbox that will hold messages that are considered important for
the user, by some externally defined criteria. the user by some externally defined criteria; and
o Creates a registry for IMAP mailbox attributes and registers the o creates a registry for IMAP mailbox attributes and registers the
new attribute and those defined in [RFC5258], [RFC3501], and new attribute and those defined in [RFC5258], [RFC3501], and
[RFC6154]. [RFC6154].
1.1. Conventions used in this document 1.1. Conventions Used in This Document
In examples, "C:" indicates lines sent by a client that is connected In the examples used in this document, "C:" indicates lines sent by a
to a server. "S:" indicates lines sent by the server to the client. client that is connected to a server, and "S:" indicates lines sent
by the server to the client.
2. Definition of the "$Important" Message Keyword
2. Definition of the '$Important' Message Keyword
The "$Important" keyword is a signal that a message is likely The "$Important" keyword is a signal that a message is likely
important to the user. The keyword is generally expected to be set important to the user. The keyword is generally expected to be set
automatically by the system based on available signals (such as who automatically by the system based on available signals (such as who
the message is from, who else the message is addressed to, evaluation the message is from, who else the message is addressed to, evaluation
of the subject or content, or other heuristics). While the keyword 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 also can be set by the user, that is not expected to be the primary
usage. usage.
This is distinct from the "\Flagged" system flag in two ways: This is distinct from the "\Flagged" system flag in two ways:
1. "$Important" carries a meaning of general importance, as opposed 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 to follow-up or urgency. It is meant to be used for a form of
triage, with "\Flagged" remaining as a designation of special triage, with "\Flagged" remaining as a designation of special
attention, need for follow-up, or time-sensitivity. In attention, need for follow-up, or time sensitivity. In
particular, the sense of "$Important" is that other messages that particular, the sense of "$Important" is that other messages that
are "like this one" according to some server-applied heuristics are "like this one" according to some server-applied heuristics
will also be $Important. will also be considered "$Important".
2. The setting of "$Important" is expected to be based at least 2. The setting of "$Important" is expected to be based at least
partly on heuristics, generally set automatically by the server, partly on heuristics (generally set automatically by the server),
whereas "\Flagged" is only intended to be set by the user with 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" some sort of "flag this message" or "put a star on this message"
interface. interface.
3. Definition of the 'Important' Mailbox Attribute 3. Definition of the 'Important' Mailbox Attribute
The "\Important" mailbox attribute is a signal that the mailbox The "\Important" mailbox attribute is a signal that the mailbox
contains messages that are likely important to the user. In an contains messages that are likely important to the user. In an
implementation that also supports the "$Important" keyword, this implementation that also supports the "$Important" keyword, this
special use is likely to represent a virtual mailbox collecting special use is likely to represent a virtual mailbox collecting
messages (from other mailboxes) that are marked with the "$Important" messages (from other mailboxes) that are marked with the "$Important"
keyword. In other implementations, the system might automatically keyword. In other implementations, the system might automatically
put messages there based on the same sorts of heuristics that are put messages there based on the same sorts of heuristics that are
noted for the "$Important" keyword (see Section 2). The distinction noted for the "$Important" keyword (see Section 2). The distinctions
between "\Important" and "\Flagged" for mailboxes is similar to those between "\Important" and "\Flagged" for mailboxes are similar to
between "$Important" and "\Flagged" for messages. those between "$Important" and "\Flagged" for messages.
3.1. Formal Syntax 3.1. Formal Syntax
The following syntax specification adds to the one in [RFC6154], The following syntax specification adds to the one in Section 6 of
Section 6, using Augmented Backus-Naur Form (ABNF) as described in [RFC6154] using Augmented Backus-Naur Form (ABNF) as described in
[RFC5234]. Be sure to see the ABNF notes at the beginning of [RFC5234]. Be sure to see the ABNF notes at the beginning of
[RFC3501], Section 9. Section 9 of [RFC3501].
use-attr =/ "\Important" use-attr =/ "\Important"
3.2. Examples 3.2. Examples
3.2.1. Example of a LIST Response 3.2.1. Example of a LIST Response
In the following example, the mailbox called "Important Messages" is In the following example, the mailbox called "Important Messages" is
the one designated with the "\Important" attribute. the one designated with the "\Important" attribute.
C: t1 LIST "" "Imp*" C: t1 LIST "" "Imp*"
S: * LIST (\HasNoChildren \Important) "/" "Important Messages" S: * LIST (\HasNoChildren \Important) "/" "Important Messages"
S: * LIST (\HasNoChildren) "/" "Imported Wine" S: * LIST (\HasNoChildren) "/" "Imported Wine"
S: t1 OK Success S: t1 OK Success
3.2.2. Examples of Creating a New Mailbox using \Important 3.2.2. Examples of Creating a New Mailbox Using "\Important"
In the following example, the mailbox called "Important Messages" is In the following example, the mailbox called "Important Messages" is
created with the "\Important" attribute on a server that advertises created with the "\Important" attribute on a server that advertises
the "CREATE-SPECIAL-USE" capability string. the "CREATE-SPECIAL-USE" capability string.
C: t1 CREATE "Important Messages" (USE (\Important)) C: t1 CREATE "Important Messages" (USE (\Important))
S: t1 OK Mailbox created S: t1 OK Mailbox created
The following example is similar to the previous one, but the server The following example is similar to the previous one, but the server
is not able to assign the \Important attribute to the new mailbox. is not able to assign the "\Important" attribute to the new mailbox.
C: t1 CREATE "Important Messages" (USE (\Important)) C: t1 CREATE "Important Messages" (USE (\Important))
S: t1 NO [USEATTR] Not created; an \Important mailbox already exists S: t1 NO [USEATTR] An \Important mailbox already exists
The following example is similar to the previous one, but the server The following example is similar to the previous one, but the server
does not support this extension. does not support this extension.
C: t1 CREATE "Important Messages" (USE (\Important)) C: t1 CREATE "Important Messages" (USE (\Important))
S: t1 NO [USEATTR] Mailbox not created; unsupported use \Important S: t1 NO [USEATTR] Mailbox not created; unsupported use \Important
In both of the failure-mode examples, the "USEATTR" response code In both of the failure-mode examples, the "USEATTR" response code
lets the client know that the problem is in the "USE" parameters. 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 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 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 text is not parsable by the client (it can only be logged and/or
reported to the user). reported to the user).
4. Implementation Notes 4. Implementation Notes
This section is non-normative and is intended to describe the This section is non-normative and is intended to describe the
intended (and current as of this publication) usage of "$Important" intended (and current as of this publication) usage of "$Important"
in contrast with "\Flagged" on a message. in contrast with "\Flagged" on a message.
On the server: On the server:
o \Flagged is set or cleared in response to an explicit command from o "\Flagged" is set or cleared in response to an explicit command
the client. from the client.
o $Important is set via a heuristic process performed by the server, o "$Important" is set via a heuristic process performed by the
usually involving analysis of header fields, what mailbox the server and usually involves analysis of header fields, what
message is filed in, perhaps message content, attachments, and mailbox the message is filed in, perhaps message content,
such. It may then be set or cleared in response to an explicit attachments, and such. It may then be set or cleared in response
command from the client, and the server may use that to adjust the to an explicit command from the client, and the server may use
heuristics in the future. It's also possible that the server will that to adjust the heuristics in the future. It's also possible
re-evaluate this and make a message $Important later if the user that the server will re-evaluate this and make a message
accesses the message frequently, for example. "$Important" later if the user accesses the message frequently,
for example.
On the client: On the client:
o Typically, an icon such as a flag or a star, or an indication such o Typically, an icon such as a flag or a star (or an indication,
as red or bold text, is associated with \Flagged, and the UI such as red or bold text) is associated with "\Flagged", and the
provides a way for the user to turn that icon or indication on or UI provides a way for the user to turn that icon or indication on
off. Manipulation of the this results in a command to the server. or off. Manipulation of this results in a command to the server.
o Typically, a lesser indication is used for $Important. The client o Typically, a lesser indication is used for "$Important". The
might or might not provide the user with a way to manipulate it. client might or might not provide the user with a way to
If it does, manipulation results in a command to the server. manipulate it. If it does, manipulation results in a command to
the server.
5. Security Considerations 5. Security Considerations
The security considerations in [RFC6154], Section 7, apply equally to The security considerations in Section 7 of [RFC6154] apply equally
this extension. In particular, "Conveying special-use information to to this extension, in particular, "Conveying special-use information
a client exposes a small bit of extra information that could be of to a client exposes a small bit of extra information that could be of
value to an attacker." Moreover, identifying "important" messages or value to an attacker." Moreover, identifying important messages or a
a place where important messages are kept could give an attacker a place where important messages are kept could give an attacker a
strategic starting point. If the algorithm by which messages are strategic starting point. If the algorithm by which messages are
determined to be important is well known, still more information is determined to be important is well known, still more information is
exposed -- perhaps, for example, there is an implication that the exposed -- perhaps, for example, there is an implication that the
senders of these messages are particularly significant to the mailbox senders of these messages are particularly significant to the mailbox
owner, and perhaps that is information that should not be made owner, and perhaps that is information that should not be made
public. public.
As noted in RFC 6154, it is wise to protect the IMAP channel from As noted in RFC 6154, it is wise to protect the IMAP channel from
passive eavesdropping, and to defend against unauthorized discernment passive eavesdropping and to defend against unauthorized discernment
of the identity of a user's "\Important" mailbox or of a user's of the identity of a user's "\Important" mailbox or of a user's
"$Important" messages. See [RFC3501], Section 11, for security "$Important" messages. See Section 11 of [RFC3501] for security
considerations about using the IMAP STARTTLS command to protect the considerations about using the IMAP STARTTLS command to protect the
IMAP channel. IMAP channel.
6. IANA Considerations 6. IANA Considerations
This document contains 3 actions for IANA, specified in the sections IANA has completed three actions, which are specified in the sections
below: below:
1. Registration of the "$Important" keyword. 1. registration of the "$Important" keyword;
2. Creation of a new "IMAP Mailbox Name Attributes" registry. 2. creation of a new "IMAP Mailbox Name Attributes" registry; and
3. Registration of initial entries in the "IMAP Mailbox Name 3. registration of initial entries in the "IMAP Mailbox Name
Attributes" registry. Attributes" registry.
6.1. Registration of the $Important keyword 6.1. Registration of the "$Important" Keyword
IANA is asked to register the $Important keyword in the "IMAP IANA has registered the "$Important" keyword in the "IMAP Keywords"
Keywords" registry, as follows, using the template in [RFC5788]. registry, as follows, using the template in [RFC5788].
IMAP keyword name: $Important IMAP keyword name: $Important
Purpose (description): The "$Important" keyword is a signal that a
Purpose (description): The "$Important" keyword is a signal that a
message is likely important to the user. message is likely important to the user.
Private or Shared on a server: PRIVATE Private or Shared on a server: PRIVATE
Is it an advisory keyword or may it cause an automatic action: Is it an advisory keyword or may it cause an automatic action:
Advisory (but see the reference for details). Advisory (but see the reference for details).
When/by whom the keyword is set/cleared: The keyword can be set by When/by whom the keyword is set/cleared: The keyword can be set by
the user, or automatically by the system based on available the user, or automatically by the system based on available
signals (such as who the message is from, who else the message signals (such as who the message is from, who else the message
is addressed to, evaluation of the subject or content, or other is addressed to, evaluation of the subject or content, or other
heuristics). heuristics).
Related keywords: None (but see the reference for the related mailbox Related keywords: None (see the reference for the related mailbox
name attribute). name attribute).
Related IMAP capabilities: None. Related IMAP capabilities: None.
Security considerations: See [[THIS RFC]], Section 5
Published specification: [[THIS RFC]] Security considerations: See Section 5 of RFC 8457.
Published specification: RFC 8457
Person & email address to contact for further information: Person & email address to contact for further information:
IETF Applications and Real-Time Area <art@ietf.org> IETF Applications and Real-Time Area <art@ietf.org>
Intended usage: COMMON Intended usage: COMMON
Owner/Change controller: IESG Owner/Change controller: IESG
Note: None. Note: None.
6.2. Creation of the IMAP Mailbox Name Attributes Registry 6.2. Creation of the IMAP Mailbox Name Attributes Registry
IANA is asked to create a new registry in the group "Internet Message IANA has created a new registry in the group "Internet Message Access
Access Protocol (IMAP)". The new registry will be called "IMAP Protocol (IMAP)". It is called "IMAP Mailbox Name Attributes", and
Mailbox Name Attributes", and will have two references: "RFC 3501, it has two references: "RFC 3501, Section 7.2.2", and "RFC 8457,
Section 7.2.2", and "[[THIS RFC]], Section 6". This registry will be Section 6". This registry will be shared with the JSON Meta
shared with the JSON Meta Application Protocol (JMAP) for Mail [I-D Application Protocol (JMAP) for Mail [JMAP-MAIL].
.ietf-jmap-mail].
The registry entries will contain the following fields: The registry entries contain the following fields:
1. Attribute Name 1. Attribute Name
2. Description 2. Description
3. Reference 3. Reference
4. Usage Notes 4. Usage Notes
IANA will keep this list in alphabetical order by Attribute Name, IANA keeps this list in alphabetical order by Attribute Name, which
which is registered without the initial backslash ("\"). The names is registered without the initial backslash ("\"). The names are
are generally registered with initial capital letters, but are generally registered with initial capital letters but are treated as
treated as case-insensitive US-ASCII strings. case-insensitive US-ASCII strings.
The "Usage Notes" field is free-form US-ASCII text that will normally 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 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" 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 and "JMAP only". The field is for human use, and there is no need
for a registry of strings that may appear here. for a registry of strings that may appear here.
The registration policy for the new registry will be listed as "IETF The registration policy for the new registry is listed as "IETF
Review or Expert Review" [RFC8126], and new registrations will be Review" or "Expert Review" [RFC8126], and new registrations will be
accepted in one of two ways: accepted in one of two ways:
1. For registrations requested in an IETF consensus document, the 1. For registrations requested in an IETF consensus document, the
registration policy will be IETF Review, and the request will be registration policy will be IETF Review, and the request will be
made in the IANA Considerations section of the document, giving made in the IANA Considerations section of the document, which
the requested values for each of the fields. gives the requested values for each of the fields.
2. For other registrations, the policy will be Expert Review policy 2. For other registrations, the policy will be Expert Review policy
(see Section 6.2.1), and the request will be made by sending (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 email to IANA asking for a new IMAP Mailbox Name Attribute and
giving the requested values for each of the fields. While a giving the requested values for each of the fields. While a
formal specification is not required, the reference document formal specification is not required, the reference document
should provide a description of the proposed attribute sufficient should provide a description of the proposed attribute sufficient
for building interoperable implementations. An Informational RFC for building interoperable implementations. An Informational RFC
(submitted through the IETF or Independent stream) is a fine way (submitted, for example, through the IETF or Independent stream)
to publish a reference document (see also Section 6.2.1). is a fine way to publish a reference document (see also
Section 6.2.1).
6.2.1. Instructions to the Designated Expert 6.2.1. Instructions to the Designated Expert
The expert reviewer, who will be designated by the IESG, is expected The expert reviewer, who will be designated by the IESG, is expected
to provide only a general review of the requested registration, to provide only a general review of the requested registration,
checking that the reference and description are adequate for checking that the reference and description are adequate for
understanding the intent of the registered attribute. Efforts should understanding the intent of the registered attribute. Efforts should
also be made to generalize the intent of an attribute so that also be made to generalize the intent of an attribute so that
multiple implementations with the same requirements may reuse multiple implementations with the same requirements may reuse
existing attributes. Except for this check, this is intended to be existing attributes. Except for this check, this is intended to be
very close to a first come first served policy, and the expert should very close to a first come first served policy, and the expert should
not block serious registration requests with a reasonable reference. not block serious registration requests with a reasonable reference.
The reference may be to any form of documentation, including a web The reference may be to any form of documentation, including a web
page, but consideration should be given to providing one that is page, but consideration should be given to providing one that is
expected to be long-lived and stable. expected to be long-lived and stable.
6.3. Initial Entries for the IMAP Mailbox Name Attributes Registry 6.3. Initial Entries for the IMAP Mailbox Name Attributes Registry
The registry will initially contain these entries: The registry initially contains these entries:
+===============+===================================+===========+ +===============+===================================+===========+
| Attribute | Description | Reference | | Attribute | Description | Reference |
| Name | | | | Name | | |
+===============+===================================+===========+ +===============+===================================+===========+
| All | All messages | [RFC6154] | | All | All messages | [RFC6154] |
+---------------+-----------------------------------+-----------+ +---------------+-----------------------------------+-----------+
| Archive | Archived messages | [RFC6154] | | Archive | Archived messages | [RFC6154] |
+---------------+-----------------------------------+-----------+ +---------------+-----------------------------------+-----------+
| Drafts | Messages that are working drafts | [RFC6154] | | Drafts | Messages that are working drafts | [RFC6154] |
+---------------+-----------------------------------+-----------+ +---------------+-----------------------------------+-----------+
| Flagged | Messages with the \Flagged flag | [RFC6154] | | Flagged | Messages with the \Flagged flag | [RFC6154] |
+---------------+-----------------------------------+-----------+ +---------------+-----------------------------------+-----------+
| HasChildren | Has accessible child mailboxes | [RFC5258] | * | HasChildren | Has accessible child mailboxes | [RFC5258] | *
+---------------+-----------------------------------+-----------+ +---------------+-----------------------------------+-----------+
| HasNoChildren | Has no accessible child mailboxes | [RFC5258] | * | HasNoChildren | Has no accessible child mailboxes | [RFC5258] | *
+---------------+-----------------------------------+-----------+ +---------------+-----------------------------------+-----------+
| Important | Messages deemed important to user | THIS RFC | | Important | Messages deemed important to user | RFC 8457 |
+---------------+-----------------------------------+-----------+ +---------------+-----------------------------------+-----------+
| Junk | Messages identified as Spam/Junk | [RFC6154] | | Junk | Messages identified as Spam/Junk | [RFC6154] |
+---------------+-----------------------------------+-----------+ +---------------+-----------------------------------+-----------+
| Marked | Server has marked the mailbox as | [RFC3501] | * | Marked | Server has marked the mailbox as | [RFC3501] | *
| | "interesting" | | | | "interesting" | |
+---------------+-----------------------------------+-----------+ +---------------+-----------------------------------+-----------+
| NoInferiors | No hierarchy under this name | [RFC3501] | * | NoInferiors | No hierarchy under this name | [RFC3501] | *
+---------------+-----------------------------------+-----------+ +---------------+-----------------------------------+-----------+
| NonExistent | The mailbox name doesn't actually | [RFC5258] | * | NonExistent | The mailbox name doesn't actually | [RFC5258] | *
| | exist | | | | exist | |
skipping to change at page 8, line 47 skipping to change at page 9, line 51
+---------------+-----------------------------------+-----------+ +---------------+-----------------------------------+-----------+
| Sent | Sent mail | [RFC6154] | | Sent | Sent mail | [RFC6154] |
+---------------+-----------------------------------+-----------+ +---------------+-----------------------------------+-----------+
| Subscribed | The mailbox is subscribed to | [RFC5258] | | Subscribed | The mailbox is subscribed to | [RFC5258] |
+---------------+-----------------------------------+-----------+ +---------------+-----------------------------------+-----------+
| Trash | Messages the user has discarded | [RFC6154] | | Trash | Messages the user has discarded | [RFC6154] |
+---------------+-----------------------------------+-----------+ +---------------+-----------------------------------+-----------+
| Unmarked | No new messages since last select | [RFC3501] | * | Unmarked | No new messages since last select | [RFC3501] | *
+===============+===================================+===========+ +===============+===================================+===========+
The rows marked with "*" at the end should have their Usage Notes The rows marked with "*" at the end have their Usage Notes field set
field set to "not used by JMAP". to "not used by JMAP".
7. Changes During Document Development
[[RFC Editor: Please remove this section prior to publication.]]
Changes in draft-ietf-extra-specialuse-important-00
o Removed "specific" from "a specific meaning of general importance"
because it sounded stupid.
o 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
o Updated "IETF Applications Area" to "IETF Applications and Real-
Time Area".
o Changed some wording to make the distinction between \Flagged and
\Important clearer.
o Added some text explaining how \Important is used in existing
servers.
o Added a note in the ABNF section referring to the ABNF notes in 7. References
the IMAP spec.
Changes in draft-leiba-extra-specialuse-important-00 7.1. Normative References
o Reset status, moved Eric to "Contributors", changed Barry to [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
"Editor" 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<https://www.rfc-editor.org/info/rfc3501>.
o Updated BCP 26 reference to RFC 8126. [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
Changes in draft-iceman-imap-specialuse-important-02 [RFC6154] Leiba, B. and J. Nicolson, "IMAP LIST Extension for
Special-Use Mailboxes", RFC 6154, DOI 10.17487/RFC6154,
March 2011, <https://www.rfc-editor.org/info/rfc6154>.
o Added the definition and registration of $Important. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
o Noted that \Important might be implemented as a virtual collection 7.2. Informative References
of $Important messages.
Changes in draft-iceman-imap-specialuse-important-01 [JMAP-MAIL]
Jenkins, N. and C. Newman, "JMAP for Mail", Work in
Progress, draft-ietf-jmap-mail-07, August 2018.
o Expanded the new registry to all mailbox name attributes, and [RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access
added the attributes from 3501 and 5258 (suggested by Alexey). Protocol version 4 - LIST Command Extensions", RFC 5258,
This also adds those two documents to the "updates" list. DOI 10.17487/RFC5258, June 2008,
<https://www.rfc-editor.org/info/rfc5258>.
o Recorded Cyrus's suggestion to define $Important. [RFC5788] Melnikov, A. and D. Cridland, "IMAP4 Keyword Registry",
RFC 5788, DOI 10.17487/RFC5788, March 2010,
<https://www.rfc-editor.org/info/rfc5788>.
8. Contributors Contributors
The following author was an original contributor to this document in The following author was an original contributor to this document in
addition to the editor. addition to the editor.
Eric "Iceman" Eric "Iceman"
Google Google
iceman@google.com Email: iceman@google.com
9. References
9.1. Normative References
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC6154] Leiba, B. and J. Nicolson, "IMAP LIST Extension for
Special-Use Mailboxes", RFC 6154, March 2011.
[RFC8126] Cotton, M., Leiba, B. and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www
.rfc-editor.org/info/rfc8126>.
9.2. Informative References
[I-D.ietf-jmap-mail]
Jenkins, N., "JMAP for Mail", Internet-Draft draft-ietf-
jmap-mail-04, March 2018.
[RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access
Protocol version 4 - LIST Command Extensions", RFC 5258,
DOI 10.17487/RFC5258, June 2008, <https://www.rfc-
editor.org/info/rfc5258>.
[RFC5788] Melnikov, A. and D. Cridland, "IMAP4 Keyword Registry",
RFC 5788, March 2010.
Author's Address Author's Address
Barry Leiba, editor Barry Leiba (editor)
Huawei Technologies Huawei Technologies
Phone: +1 646 827 0648 Phone: +1 646 827 0648
Email: barryleiba@computer.org Email: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/ URI: http://internetmessagingtechnology.org/
 End of changes. 76 change blocks. 
220 lines changed or deleted 179 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/