[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 5788

Network Working Group                                        A. Melnikov
Internet-Draft                                               D. Cridland
Intended status: Standards Track                           Isode Limited
Expires: June 14, 2010                                 December 11, 2009


                         IMAP4 Keyword Registry
                    draft-melnikov-imap-keywords-10

Abstract

   The aim of this document is to establishe a new IANA registry for
   IMAP keywords and to define a procedure for keyword registration, in
   order to improve interoperability between different IMAP clients.

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

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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.

   This Internet-Draft will expire on June 14, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the



Melnikov & Cridland       Expires June 14, 2010                 [Page 1]

Internet-Draft           IMAP4 Keyword Registry            December 2009


   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.


Table of Contents

   1.      Conventions used in this document  . . . . . . . . . . . .  3

   2.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  3

   3.      IANA Considerations  . . . . . . . . . . . . . . . . . . .  3
   3.1.    Review guidelines for the designated Expert Reviewer . . .  5
   3.2.    Comments on IMAP Keywords' Registrations . . . . . . . . .  6
   3.3.    Change Control . . . . . . . . . . . . . . . . . . . . . .  6
   3.4.    Initial registrations  . . . . . . . . . . . . . . . . . .  7
   3.4.1.  $MDNSent IMAP keyword registration . . . . . . . . . . . .  7
   3.4.2.  $Forwarded IMAP keyword registration . . . . . . . . . . .  8
   3.4.3.  $SubmitPending IMAP keyword registration . . . . . . . . .  9
   3.4.4.  $Submitted IMAP keyword registration . . . . . . . . . . . 11

   4.      Security Considerations  . . . . . . . . . . . . . . . . . 12

   5.      Acknowledgements . . . . . . . . . . . . . . . . . . . . . 12

   6.      References . . . . . . . . . . . . . . . . . . . . . . . . 12
   6.1.    Normative References . . . . . . . . . . . . . . . . . . . 12
   6.2.    Informative References . . . . . . . . . . . . . . . . . . 13

           Authors' Addresses . . . . . . . . . . . . . . . . . . . . 13













Melnikov & Cridland       Expires June 14, 2010                 [Page 2]

Internet-Draft           IMAP4 Keyword Registry            December 2009


1.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [Kwds].


2.  Introduction

   IMAP Keywords [RFC3501] are boolean named flags that can be used by
   clients to annotate messages in an IMAP mailbox.  Although IMAP
   keywords is an optional feature of IMAP, the majority of IMAP servers
   can store arbitrary keywords.  Many mainstream IMAP clients use a
   limited set of specific keywords, and some can manage (create, edit,
   display) arbitrary IMAP keywords.

   Over years some IMAP keywords have become de-facto standard, with
   some specific semantics associated with them.  In some cases
   different client implementors decided to define and use keywords with
   different names, but the same semantics.  Some server implementors
   decided to map such keywords automatically in order to improve cross
   client interoperability.

   In other cases, the same keywords have been used with different
   semantics, thus causing interoperability problems.

   This document attempts to prevent further incompatible uses of IMAP
   keywords by establishing an IMAP Keyword registry, and allocating a
   special prefix for standardized keywords.


3.  IANA Considerations

   IANA is requested to establish a new registry for IMAP keywords.

   Registration of an IMAP keyword is requested by filling in the
   following template and following the instructions on the IANA pages
   for the registry for submitting it to IANA:

   Subject:    Registration of IMAP keyword X


   IMAP keyword name:








Melnikov & Cridland       Expires June 14, 2010                 [Page 3]

Internet-Draft           IMAP4 Keyword Registry            December 2009


   Purpose (description):


   Private or Shared on a server:  (One of PRIVATE, SHARED or BOTH.
               PRIVATE means that each different user has a distinct
               copy of the keyword.  SHARED means that all different
               users see the same value of the keyword.  BOTH means that
               an IMAP server can have the keyword as either private or
               shared.)


   Is it an advisory keyword or may it cause an automatic action:


   When/by whom the keyword is set/cleared:


   Related keywords:  (for example "mutually exclusive with keywords Y
               and Z")


   Related IMAP capabilities:


   Security considerations:


   Published specification (recommended):


   Person & email address to contact for further information:


   Intended usage:  (One of COMMON, LIMITED USE or DEPRECATED (i.e. not
               recommended for use))


   Owner/Change controller:  (MUST be "IESG" for any "common use"
               keyword registration specified in an IETF Review
               document.  See definition of "common use" below in this
               section.  When the Owner/Change controller is not a
               Standardization Organization, the registration request
               MUST make it clear if the registration is controlled by a
               company, or the individual performing the registration.)







Melnikov & Cridland       Expires June 14, 2010                 [Page 4]

Internet-Draft           IMAP4 Keyword Registry            December 2009


   Note:       (Any other information that the author deems interesting
               may be added here, for example if the keyword(s) is
               supported by existing clients.)


   Registration of an IMAP keyword requires Expert Review [RFC5226].
   Registration of any IMAP keyword is initiated by posting a
   registration request to the Message Organization WG mailing list
   <morg@ietf.org> (or its replacement as chosen by the responsible
   Application Area Director) and CCing IANA (<iana@iana.org>).  After
   allowing for at least 2 weeks for community input on the designated
   mailing list, the expert will determine the appropriateness of the
   registration request and either approve or disapprove the request
   with notice to the requestor, the mailing list, and IANA.  Any
   refusal must come with a clear explanation.

   The IESG appoints one or more Expert Reviewer for the IMAP Keyword
   registry established by this document.

   Expert Reviewer should strive for timely reviews.  Expert Reviewer
   should take no longer than 6 weeks to make and announce the decision,
   or notify the mailing list that more time is required.

   Decisions (or lack of) made by an Expert Reviewer can be first
   appealed to Application Area Directors and, if the appellant is not
   satisfied with the response, to the full IESG.

   There are two types of IMAP keywords in the "IMAP Keywords" registry:
   intended for common use and vendor/organization specific (also known
   as "limited use").  An IMAP keyword is said to be for "common use" if
   it is reasonably expected to be implemented in at least 2 independent
   client implementations.  The two types of IMAP Keywords have
   different levels of requirements for registration (see below).

3.1.  Review guidelines for the designated Expert Reviewer

   Expert Reviewers should focus on the following requirements.

   Registration of a vendor/organization specific ("limited use") IMAP
   keyword is easier.  The Expert Reviewer only needs to check that the
   requested name doesn't conflict with an already registered name, and
   that the name is not too generic, misleading, etc.  The Expert
   Reviewer MAY request the IMAP Keyword name change before approving
   the registration.  The Expert Reviewer SHOULD refuse a registration
   if there is an already registered IMAP Keyword which serve the same
   purpose, but has a different name.

   When registering an IMAP Keyword for "common use", the Expert



Melnikov & Cridland       Expires June 14, 2010                 [Page 5]

Internet-Draft           IMAP4 Keyword Registry            December 2009


   Reviewer performs the checks described for vendor/organization
   specific IMAP Keywords, plus additional checks as detailed below.

   Keywords intended for common use SHOULD start with the "$" prefix.
   (Note that this is a SHOULD because some of the commonly used IMAP
   keywords in widespread use don't follow this convention.)

   IMAP keywords intended for common use SHOULD be standardized in IETF
   Review [RFC5226] documents.  (Note that IETF Review documents still
   require Expert Review.)

   Values in the "IMAP Keywords" IANA registry intended for common use
   must be clearly documented and likely to ensure interoperability.
   They must be useful, not harmful to the Internet.  In cases when an
   IMAP Keyword being registered is already deployed, Expert Reviewers
   should favour registering it over requiring perfect documentation
   and/or requesting to change the name of the IMAP Keyword.

   The Expert Reviewer MAY automatically "upgrade" registration requests
   for a "limited use" IMAP Keyword to "common use" level.  The Expert
   Reviewer MAY also request that a registration targeted for "common
   use" be registered as "limited use" instead.

3.2.  Comments on IMAP Keywords' Registrations

   Comments on registered IMAP Keywords should be sent to both the
   "owner" of the mechanism and to the mailing list designated to IMAP
   keyword review (see Section 3).  This improves chances of getting a
   timely response.

   Submitters of comments may, after a reasonable attempt to contact the
   owner and after soliciting comments on the IMAP mailing list, request
   the designated Expert Reviewer to attach their comment to the IMAP
   keyword registration itself.  The procedure is similar to requesting
   an expert review for the affected keyword.

3.3.  Change Control

   Once an IMAP keyword registration has been published by IANA, the
   owner may request a change to its definition.  The change request
   (including a change to the "intended usage" field) follows the same
   procedure as the initial registration request, with the exception of
   changes to the "Person & email address to contact for further
   information" and "Owner/Change controller" fields.  The latter can be
   changed by the owner by informing IANA; this can be done without
   discussion or review.

   The IESG may reassign responsibility for an IMAP keyword.  The most



Melnikov & Cridland       Expires June 14, 2010                 [Page 6]

Internet-Draft           IMAP4 Keyword Registry            December 2009


   common case of this will be to enable clarifications to be made to
   keywords where the owner of the registration has died, moved out of
   contact or is otherwise unable to make changes that are important to
   the community.

   IMAP keyword registrations MUST NOT be deleted; keywords which are no
   longer believed appropriate for use can be declared DEPRECATED by a
   change to their "intended usage" field.

   The IESG is considered to be the owner of all "common use" IMAP
   keywords that are published in an IETF Review document.

3.4.  Initial registrations

   IANA is requested to register IMAP Keywords specified in subsections
   of this section in the registry established in this document.

3.4.1.  $MDNSent IMAP keyword registration

   Subject:    Registration of IMAP keyword $MDNSent


   IMAP keyword name:  $MDNSent


   Purpose (description):  Specifies that a Message Disposition
               Notification (MDN) must not be sent for any message
               annotated with the $MDNSent IMAP keyword.


   Private or Shared on a server:  SHARED


   Is it an advisory keyword or may it cause an automatic action:  This
               keyword can cause automatic action by the client.  See
               [RFC3503] for more details.


   When/by whom the keyword is set/cleared:  This keyword is set by an
               IMAP client when it decides to act on a MDN request, or
               when uploading a sent or draft message.  It can also be
               set by a delivery agent.  Once set the flag SHOULD NOT be
               cleared.








Melnikov & Cridland       Expires June 14, 2010                 [Page 7]

Internet-Draft           IMAP4 Keyword Registry            December 2009


   Related keywords:  None


   Related IMAP capabilities:  None


   Security considerations:  See section 6 of [RFC3503]


   Published specification (recommended):  [RFC3503]


   Person & email address to contact for further information:  Alexey
               Melnikov <alexey.melnikov@isode.com>


   Intended usage:  COMMON


   Owner/Change controller:  IESG


   Note:


3.4.2.  $Forwarded IMAP keyword registration

   Subject:    Registration of the IMAP keyword $Forwarded


   IMAP keyword name:  $Forwarded


   Purpose (description):  $Forwarded is used by several IMAP clients to
               specify that the message was resent to another email
               address, embedded within or attached to a new message.
               This keyword is set by the mail client when it
               successfully forwards the message to another email
               address.  Typical usage of this keyword is to show a
               different (or additional) icon for a message that has
               been forwarded.


   Private or Shared on a server:  BOTH







Melnikov & Cridland       Expires June 14, 2010                 [Page 8]

Internet-Draft           IMAP4 Keyword Registry            December 2009


   Is it an advisory keyword or may it cause an automatic action:
               advisory


   When/by whom the keyword is set/cleared:  This keyword can be set
               either by a delivery agent or by a mail client.  Once set
               the flag SHOULD NOT be cleared.  Notes: There is no way
               to tell if a message with $Forwarded keyword set was
               forwarded more than once.


   Related keywords:  None


   Related IMAP capabilities:  None


   Security considerations:  A server implementing this keyword as a
               shared keyword, may disclose that a confidential message
               was forwarded.


   Published specification (recommended):  [RFC5550]


   Person & email address to contact for further information:  Alexey
               Melnikov <alexey.melnikov@isode.com>


   Intended usage:  COMMON


   Owner/Change controller:  IESG


   Note:


3.4.3.  $SubmitPending IMAP keyword registration

   Subject:    Registration of IMAP keyword $SubmitPending


   IMAP keyword name:  $SubmitPending







Melnikov & Cridland       Expires June 14, 2010                 [Page 9]

Internet-Draft           IMAP4 Keyword Registry            December 2009


   Purpose (description):  The $SubmitPending IMAP keyword designates
               the message as awaiting to be submitted.  This keyword
               allows storing messages waiting to be submitted in the
               same mailbox where messages that were already submitted
               and/or are being edited are stored.

               A message that has both $Submitted and $SubmitPending
               IMAP keywords set is a message being actively submitted.


   Private or Shared on a server:  SHARED


   Is it an advisory keyword or may it cause an automatic action:  This
               keyword can cause automatic action by the client.  See
               Section 5.10 of [RFC5550] for more details.


   When/by whom the keyword is set/cleared:  This keyword is set by a
               mail client when it decides that the message needs to be
               sent out.


   Related keywords:  $Submitted


   Related IMAP capabilities:  None


   Security considerations:  A server implementing this keyword as a
               shared keyword, may disclose that a confidential message
               is sheduled to be sent out or is being actively sent out.


   Published specification (recommended):  [RFC5550]


   Person & email address to contact for further information:  Alexey
               Melnikov <alexey.melnikov@isode.com>


   Intended usage:  COMMON


   Owner/Change controller:  IESG






Melnikov & Cridland       Expires June 14, 2010                [Page 10]

Internet-Draft           IMAP4 Keyword Registry            December 2009


   Note:


3.4.4.  $Submitted IMAP keyword registration

   Subject:    Registration of IMAP keyword $Submitted


   IMAP keyword name:  $Submitted


   Purpose (description):  The $Submitted IMAP keyword designates the
               message as being sent out.

               A message that has both $Submitted and $SubmitPending
               IMAP keywords set is a message being actively submitted.


   Private or Shared on a server:  SHARED


   Is it an advisory keyword or may it cause an automatic action:  This
               keyword can cause automatic action by the client.  See
               Section 5.10 of [RFC5550] for more details.


   When/by whom the keyword is set/cleared:  This keyword is set by a
               mail client when it decides to start sending it.


   Related keywords:  $SubmitPending


   Related IMAP capabilities:  None


   Security considerations:  A server implementing this keyword as a
               shared keyword, may disclose that a confidential message
               was sent or is being actively sent out.


   Published specification (recommended):  [RFC5550]


   Person & email address to contact for further information:  Alexey
               Melnikov <alexey.melnikov@isode.com>





Melnikov & Cridland       Expires June 14, 2010                [Page 11]

Internet-Draft           IMAP4 Keyword Registry            December 2009


   Intended usage:  COMMON


   Owner/Change controller:  IESG


   Note:



4.  Security Considerations

   IMAP Keywords are one of the base IMAP features [RFC3501].  This
   document doesn't change their behaviour, so it is not adding new
   security issues.

   A particular IMAP keyword might have specific security
   considerations, which are documented in IMAP keyword registration
   template standardized by this document.


5.  Acknowledgements

   The creation of this document was prompted by one of many discussions
   on the IMAP mailing list.

   John Neystadt co-authored the first revision of this document.

   Special thanks to Chris Newman, David Harris, Lyndon Nerenberg, Mark
   Crispin, Samuel Weiler and Alfred Hoenes for reviewing different
   versions of this document.  However all errors or omissions must be
   attributed to the authors of this document.

   The author would also like to thank the developers of Mozilla mail
   clients for providing food for thoughts.


6.  References

6.1.  Normative References

   [Kwds]     Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997.

   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
              4rev1", RFC 3501, March 2003.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an



Melnikov & Cridland       Expires June 14, 2010                [Page 12]

Internet-Draft           IMAP4 Keyword Registry            December 2009


              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

6.2.  Informative References

   [RFC3503]  Melnikov, A., "Message Disposition Notification (MDN)
              profile for Internet Message Access Protocol (IMAP)",
              RFC 3503, March 2003.

   [RFC5550]  Cridland, D., Melnikov, A., and S. Maes, "The Internet
              Email to Support Diverse Service Environments (Lemonade)
              Profile", RFC 5550, August 2009.


Authors' 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/


   Dave Cridland
   Isode Limited
   5 Castle Business Village
   36 Station Road
   Hampton, Middlesex  TW12 2BX
   UK

   Email: dave.cridland@isode.com
















Melnikov & Cridland       Expires June 14, 2010                [Page 13]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/