Internet Draft: Reporting flag state in IMAP A. Melnikov Document: draft-melnikov-imap-createparams-01.txt Isode Ltd. Expires: March 2006 September 2005 Intended category: Standards Track IMAP CREATE/RENAME parameters Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 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 the IMAPEXT Mailing list . Distribution of this draft is unlimited. Abstract When creating (or renaming) a mailbox in [IMAP4] it is desirable to be able to specify additional creation time parameters that can't be changed after the mailbox is created. Some examples of the creation time parameters are: mailbox type, mailbox location on a server or a cluster of servers, mailbox flag state. This document extends IMAP CREATE and RENAME commands to allow for such parameters. A server which supports this extension indicates this with a capability name of "X-DRAFT-I01-CREATEPARAM". Melnikov Expires: March 2006 [Page 1] INTERNET DRAFT IMAP CREATE parameters September 2005 Table of Contents 0. To do.........................................................1 1. Conventions Used in this Document.............................2 2. Extended CREATE command.......................................X 2.1. Partition identifier parameter to CREATE command.............X 2.2. TYPE parameter to CREATE command.............................X 2.3. SHAREDFLAGS parameter to CREATE command......................X 3. Extended RENAME command.......................................X 4. Security Considerations.......................................X 5. Formal Syntax.................................................X 6. IANA considerations...........................................X 7. Acknowledgments...............................................X 8. Normative References..........................................X 9. Author's Addresses............................................X 10. Intellectual Property.........................................X 11. Full Copyright Statement......................................X 1. Conventions Used in this Document "C:" and "S:" in examples show lines sent by the client and server respectively. The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document when typed in uppercase are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. Melnikov Expires: March 2006 [Page 2] INTERNET DRAFT IMAP CREATE parameters September 2005 2. Extended CREATE command Arguments: mailbox name OPTIONAL list of CREATE parameters Responses: no specific responses for this command Result: OK - create completed NO - create failure: can't create mailbox with that name and parameters BAD - argument(s) invalid See section 6.3.3 of [IMAP4] for the description of the basic CREATE command. The text in this section only describes how this behavior is modified by additional parameter. This extension adds the ability to include one or more parameters with the IMAP CREATE command, to turn on or off certain standard behaviour, or to add new optional behaviours required for a particular extension. Optional parameters to the CREATE command are added as a parenthesised list of attribute/value pairs after the mailbox name. Each value can be either an atom, a string or a list. The order of individual parameters is arbitrary. Individual parameters may consist of one or more atoms or strings in a specific order. If a parameter consists of more than one atom or string, it MUST appear in its own parenthesised list. Any parameter not defined by extensions that the server supports MUST be rejected with a BAD response. Several new CREATE command parameters are defined in subsequent sections. Extended CREATE can't be used to modify parameters of an already existing mailbox. The server MUST return NO to any such request. Example: C: a CREATE Forms (PARTITION Server1:partition5 TYPE CALENDAR) S: a OK CREATE complete In the above example, the mailbox "Forms" is create on partition names "Server1:partition5" and has a type CALENDAR. See also section 2.2. 2.1. Partition identifier parameter to CREATE and RENAME commands Several existing IMAP servers support a concept of "partition". A partition describes a collection of related mailboxes in a mailstore. Each partition is identified by a unique partition Melnikov Expires: March 2006 [Page 3] INTERNET DRAFT IMAP CREATE parameters September 2005 identifier, which may contains a globally unique prefix (e.g. host name or domain name), followed by a local partition identifier. For example, a server implementation that stores mailboxes in a filesystem may choose to use the root directory for a partition as the local partition identifier. (See also the Security Considerations section for discussions about partition naming.) Servers that don't support the partition concept SHOULD ignore the partition parameter to CREATE and RENAME commands. 2.1.1. Additional requirements on the partition identifier parameter to CREATE Note, If the partition identifier parameter is not specified, the server supporting multiple partitions uses internal policy to assign the new mailbox to one of the existing partitions. If one or more of the superior hierarchical mailboxes doesn't exist the server SHOULD create such superior mailboxes, as described in section 6.3.3 of [IMAP4]. Such superior mailboxes SHOULD be assigned to the same partition as the mailbox itself. In other words, an attempt to create "foo/bar/zap" on a server in which "/" is the hierarchy separator character SHOULD create foo/ and foo/bar/ if they do not already exist. If the mailbox "foo" already exists and is assigned to "partition1" and the client requests to create "foo/bar/zap" on "partition2", than the server SHOULD create both "foo/bar" and "foo/bar/zap" on "partition2". 2.2. TYPE parameter to CREATE command Many existing IMAP servers provide access to specialized mailstores, for example mailstores that can store voice messages as described in VPIM <>. The TYPE parameter to CREATE command allows the client to give a hint about intended usage of the mailbox to be created. Such hint can be used by the server to choose storage format. For example, some storage formats can only store or be optimized for certain types of MIME messages. This document defines the following initial set of mailbox types: - "CONTACT" - can contain MIME messages containing text/plain (?) and vCARD - "CALENDAR" - can contain vCALENDAR objects as described in <<>> - "VOICE" - "IMAGE" Melnikov Expires: March 2006 [Page 4] INTERNET DRAFT IMAP CREATE parameters September 2005 - "VIDEO" - "JUNK" - messages identified by the user as junk. Messages MAY be deleted automatically from such mailbox after some period of time. - "VIEW" - "virtual mailbox", created using a persistent mailbox search mechanism. <> 2.3. SHAREDFLAGS parameter to CREATE command <> Let's call a flag shared for a mailbox if the mailbox may be set up so that any changes to this flag by a user A are persistent and visible to a different user B. Note, that different mailboxes may have different flags as shared. SHAREDFLAGS parameter allows to specify which system flags and user defined keywords should be shared for the mailbox. It also allows to "precreate" some user defined keyword. The server is not required to be able to store any particular system flag or user defined keyword as shared. If the server is unable to persistently store certain flags from SHAREFLAGS list or store certain flags as shared (or unable to store any user defined flag, when a user defined flag is specified), it MUST return NO to the CREATE command with the SHAREDFLAGS parameter and MUST NOT create the mailbox. If multiple flags are specified in the SHAREDFLAGS parameter the server MUST either be able to store all requested flags as shared or fail the command with the tagged NO response. The server MAY restrict which users can create a mailbox with SHAREDFLAGS parameter and which flags may be stored as shared. When a child submailbox is created and no SHAREDFLAGS parameter is specified, the parent SHAREDFLAGS settings SHOULD be used. If a mailbox created with SHAREDFLAGS parameter is subsequently renamed, the SHAREDFLAGS settings SHOULD be preserved. <> Melnikov Expires: March 2006 [Page 5] INTERNET DRAFT IMAP CREATE parameters September 2005 A server which supports the SHAREDFLAGS parameter to the CREATE command indicates this with a capability name of "X-DRAFT- I00-CREATEFLAGS". This is in addition to the "X-DRAFT- I00-CREATEPARAM" capability. Example: C: a CREATE Forms (SHAREDFLAGS (\Seen $MDNSent)) S: a OK CREATE completed. Requested flags are shared. ... C: b SELECT Forms S: * 172 EXISTS S: * 1 RECENT S: * OK [UNSEEN 12] Message 12 is first unseen S: * OK [UIDVALIDITY 3857529045] UIDs valid S: * OK [UIDNEXT 4392] Predicted next UID S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft $MDNSent) S: * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen $MDNSent)] Draft flag is not permanent S: * OK [SHAREDFLAGS (\Seen $MDNSent)] Limited S: b OK [READ-WRITE] SELECT completed 3. Extended RENAME command Arguments: existing mailbox name new mailbox name OPTIONAL list of RENAME parameters Responses: no specific responses for this command Result: OK - rename completed NO - rename failure: can't rename mailbox with that name, can't rename to mailbox with that name, can't move the mailbox to the specified partition, etc. BAD - argument(s) invalid See section 6.3.5 of [IMAP4] for the description of the basic RENAME command. The text in this section only describes how this behavior is modified by additional parameter. This extension adds the ability to include one or more parameters with the IMAP RENAME command, to turn on or off certain standard behaviour, or to add new optional behaviours required for a particular extension. Optional parameters to the RENAME command are added as a parenthesised list of attribute/value pairs after the mailbox name. Each value can be either an atom, a string or a list. The order of individual parameters is arbitrary. Individual parameters may consist of one or more atoms or strings in a Melnikov Expires: March 2006 [Page 6] INTERNET DRAFT IMAP CREATE parameters September 2005 specific order. If a parameter consists of more than one atom or string, it MUST appear in its own parenthesised list. Any parameter not defined by extensions that the server supports MUST be rejected with a BAD response. Note that not all CREATE parameters are allowed as RENAME parameters and vice versa. The RENAME command changes the name of a mailbox from "existing mailbox name" to "new mailbox name". One of the RENAME command parameters is the partition identifier parameter, which is described in more details in section 2.1. Servers that don't support the partition concept SHOULD ignore the partition parameter. When the new partition identifier parameter is specified the server is requested to "move" the mailbox to a different partition. Thus in order to move a mailbox between two partitions the client can issue a RENAME command with the new mailbox name being the same as the existing mailbox name, and the partition identifier parameter specifying the new partition. If one or more of the superior hierarchical mailboxes for the new mailbox name doesn't exist the server SHOULD create such superior mailboxes, as described in section 6.3.5 of [IMAP4]. Such superior mailboxes SHOULD be assigned to the same partition as the new mailbox name itself. In other words, an attempt to rename "foo/bar/zap" to "baz/rag/zowie" on a server in which "/" is the hierarchy separator character SHOULD create baz/ and baz/rag/ if they do not already exist. If the mailbox "baz" already exists and is assigned to "partition1" and the client requests to move "foo/bar/zap" to "partition2", than the server SHOULD create both "baz/rag" and "baz/rag/zowie" on "partition2". If the existing mailbox name has inferior hierarchical mailboxes, then the inferior hierarchical mailboxes MUST also be renamed. For example, a rename of "foo" to "zap" will rename "foo/bar" (assuming "/" is the hierarchy delimiter character) to "zap/bar". If the new partition identifer parameter is specified, than all inferior mailboxes SHOULD be moved to the specified partition. 4. Security Considerations <> Melnikov Expires: March 2006 [Page 7] INTERNET DRAFT IMAP CREATE parameters September 2005 A partition name may disclose too match information about particular implementation. For example, if different partitions are implemented as different directories in a file system, and a partition name is the file system path, partition name may disclose the file system layout. 5. Formal Syntax Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4]. Non-terminals referenced but not defined below are as defined by [ABNF], [IMAP4] or [IMAPABNF]. Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. capability =/ "X-DRAFT-I00-CREATEPARAM" / "X-DRAFT-I00-CREATEFLAGS" ;; "capability" is defined in [IMAP4] create-param =/ partition-param / ("TYPE" SP mailbox-type) / ("SHAREDFLAGS" SP flag-list) ;; "flag-list" is defined in [IMAP4] mailbox-type = "CONTACT" / "CALENDAR" / "VOICE" / "IMAGE" / "VIDEO" / "JUNK" / "VIEW" <> partition-param = "PARTITION" SP partition partition = [partition-server ":"] partition-local ;; use astring instead? partition-server = atom ;; No ":" allowed, unless IPv6 address? partition-local = atom ;; No ":" allowed rename-param =/ partition-param 6. IANA considerations Melnikov Expires: March 2006 [Page 8] INTERNET DRAFT IMAP CREATE parameters September 2005 <> 7. Acknowledgments The author would like to thank Cyrus Daboo for the initial motivation for this document. 8. Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, November 1997. [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, University of Washington, March 2003. [IMAPABNF] Melnikov, A., and C. Daboo, "Collected extensions to IMAP4 ABNF", work in progress, draft-melnikov-imap-ext-abnf-XX.txt. 9. Author's Addresses Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX, UK Email: Alexey.Melnikov@isode.com URI: http://www.melnikov.ca/ Melnikov Expires: March 2006 [Page 9] INTERNET DRAFT IMAP CREATE parameters September 2005 10. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 11. Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Melnikov Expires: March 2006 [Page 10]