< draft-ietf-morg-list-specialuse-05.txt   draft-ietf-morg-list-specialuse-06.txt >
Message ORGanization Working Group B. Leiba Message ORGanization Working Group B. Leiba
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Standards Track J. Nicolson Intended status: Standards Track J. Nicolson
Expires: June 4, 2011 Google Expires: June 18, 2011 Google
December 1, 2010 December 15, 2010
IMAP LIST extension for special-use mailboxes IMAP LIST extension for special-use mailboxes
draft-ietf-morg-list-specialuse-05 draft-ietf-morg-list-specialuse-06
Abstract Abstract
Some IMAP message stores include special-use mailboxes, such as those Some IMAP message stores include special-use mailboxes, such as those
used to hold draft messages or sent messages. Many mail clients used to hold draft messages or sent messages. Many mail clients
allow users to specify where draft or sent messages should be put, allow users to specify where draft or sent messages should be put,
but configuring them requires that the user know which mailboxes the but configuring them requires that the user know which mailboxes the
server has set aside for these purposes. This extension adds new server has set aside for these purposes. This extension adds new
mailbox attributes that a server MAY include in IMAP LIST command optional mailbox attributes that a server may include in IMAP LIST
responses to identify special-use mailboxes to the client, easing command responses to identify special-use mailboxes to the client,
configuration. easing configuration.
Note
A revised version of this draft document will be submitted to the RFC
editor as a Proposed Standard for the Internet Community. Discussion
and suggestions for improvement are requested, and should be sent to
morg@ietf.org.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 4, 2011. This Internet-Draft will expire on June 18, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . . 4 1.1. Conventions used in this document . . . . . . . . . . . . . 3
2. New mailbox attributes identifying special-use mailboxes . . 4 2. New mailbox attributes identifying special-use mailboxes . . 3
3. Extension to IMAP CREATE command to set special-use 3. Extension to IMAP CREATE command to set special-use
attributes . . . . . . . . . . . . . . . . . . . . . . . . . 6 attributes . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. IMAP METADATA entry for special-use attributes . . . . . . . 7 4. IMAP METADATA entry for special-use attributes . . . . . . . 6
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Example of an IMAP LIST command . . . . . . . . . . . . . . 7 5.1. Example of an IMAP LIST command . . . . . . . . . . . . . . 7
5.2. Example of an extended IMAP LIST command . . . . . . . . . . 8 5.2. Example of an extended IMAP LIST command . . . . . . . . . . 7
5.3. Example of an IMAP CREATE command . . . . . . . . . . . . . 8 5.3. Example of an IMAP CREATE command . . . . . . . . . . . . . 8
5.4. Example of using IMAP METADATA to manipulate special-use 5.4. Example of using IMAP METADATA to manipulate special-use
attributes . . . . . . . . . . . . . . . . . . . . . . . . . 9 attributes . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 10 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10
8.1. Registration of USEATTR IMAP response code . . . . . . . . . 11 8.1. Registration of USEATTR IMAP response code . . . . . . . . . 11
8.2. Registration of CREATE-SPECIAL-USE IMAP capability . . . . . 11 8.2. Registration of CREATE-SPECIAL-USE IMAP capability . . . . . 11
8.3. Registration of SPECIAL-USE IMAP capability . . . . . . . . 11 8.3. Registration of SPECIAL-USE IMAP capability . . . . . . . . 11
8.4. Registration of SPECIAL-USE selection option . . . . . . . . 11 8.4. Registration of SPECIAL-USE selection option . . . . . . . . 11
8.5. Registration of SPECIAL-USE return option . . . . . . . . . 11 8.5. Registration of SPECIAL-USE return option . . . . . . . . . 11
8.6. Registration of SPECIAL-USE metadata . . . . . . . . . . . . 12 8.6. Registration of SPECIAL-USE metadata . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . . 13
skipping to change at page 3, line 4 skipping to change at page 2, line 43
8.1. Registration of USEATTR IMAP response code . . . . . . . . . 11 8.1. Registration of USEATTR IMAP response code . . . . . . . . . 11
8.2. Registration of CREATE-SPECIAL-USE IMAP capability . . . . . 11 8.2. Registration of CREATE-SPECIAL-USE IMAP capability . . . . . 11
8.3. Registration of SPECIAL-USE IMAP capability . . . . . . . . 11 8.3. Registration of SPECIAL-USE IMAP capability . . . . . . . . 11
8.4. Registration of SPECIAL-USE selection option . . . . . . . . 11 8.4. Registration of SPECIAL-USE selection option . . . . . . . . 11
8.5. Registration of SPECIAL-USE return option . . . . . . . . . 11 8.5. Registration of SPECIAL-USE return option . . . . . . . . . 11
8.6. Registration of SPECIAL-USE metadata . . . . . . . . . . . . 12 8.6. Registration of SPECIAL-USE metadata . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Some IMAP message stores include special-use mailboxes, such as those Some IMAP message stores include special-use mailboxes, such as those
used to hold draft messages or sent messages. Many mail clients used to hold draft messages or sent messages. Many mail clients
allow users to specify where draft or sent messages should be put, allow users to specify where draft or sent messages should be put,
but configuring them requires that the user know which mailboxes the but configuring them requires that the user know which mailboxes the
server has set aside for these purposes. This extension adds new server has set aside for these purposes. This extension adds new
mailbox attributes that a server MAY include in IMAP LIST command optional mailbox attributes that a server may include in IMAP LIST
responses to identify special-use mailboxes to the client, easing command responses to identify special-use mailboxes to the client,
configuration. easing configuration.
In addition, this extension adds an OPTIONAL parameter on the IMAP In addition, this extension adds an optional parameter on the IMAP
CREATE command, allowing a client to assign a special use to a CREATE command, allowing a client to assign a special use to a
mailbox when it is created. Servers MAY choose to support this part mailbox when it is created. Servers may choose to support this part
of the extension, but are not required to. of the extension, but are not required to.
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 examples, "C:" indicates lines sent by a client that is connected
to a server. "S:" indicates lines sent by the server to the client. to a server. "S:" indicates lines sent by the server to the client.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 6, line 13 skipping to change at page 5, line 13
almost certain to represent a virtual mailbox. almost certain to represent a virtual mailbox.
\Archive \Archive
This mailbox is used to archive messages. The meaning of an This mailbox is used to archive messages. The meaning of an
"archival" mailbox is server-dependent; typically, it will be "archival" mailbox is server-dependent; typically, it will be
used to get messages out of the inbox, or otherwise keep them used to get messages out of the inbox, or otherwise keep them
out of the user's way, while still making them accessible. out of the user's way, while still making them accessible.
All of the above attributes are OPTIONAL, and any given server or All of the above attributes are OPTIONAL, and any given server or
message store may support any combination of the attributes, or none message store may support any combination of the attributes, or none
at all. In some server or message store implementations it might be at all. In most cases there will likely be at most one mailbox with
possible for multiple mailboxes to have the same special-use a given attribute for a given user, but in some server or message
attribute. store implementations it might be possible for multiple mailboxes to
have the same special-use attribute.
Special-use attributes are likely to be user-specific. User Adam Special-use attributes are likely to be user-specific. User Adam
might share his \Sent mailbox with user Barb, but that mailbox is might share his \Sent mailbox with user Barb, but that mailbox is
unlikely to also serve as Barb's \Sent mailbox. It's certainly unlikely to also serve as Barb's \Sent mailbox. It's certainly
possible for Adam and Barb to each set the \Sent use on the same possible for Adam and Barb to each set the \Sent use on the same
mailbox, but that would be done by specific action (see the sections mailbox, but that would be done by specific action (see the sections
below). below).
3. Extension to IMAP CREATE command to set special-use attributes 3. Extension to IMAP CREATE command to set special-use attributes
skipping to change at page 7, line 36 skipping to change at page 6, line 37
response. response.
Such a server MAY allow the setting of special-use attributes through Such a server MAY allow the setting of special-use attributes through
the METADATA mechanisms, thereby allowing clients to change the the METADATA mechanisms, thereby allowing clients to change the
special uses of existing mailboxes. These changes might have side special uses of existing mailboxes. These changes might have side
effects, as the server automatically adjusts the special uses effects, as the server automatically adjusts the special uses
accordingly, just as it might do with CREATE USE, above. See accordingly, just as it might do with CREATE USE, above. See
Section 5.4 for an example. Section 5.4 for an example.
A server that supports this MUST check the validity of changes to the A server that supports this MUST check the validity of changes to the
special-use attributes that are done through the metadata. It MUST special-use attributes that are done through the metadata in the same
NOT allow a client to set invalid or unsupported attributes, nor to way that it checks validity for the CREATE command and for any
create conflicting or otherwise invalid situations. internal mechanisms for setting special uses on mailboxes. It MUST
NOT just blindly accept setting of these metadata by clients, which
might result in the setting of special uses that the implementation
does not support, multiple mailboxes with the same special use, or
other situations that the implementation considers invalid.
5. Examples 5. Examples
5.1. Example of an IMAP LIST command 5.1. Example of an IMAP LIST command
This example shows an IMAP LIST response from a server that supports This example shows an IMAP LIST response from a server that supports
this extension. Note that not all of the attributes are used. This this extension. Note that not all of the attributes are used. This
server also supports the Child Mailbox extension [RFC3348]. server also supports the Child Mailbox extension [RFC3348].
C: t1 LIST "" "%" C: t1 LIST "" "%"
S: * LIST (\Marked \HasNoChildren) "/" Inbox S: * LIST (\Marked \HasNoChildren) "/" Inbox
S: * LIST (\HasNoChildren) "/" ToDo S: * LIST (\HasNoChildren) "/" ToDo
S: * LIST (\HasChildren) "/" Projects S: * LIST (\HasChildren) "/" Projects
skipping to change at page 10, line 44 skipping to change at page 10, line 29
; Server implementations MUST NOT generate ; Server implementations MUST NOT generate
; extension attributes except as defined by ; extension attributes except as defined by
; future standards-track revisions of or ; future standards-track revisions of or
; extensions to this specification. ; extensions to this specification.
7. Security Considerations 7. Security Considerations
LIST response: There are no security issues with conveying special- LIST response: There are no security issues with conveying special-
use information to a client. use information to a client.
CREATE command "USE" parameter: In some server implementations, some CREATE command "USE" parameter and metadata extension: In some server
special uses may imply automatic action by the server. For example, implementations, some special uses may imply automatic action by the
creation of a "\Junk" mailbox might cause the server to start placing server. For example, creation of a "\Junk" mailbox might cause the
messages that have been evaluated as spam into the mailbox. server to start placing messages that have been evaluated as spam
Implementors SHOULD consider the consequences of allowing a user (or into the mailbox. Implementors SHOULD consider the consequences of
client program) to designate the target of such automatic action. allowing a user (or client program) to designate the target of such
automatic action.
8. IANA Considerations Example: If a user is allowed to give the "\Junk" attribute to a
shared mailbox, legitimate mail that's misclassified as junk (false
positives) will be put into that shared mailbox, exposing the user's
private mail to others. The server might warn a user of that
possibility, or might refuse to allow the specification to be made on
a shared mailbox. (Note that this problem exists independent of this
specification, if the server allows a user to share a mailbox that's
already in use for such a function.)
8. IANA Considerations
8.1. Registration of USEATTR IMAP response code 8.1. Registration of USEATTR IMAP response code
This document defines a new IMAP response code. IANA is asked to add This document defines a new IMAP response code. IANA is asked to add
"USEATTR" to the IMAP Response Codes registry. "USEATTR" to the IMAP Response Codes registry.
8.2. Registration of CREATE-SPECIAL-USE IMAP capability 8.2. Registration of CREATE-SPECIAL-USE IMAP capability
This document defines a new IMAP capability. IANA is asked to add This document defines a new IMAP capability. IANA is asked to add
"CREATE-SPECIAL-USE" to the IMAP 4 Capabilities registry. "CREATE-SPECIAL-USE" to the IMAP 4 Capabilities registry.
 End of changes. 23 change blocks. 
43 lines changed or deleted 50 lines changed or added

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