[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01                                                         
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 <ietf-imapext@imc.org>. 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 <<add informative reference>>.

     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.

     <<TODO: review the list and potentially add more types, like task
     lists>>


2.3.   SHAREDFLAGS parameter to CREATE command

     <<Also add PRIVATEFLAGS?>>

     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.  <<SHOULD
     because it can be moved to a different namespace that might have
     different restrictions>>




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

     <<Certain CREATE/RENAME parameters shouldn't be allowed for all
     users.  For example, a server implementation may restrict usage of
     the partion identifier parameter in CREATE/RENAME to users with
     administrative priveleges.>>




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"
        <<sync with section 2.2>>

        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


     <<TBD>>

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]