Skip to main content

IMAP LIST Extension for Special-Use Mailboxes
RFC 6154

Revision differences

Document history

Date Rev. By Action
2015-10-14
06 (System) Notify list changed from morg-chairs@ietf.org, draft-ietf-morg-list-specialuse@ietf.org to (None)
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Sean Turner
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Peter Saint-Andre
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Ralph Droms
2011-03-03
06 Cindy Morgan State changed to RFC Published from RFC Ed Queue.
2011-03-03
06 Cindy Morgan [Note]: changed to 'RFC 6154'
2011-03-03
06 (System) RFC published
2010-12-21
06 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent.
2010-12-20
06 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2010-12-20
06 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2010-12-20
06 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-12-20
06 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-12-20
06 (System) IANA Action state changed to In Progress
2010-12-20
06 Amy Vezza IESG state changed to Approved-announcement sent
2010-12-20
06 Amy Vezza IESG has approved the document
2010-12-20
06 Amy Vezza Closed "Approve" ballot
2010-12-20
06 Amy Vezza Approval announcement text regenerated
2010-12-17
06 Alexey Melnikov Ballot writeup text changed
2010-12-17
06 (System) Removed from agenda for telechat - 2010-12-16
2010-12-16
06 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Chris Lonvick.
2010-12-16
06 Amy Vezza State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation.
2010-12-16
06 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded
2010-12-16
06 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded
2010-12-16
06 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2010-12-16
06 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2010-12-15
06 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded
2010-12-15
06 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2010-12-15
06 Alexey Melnikov Ballot writeup text changed
2010-12-15
06 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2010-12-15
06 Alexey Melnikov State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2010-12-15
06 (System) New version available: draft-ietf-morg-list-specialuse-06.txt
2010-12-15
06 Sean Turner
[Ballot discuss]
This is a modified position.  I've removed those that have been addressed.  The remaining two will be cleared after the RFC editor's note/new …
[Ballot discuss]
This is a modified position.  I've removed those that have been addressed.  The remaining two will be cleared after the RFC editor's note/new version has been posted:

#2) Are there any security considerations with combining special-use to the metadata extension?

#3) There's also some text Barry & Chris have agreed to incorporate based on Chris' SECDIR review:
http://www.ietf.org/mail-archive/web/secdir/current/msg02277.html
2010-12-15
06 Ralph Droms
[Ballot comment]
From this example in section 5.4 and a brief e-mail exchange with Barry:


    ==> Set new use for SavedDrafts; MyDrafts changes …
[Ballot comment]
From this example in section 5.4 and a brief e-mail exchange with Barry:


    ==> Set new use for SavedDrafts; MyDrafts changes automatically:
    C: t3 SETMETADATA "SavedDrafts" (/shared/specialuse "\Drafts")
    S: * METADATA "MyDrafts" (/shared/specialuse NIL)
    S: t3 OK SETMETADATA complete

I infer that, in this example, only one mailbox on the server can have
the \Drafts attribute.  This text from section 2 gives a hint that a
server may have a restriction that only one mailbox at a time may be
assigned a specific special use attribute:

  All of the above attributes are OPTIONAL, and any given server or
  message store may support any combination of the attributes, or none
  at all.  In some server or message store implementations it might be
  possible for multiple mailboxes to have the same special-use
  attribute.

It would make the restriction explicit to add text here to the effect of "Some
servers or message store implementations may restrict the use of
special use attributes so that only one mailbox is assigned each
special use attribute."
2010-12-15
06 Ralph Droms [Ballot Position Update] Position for Ralph Droms has been changed to No Objection from Discuss
2010-12-15
06 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2010-12-14
06 Ralph Droms
[Ballot discuss]
This is a very brief DISCUSS and quite likely something I just missed in the text.

From this example in section 5.4:


  …
[Ballot discuss]
This is a very brief DISCUSS and quite likely something I just missed in the text.

From this example in section 5.4:


    ==> Set new use for SavedDrafts; MyDrafts changes automatically:
    C: t3 SETMETADATA "SavedDrafts" (/shared/specialuse "\Drafts")
    S: * METADATA "MyDrafts" (/shared/specialuse NIL)
    S: t3 OK SETMETADATA complete

should I infer that only one mailbox on the server can have the
\Drafts attribute?  If I have that right, is that restriction
explicitly written down somewhere in the doc?  Or, is the uniqueness
of a \Drafts mailbox up to the server, which should also be written
down?  Or, am I completely confused and misunderstanding the example?
2010-12-14
06 Ralph Droms [Ballot Position Update] New position, Discuss, has been recorded
2010-12-14
06 David Harrington [Ballot Position Update] New position, No Objection, has been recorded
2010-12-14
06 Sean Turner
[Ballot discuss]
I have a sinking suspicion that I'll clear #1 on or before the call (and maybe #2 too):

#1) I use Thunderbird and …
[Ballot discuss]
I have a sinking suspicion that I'll clear #1 on or before the call (and maybe #2 too):

#1) I use Thunderbird and it calls the "Archive" "Archives" and "Sent" "Outbox".  I'm assuming it doesn't matter what the folder is called as long as it's "marked" the right way on the server - right?

#2) Are there any security considerations with combining special-use to the metadata extension?

This one will be cleared once a new version or RFC editor's note is posted:

#3) There's also some text Barry & Chris have agreed to incorporate based on Chris' SECDIR review:
http://www.ietf.org/mail-archive/web/secdir/current/msg02277.html
2010-12-14
06 Sean Turner
[Ballot discuss]
I have a sinking suspicion that I'll clear #1 on or before the call (and maybe #2 too):

#1) I use Thunderbird and …
[Ballot discuss]
I have a sinking suspicion that I'll clear #1 on or before the call (and maybe #2 too):

#1) I use Thunderbird and it calls the "Archive" "Archives" and "Sent" "Outbox".  I guess it doesn't matter what the folder is called as long as it's "marked" the right way on the server - right?

#2) Are there any security considerations with combining special-use to the metadata extension?
2010-12-14
06 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded
2010-12-14
06 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2010-12-13
06 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded
2010-12-13
06 Adrian Farrel
[Ballot comment]
I don't think it is appropriate to use RFC2119 terminology in the
Abstract.

It is probably also not appropriate in the Introduction.

--- …
[Ballot comment]
I don't think it is appropriate to use RFC2119 terminology in the
Abstract.

It is probably also not appropriate in the Introduction.

---

It would be nice to capitalise the section headings.

---

Section 7

  LIST response: There are no security issues with conveying special-
  use information to a client.

Really. Doesn't the exchange of information imply that there is
potential to intercept the information. Knowledge of the message store
usage may be valuable to someone attempting to access messages.
2010-12-13
06 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded
2010-12-13
06 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded
2010-12-09
06 Amanda Baber [Note]: 'Timo Sirainen <tss@iki.fi> is the document shepherd.<br>' added by Amanda Baber
2010-12-09
06 Amanda Baber
IANA understands that, upon approval of this document, there are six
IANA Actions that need to be completed.

First, in the IMAP Response Code registry …
IANA understands that, upon approval of this document, there are six
IANA Actions that need to be completed.

First, in the IMAP Response Code registry located at:

http://www.iana.org/assignments/imap-response-codes/imap-response-codes.xhtml

The following registration will be added:

Response: USEATTR
Reference: [RFC-to-be]
Status Description: <left blank>

Second, in the Internet Message Access Protocol (IMAP) 4 Capabilities
Registry located at:

http://www.iana.org/assignments/imap4-capabilities

the following capability is to be registered:

Capability name: CREATE-SPECIAL-USE
Reference: [RFC-to-be]

Third, in the Internet Message Access Protocol (IMAP) 4 Capabilities
Registry located at:

http://www.iana.org/assignments/imap4-capabilities

the following capability is to be registered:

Capability name: SPECIAL-USE
Reference: [RFC-to-be]

Fourth, in the Internet Message Access Protocol (IMAP) 4 LIST EXTENDED
registry located at:

http://www.iana.org/assignments/imap4-list-extended

the following registration will be added:

LIST-EXTENDED option name: SPECIAL-USE
LIST-EXTENDED option type: SELECTION
Implied return option(s): SPECIAL-USE
LIST-EXTENDED option description: Limit the list to special-use
mailboxes only
Published specification: [RFC-to-be]
Security considerations: none
Intended usage: COMMON
Person and email address to contact for further information: Authors'
Addresses
at the end of the published [RFC-to-be]
Owner/Change controller: iesg@ietf.org

Fifth, in the Internet Message Access Protocol (IMAP) 4 LIST EXTENDED
registry located at:

http://www.iana.org/assignments/imap4-list-extended

the following registration will be added:

LIST-EXTENDED option name: SPECIAL-USE
LIST-EXTENDED option type: RETURN
LIST-EXTENDED option description: Request special-use mailbox information
Published specification: [RFC-to-be]
Security considerations: none
Intended usage: COMMON
Person and email address to contact for further information: Authors'
Addresses
at the end of the published [RFC-to-be]
Owner/Change controller: iesg@ietf.org

Sixth, a new registration is to be made in the IMAP METADATA Mailbox
Entry Registry located at:

http://www.iana.org/assignments/imap-metadata/imap-metadata.xhtml

as follows:

Name: /shared/specialuse
Content-type: text/plain; charset=us-ascii
Reference: [RFC-to-be]

IANA understands that these six actions are all that need to be
completed upon approval of this document.
2010-12-07
06 Alexey Melnikov [Note]: changed to 'Timo Sirainen <tss@iki.fi> is the document shepherd.<br>'
2010-12-07
06 Alexey Melnikov Ballot writeup text changed
2010-12-07
06 Peter Saint-Andre [Ballot Position Update] Position for Peter Saint-Andre has been changed to No Objection from Discuss
2010-12-06
06 Peter Saint-Andre
[Ballot discuss]
This is a fine document. I have one issue that I would like to discuss.

Section 4 states:

  A server that supports …
[Ballot discuss]
This is a fine document. I have one issue that I would like to discuss.

Section 4 states:

  A server that supports this MUST check the validity of changes to the
  special-use attributes that are done through the metadata.  It MUST
  NOT allow a client to set invalid or unsupported attributes, nor to
  create conflicting or otherwise invalid situations.

However, the spec does not define what it means for attributes to be invalid or unsupported, nor what it means for situations to be conflicting or invalid. Can we provide some guidance to server implementers here? And what is the proper error handling on the part of the server (e.g., how does it signal to the client exactly which aspects of the request have been honored)?
2010-12-06
06 Peter Saint-Andre [Ballot Position Update] New position, Discuss, has been recorded
2010-12-03
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Chris Lonvick
2010-12-03
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Chris Lonvick
2010-12-02
06 Alexey Melnikov [Note]: changed to 'As per IETF LC comment: rename the /shared/... to /private/...<br><br>Timo Sirainen <tss@iki.fi> is the document shepherd.<br>'
2010-12-02
06 Alexey Melnikov
(1.a) Who is the Document Shepherd for this document? Has the
      Document Shepherd personally reviewed this version of the
      …
(1.a) Who is the Document Shepherd for this document? Has the
      Document Shepherd personally reviewed this version of the
      document and, in particular, does he or she believe this
      version is ready for forwarding to the IESG for publication?

Timo Sirainen is the Shepherd. I have reviewed this version and believe
it's ready.

(1.b) Has the document had adequate review both from key WG members
      and from key non-WG members? Does the Document Shepherd have
      any concerns about the depth or breadth of the reviews that
      have been performed? 

The document has had adequate review. I have no concerns.

(1.c) Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective,
      e.g., security, operational complexity, someone familiar with
      AAA, internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or
      issues with this document that the Responsible Area Director
      and/or the IESG should be aware of? For example, perhaps he
      or she is uncomfortable with certain parts of the document, or
      has concerns whether there really is a need for it. In any
      event, if the WG has discussed those issues and has indicated
      that it still wishes to advance the document, detail those
      concerns here. Has an IPR disclosure related to this document
      been filed? If so, please include a reference to the
      disclosure and summarize the WG discussion and conclusion on
      this issue.

I have no concerns. There have been no IPR disclosures.

(1.e) How solid is the WG consensus behind this document? Does it
      represent the strong concurrence of a few individuals, with
      others being silent, or does the WG as a whole understand and
      agree with it? 

WG as a whole agrees with the document. There are no unresolved
disagreements.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
      discontent? If so, please summarise the areas of conflict in
      separate email messages to the Responsible Area Director. (It
      should be in a separate email because this questionnaire is
      entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
      document satisfies all ID nits? (See the Internet-Drafts Checklist
      and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
      not enough; this check needs to be thorough. Has the document
      met all formal review criteria it needs to, such as the MIB
      Doctor, media type and URI type reviews?

Yes. I verified with idnits 2.12.05 and went through the checklist. I found
no problems.

(1.h) Has the document split its references into normative and
      informative? Are there normative references to documents that
      are not ready for advancement or are otherwise in an unclear
      state? If such normative references exist, what is the
      strategy for their completion? Are there normative references
      that are downward references, as described in [RFC3967]? If
      so, list these downward references to support the Area
      Director in the Last Call procedure for them [RFC3967].

All the references are correctly set as normative. There are no downward
references.

(1.i) Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body
      of the document? If the document specifies protocol
      extensions, are reservations requested in appropriate IANA
      registries? Are the IANA registries clearly identified? If
      the document creates a new registry, does it define the
      proposed initial contents of the registry and an allocation
      procedure for future registrations? Does it suggest a
      reasonable name for the new registry? See [RFC5226]. If the
      document describes an Expert Review process has Shepherd
      conferred with the Responsible Area Director so that the IESG
      can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section exists and is correct, except the IMAP
METADATA Entry should use /private instead of /shared prefix.

(1.j) Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML
      code, BNF rules, MIB definitions, etc., validate correctly in
      an automated checker?

ABNF rules validate correctly with Chris Newman's ABNF Validator.

(1.k) The IESG approval announcement includes a Document
      Announcement Write-Up. Please provide such a Document
      Announcement Write-Up? Recent examples can be found in the
      "Action" announcements for approved documents. The approval
      announcement contains the following sections:

    Technical Summary
      Relevant content can frequently be found in the abstract
      and/or introduction of the document. If not, this may be
      an indication that there are deficiencies in the abstract
      or introduction.

Some IMAP message stores include special-use mailboxes, such as those
used to hold draft messages or sent messages.  Many mail clients
allow users to specify where draft or sent messages should be put,
but configuring them requires that the user know which mailboxes the
server has set aside for these purposes.  This extension adds new
mailbox attributes that a server MAY include in IMAP LIST command
responses to identify special-use mailboxes to the client, easing
configuration.

    Working Group Summary
      Was there anything in WG process that is worth noting? For
      example, was there controversy about particular points or
      were there decisions where the consensus was particularly
      rough?

There were some concerns about the number of IMAP CAPABILITY strings and
about moving of existing special-use attributes, but there have been no
complaints about the end result.

    Document Quality
      Are there existing implementations of the protocol? Have a
      significant number of vendors indicated their plan to
      implement the specification? Are there any reviewers that
      merit special mention as having done a thorough review,
      e.g., one that resulted in important changes or a
      conclusion that the document had no substantive issues? If
      there was a MIB Doctor, Media Type or other expert review,
      what was its course (briefly)? In the case of a Media Type
      review, on what date was the request posted?

This extension is based on Google's XLIST extension for GMail. Google has
expressed interest in implementing this extension as well, among several
other server vendors. Many clients have already implemented XLIST, and they
will either automatically or with very small modifications gain support for
this extension.
2010-12-02
06 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2010-12-02
06 Alexey Melnikov Ballot has been issued
2010-12-02
06 Alexey Melnikov Created "Approve" ballot
2010-12-02
06 Alexey Melnikov [Note]: 'As per IETF LC comment: rename the /shared/... to /private/...' added
2010-12-01
05 (System) New version available: draft-ietf-morg-list-specialuse-05.txt
2010-12-01
06 Amy Vezza Last call sent
2010-12-01
06 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <morg@ietf.org>
Reply-To: ietf@ietf.org
Subject: Last Call: <draft-ietf-morg-list-specialuse-04.txt> (IMAP LIST extension for special-use mailboxes) to Proposed Standard


The IESG has received a request from the Message Organization WG (morg)
to consider the following document:
- 'IMAP LIST extension for special-use mailboxes'
  <draft-ietf-morg-list-specialuse-04.txt> as a 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 2010-12-15. 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.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-morg-list-specialuse/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-morg-list-specialuse/
2010-12-01
06 Alexey Melnikov Placed on agenda for telechat - 2010-12-16
2010-12-01
06 Alexey Melnikov Last Call was requested
2010-12-01
06 (System) Ballot writeup text was added
2010-12-01
06 (System) Last call text was added
2010-12-01
06 (System) Ballot approval text was added
2010-12-01
06 Alexey Melnikov State changed to Last Call Requested from AD Evaluation::AD Followup.
2010-12-01
06 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-12-01
04 (System) New version available: draft-ietf-morg-list-specialuse-04.txt
2010-12-01
06 Alexey Melnikov State changed to AD Evaluation::Revised ID Needed from AD is watching::Revised ID Needed.
2010-11-23
06 Alexey Melnikov State changed to AD is watching::Revised ID Needed from AD is watching::AD Followup.
2010-11-14
06 Alexey Melnikov
AD review complete and ABNF verified with BAP (as of draft-ietf-morg-list-specialuse-03):

; SP UNDEFINED
create-param = / "USE" SP "(" [ use-flag *( SP …
AD review complete and ABNF verified with BAP (as of draft-ietf-morg-list-specialuse-03):

; SP UNDEFINED
create-param = / "USE" SP "(" [ use-flag *( SP use-flag ) ] ")"
mbx-list-oflag = / use-flag
list-select-independent-opt = / "SPECIAL-USE"
return-option = / "SPECIAL-USE"
resp-text-code = / "USEFLAG"
use-flag = "\All" / "\Archive" / "\Drafts" / "\Flagged" / "\Junk" / "\Sent" / "\Trash" / use-flag-ext
; atom UNDEFINED
use-flag-ext = "\" atom
; create-param defined but not used
; mbx-list-oflag defined but not used
; list-select-independent-opt defined but not used
; return-option defined but not used
; resp-text-code defined but not used

I think this is correct.
2010-11-08
06 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-11-08
03 (System) New version available: draft-ietf-morg-list-specialuse-03.txt
2010-06-18
06 Alexey Melnikov Draft Added by Alexey Melnikov in state AD is watching
2010-06-18
02 (System) New version available: draft-ietf-morg-list-specialuse-02.txt
2010-02-10
01 (System) New version available: draft-ietf-morg-list-specialuse-01.txt
2010-01-26
00 (System) New version available: draft-ietf-morg-list-specialuse-00.txt