Skip to main content

IMAP "$Important" Keyword and "\Important" Special-Use Attribute
RFC 8457

Revision differences

Document history

Date Rev. By Action
2018-09-10
04 (System) IANA registries were updated to include RFC8457
2018-09-06
04 (System)
Received changes through RFC Editor sync (created alias RFC 8457, changed title to 'IMAP "$Important" Keyword and "\Important" Special-Use Attribute', changed abstract to 'RFC …
Received changes through RFC Editor sync (created alias RFC 8457, changed title to 'IMAP "$Important" Keyword and "\Important" Special-Use Attribute', changed abstract to '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, which include the attributes defined in RFCs 5258, 3501, and 6154.  This document also defines a new IMAP keyword, "$Important", and registers it in the registry defined in RFC 5788.', changed pages to 11, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2018-09-06, changed IESG state to RFC Published)
2018-09-06
04 (System) RFC published
2018-09-05
04 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2018-08-31
04 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2018-07-19
04 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2018-06-18
04 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2018-06-18
04 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2018-06-18
04 (System) IANA Action state changed to In Progress from Waiting on Authors
2018-06-14
04 (System) IANA Action state changed to Waiting on Authors
2018-06-12
04 (System) RFC Editor state changed to EDIT
2018-06-12
04 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2018-06-12
04 (System) Announcement was received by RFC Editor
2018-06-11
04 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2018-06-11
04 Cindy Morgan IESG has approved the document
2018-06-11
04 Cindy Morgan Closed "Approve" ballot
2018-06-11
04 Cindy Morgan Ballot approval text was generated
2018-06-07
04 Barry Leiba New version available: draft-ietf-extra-specialuse-important-04.txt
2018-06-07
04 (System) New version approved
2018-06-07
04 (System) Request for posting confirmation emailed to previous authors: Barry Leiba
2018-06-07
04 Barry Leiba Uploaded new revision
2018-06-07
03 Cindy Morgan IESG state changed to Approved-announcement to be sent from IESG Evaluation
2018-06-07
03 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2018-06-07
03 Adam Roach [Ballot comment]
Thank you for your explanation regarding my DISCUSS.
2018-06-07
03 Adam Roach [Ballot Position Update] Position for Adam Roach has been changed to No Objection from Discuss
2018-06-06
03 Adam Roach
[Ballot discuss]
Thanks for the work everyone has done on this document. I have a concern about
an ambiguity that can potentially lead to interop …
[Ballot discuss]
Thanks for the work everyone has done on this document. I have a concern about
an ambiguity that can potentially lead to interop issues between clients and
servers that make different assumptions around \Important mailbox ordinality.

The second example in section 3.2.2 and the use of the singular form "mailbox"
in this passage from section 5 imply that only one mailbox is allowed to be
tagged "\Important":

>  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...

However, I find no normative text that indicates whether this is expected to be
inherent to the mechanism, or whether servers can exercise discretion about
allowing more than one mailbox to be tagged \Important.

In particular, I want to ensure that no one develops a client that assumes that
the server will prevent it from having multiple such mailboxes (relying on an
error in the case that it tries to create a second one), and then chokes when it
happens. Similar issues can arise with a permissive server and two clients with
different notions about whether multiple \Important mailboxes are allowed.

Please add normative language that either explicitly disallows this behavior, or
explicitly allows this behavior.
2018-06-06
03 Adam Roach
[Ballot comment]
The Abstract, Introduction, and Informative References section of this document
all refer to the obsolete RFC 3348, while the table in section …
[Ballot comment]
The Abstract, Introduction, and Informative References section of this document
all refer to the obsolete RFC 3348, while the table in section 6.3 refers to RFC
5258
, which is the document that obsoleted RFC 3348. I think you want to make
this consistent within the document (namely, I think this document should not
mention RFC 3348 anywhere).

---------------------------------------------------------------------------

§3.2.2:

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

The server response in this example is too long for the RFC format; and, being a
protocol element, I don't think the RFC editor can automatically fix it. Please
consider either using a shorter message in the example, or introducing a
documentation convention that allows wrapping of lines where the protocol does
not. (It is common in SIP and SDP to add a line break and small indent, along
with a note that such line breaks are to comply with the RFC format and do not
appear on the wire).
2018-06-06
03 Adam Roach [Ballot Position Update] New position, Discuss, has been recorded for Adam Roach
2018-06-06
03 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2018-06-06
03 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-06-06
03 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2018-06-06
03 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-06-06
03 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-06-06
03 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2018-06-06
03 Eric Rescorla [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla
2018-06-05
03 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2018-06-05
03 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2018-06-05
03 Benjamin Kaduk [Ballot comment]
The instructions for the Designated Expert read as if they would be consistent with an
RFC 8126 Specification Required policy.
2018-06-05
03 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2018-06-04
03 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2018-06-02
03 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-05-27
03 Alexey Melnikov IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2018-05-21
03 Joe Clarke Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Joe Clarke. Sent review to list.
2018-05-17
03 Stefan Santesson Request for Last Call review by SECDIR Completed: Ready. Reviewer: Stefan Santesson. Sent review to list.
2018-05-14
03 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2018-05-12
03 Brian Carpenter Request for Last Call review by GENART Completed: Ready. Reviewer: Brian Carpenter. Sent review to list.
2018-05-11
03 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2018-05-11
03 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2018-05-11
03 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-extra-specialuse-important-02. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-extra-specialuse-important-02. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the IMAP Keywords registry located at:

https://www.iana.org/assignments/imap-keywords/

a single, new registration will be made as follows:

Keyword: Type: $Important
Usage: COMMON
Comments:
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, a new registry is to be created called the IMAP Mailbox Name Attributes Registry. The new registry is to be a separate, new registry linked in the IMAP registry group on the IANA Protocol Parameter Matrix. The new registry is to be managed via IETF Review or Expert Review as defined in RFC 8126.

Each registry entry will contain the following fields: Attribute Name, Description, Reference and Usage Notes. The registry is to be maintained in Attribute Name order. The reference for the registry is to be RFC 3501, Section 7.2.2 and [ RFC-to-be ], Section 6.

There are initial entries in the new registry as follows:

+========+==================+======+
| 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 | [RFC5258] | *
+---------------+-----------------------------------+-----------+
| HasNoChildren | Has no accessible child mailboxes | [RFC5258] | *
+---------------+-----------------------------------+-----------+
| 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] | *
+---------------+-----------------------------------+-----------+
| NonExistent | The mailbox name doesn't actually | [RFC5258] | *
| | exist | |
+---------------+-----------------------------------+-----------+
| Noselect | The mailbox is not selectable | [RFC3501] | *
+---------------+-----------------------------------+-----------+
| Remote | The mailbox exists on a remote | [RFC5258] | *
| | server | |
+---------------+-----------------------------------+-----------+
| Sent | Sent mail | [RFC6154] |
+---------------+-----------------------------------+-----------+
| Subscribed | The mailbox is subscribed to | [RFC5258] |
+---------------+-----------------------------------+-----------+
| Trash | Messages the user has discarded | [RFC6154] |
+---------------+-----------------------------------+-----------+
| Unmarked | No new messages since last select | [RFC3501] | *
+========+==================+======+

The rows marked with "*" at the end will have their Usage Notes field set to "not used by JMAP".

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.
Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2018-05-10
03 Alexey Melnikov Placed on agenda for telechat - 2018-06-07
2018-05-07
03 Alexey Melnikov Ballot has been issued
2018-05-07
03 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2018-05-07
03 Alexey Melnikov Created "Approve" ballot
2018-05-07
03 Alexey Melnikov Ballot writeup was changed
2018-05-07
03 Alexey Melnikov
Document Shepherd Write-Up for draft-extra-specialuse-important

1. This document is being requested as a Proposed Standard because it
extends an existing Proposed Standard (RFC3501).  …
Document Shepherd Write-Up for draft-extra-specialuse-important

1. This document is being requested as a Proposed Standard because it
extends an existing Proposed Standard (RFC3501).  The request type is
indicated in the title page header.

2.

Technical Summary

  This spec extends IMAP with an additional special-use [RFC6154]
  type for a mailbox (possibly virtual) which stores messages that
  may be important to the user.

  The document also creates a registry for mailbox uses to allow
  other uses to be defined in future.

Working Group Summary

  The only topic of debate was how to make the the registry useful
  for JMAP and other non-IMAP specifications as well, which led to
  adding instructions to IANA for a free-form column with usage
  guidance.

Document Quality

  An \Important special-use has been implemented by Gmail already,
  and all the other server implementations said it would be easy to
  add.

Personnel

  Document Shepherd - Bron Gondwana (EXTRA co-chair)
  Responsible Area Director - Alexey Melnikov


3. The Document Shepherd has read the document through in detail and
is happy that it's easy to implement.

4. There are no concerns about reviews, this document has been well reviewed.

5. There is no review required for the document by other areas.

6. There are no concerns with this document that IESG should be aware of.

7. There have been no IPR disclosures for this spec.

8. There have been no IPR disclosures for this spec.

9. The WG consensus is solid.

10. There has been no discontent.

11. The ID nits tool said one page was too long (60 lines rather than
58) however this may be due to instructions that will be removed before
publication.

12. This document doesn't define anything which needs formal review
outside the working group.

13. All references have been identified as either normative or
informative.

14. All normative references are published standards.

15. There are no downward normative references references.

16. This RFC does not change the status of any other RFCs.

17. The IANA considerations ask for a new registry to be created and an
expert to be designated.  The initial values for the registry are fully
specified with clear instructions, and a good name has been chosen for
the registry.  Sources for all the initial values in the registry have
been provided.

18. The new IANA registry (IMAP Mailbox Name Attributes) will require
an expert reviewer, who should have IMAP protocol experience and ideally
server implementation experience.

19. The formal sections are simple enough that eyeball reading
was sufficient to validate them.


2018-05-07
03 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Joe Clarke
2018-05-07
03 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Joe Clarke
2018-05-03
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Stefan Santesson
2018-05-03
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Stefan Santesson
2018-05-03
03 Jean Mahoney Request for Last Call review by GENART is assigned to Brian Carpenter
2018-05-03
03 Jean Mahoney Request for Last Call review by GENART is assigned to Brian Carpenter
2018-04-30
03 Barry Leiba New version available: draft-ietf-extra-specialuse-important-03.txt
2018-04-30
03 (System) New version approved
2018-04-30
03 (System) Request for posting confirmation emailed to previous authors: Barry Leiba
2018-04-30
03 Barry Leiba Uploaded new revision
2018-04-30
02 Amy Vezza IANA Review state changed to IANA - Review Needed
2018-04-30
02 Amy Vezza
The following Last Call announcement was sent out (ends 2018-05-14):

From: The IESG
To: IETF-Announce
CC: extra@ietf.org, brong@fastmailteam.com, extra-chairs@ietf.org, draft-ietf-extra-specialuse-important@ietf.org, alexey.melnikov@isode.com …
The following Last Call announcement was sent out (ends 2018-05-14):

From: The IESG
To: IETF-Announce
CC: extra@ietf.org, brong@fastmailteam.com, extra-chairs@ietf.org, draft-ietf-extra-specialuse-important@ietf.org, alexey.melnikov@isode.com, Bron Gondwana
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IMAP $Important Keyword and \Important Special-Use Attribute) to Proposed Standard


The IESG has received a request from the Email mailstore and eXtensions To
Revise or Amend WG (extra) to consider the following document: - 'IMAP
$Important Keyword and \Important Special-Use Attribute'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-05-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-extra-specialuse-important/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-extra-specialuse-important/ballot/


No IPR declarations have been submitted directly on this I-D.




2018-04-30
02 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2018-04-30
02 Alexey Melnikov Last call was requested
2018-04-30
02 Alexey Melnikov Last call announcement was generated
2018-04-30
02 Alexey Melnikov Ballot approval text was generated
2018-04-30
02 Alexey Melnikov Ballot writeup was generated
2018-04-30
02 Alexey Melnikov IESG state changed to Last Call Requested from AD Evaluation
2018-04-30
02 Alexey Melnikov IESG state changed to AD Evaluation from Publication Requested
2018-04-26
02 Bron Gondwana
Document Shepherd Write-Up for draft-extra-specialuse-important

1. This document is being requested as an Internet Standard because it
extends an existing Internet Standard (RFC3501).  …
Document Shepherd Write-Up for draft-extra-specialuse-important

1. This document is being requested as an Internet Standard because it
extends an existing Internet Standard (RFC3501).  The request type is
indicated in the title page header.

2.

Technical Summary

  This spec extends IMAP with an additional special-use [RFC6154]
  type for a mailbox (possibly virtual) which stores messages that
  may be important to the user.

  The document also creates a registry for mailbox uses to allow
  other uses to be defined in future.

Working Group Summary

  The only topic of debate was how to make the the registry useful
  for JMAP and other non-IMAP specifications as well, which led to
  adding instructions to IANA for a free-form column with usage
  guidance.

Document Quality

  An \Important special-use has been implemented by Gmail already,
  and all the other server implementations said it would be easy to
  add.

Personnel

  Document Shepherd - Bron Gondwana (EXTRA co-chair)
  Responsible Area Director - Alexey Melnikov


3. The Document Shepherd has read the document through in detail and
is happy that it's easy to implement.

4. There are no concerns about reviews, this document has been well reviewed.

5. There is no review required for the document by other areas.

6. There are no concerns with this document that IESG should be aware of.

7. There have been no IPR disclosures for this spec.

8. There have been no IPR disclosures for this spec.

9. The WG consensus is solid.

10. There has been no discontent.

11. The ID nits tool said one page was too long (60 lines rather than
58) however this may be due to instructions that will be removed before
publication.

12. This document doesn't define anything which needs formal review
outside the working group.

13. All references have been identified as either normative or
informative.

14. All normative references are published standards.

15. There are no downward normative references references.

16. This RFC does not change the status of any other RFCs.

17. The IANA considerations ask for a new registry to be created and an
expert to be designated.  The initial values for the registry are fully
specified with clear instructions, and a good name has been chosen for
the registry.  Sources for all the initial values in the registry have
been provided.

18. The new IANA registry (IMAP Mailbox Name Attributes) will require
an expert reviewer, who should have IMAP protocol experience and ideally
server implementation experience.

19. The formal sections are simple enough that eyeball reading
was sufficient to validate them.


2018-04-26
02 Bron Gondwana Responsible AD changed to Alexey Melnikov
2018-04-26
02 Bron Gondwana IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2018-04-26
02 Bron Gondwana IESG state changed to Publication Requested
2018-04-26
02 Bron Gondwana IESG process started in state Publication Requested
2018-04-26
02 Alexey Melnikov Intended Status changed to Proposed Standard from Internet Standard
2018-04-19
02 Barry Leiba New version available: draft-ietf-extra-specialuse-important-02.txt
2018-04-19
02 (System) New version approved
2018-04-19
02 (System) Request for posting confirmation emailed to previous authors: Barry Leiba
2018-04-19
02 Barry Leiba Uploaded new revision
2018-04-19
01 Barry Leiba New version available: draft-ietf-extra-specialuse-important-01.txt
2018-04-19
01 (System) New version approved
2018-04-19
01 (System) Request for posting confirmation emailed to previous authors: Barry Leiba
2018-04-19
01 Barry Leiba Uploaded new revision
2018-03-29
00 Bron Gondwana Changed document writeup
2018-03-29
00 Bron Gondwana Changed document writeup
2018-03-29
00 Bron Gondwana IETF WG state changed to In WG Last Call from WG Document
2018-03-29
00 Bron Gondwana Changed consensus to Yes from Unknown
2018-03-29
00 Bron Gondwana Intended Status changed to Internet Standard from None
2018-03-29
00 Bron Gondwana Notification list changed to Bron Gondwana <brong@fastmailteam.com>
2018-03-29
00 Bron Gondwana Document shepherd changed to Bron Gondwana
2018-03-29
00 Bron Gondwana This document now replaces draft-leiba-extra-specialuse-important instead of None
2018-03-29
00 Barry Leiba New version available: draft-ietf-extra-specialuse-important-00.txt
2018-03-29
00 (System) WG -00 approved
2018-03-22
00 Barry Leiba Set submitter to "Barry Leiba ", replaces to draft-leiba-extra-specialuse-important and sent approval email to group chairs: extra-chairs@ietf.org
2018-03-22
00 Barry Leiba Uploaded new revision