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 |