GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5788

Internet Engineering Task Force (IETF) A. Melnikov Request for Comments: 5788 D. Cridland Category: Standards Track Isode Limited ISSN: 2070-1721 March 2010

                       IMAP4 Keyword Registry

Abstract

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

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc5788.

Copyright Notice

 Copyright (c) 2010 IETF Trust and the persons identified as the
 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 Simplified BSD License.

Melnikov & Cridland Standards Track [Page 1] RFC 5788 IMAP4 Keyword Registry March 2010

Table of Contents

 1. Introduction ....................................................2
 2. Conventions Used in This Document ...............................2
 3. IANA Considerations .............................................3
    3.1. Review Guidelines for the Designated Expert Reviewer .......4
    3.2. Comments on IMAP Keywords' Registrations ...................5
    3.3. Change Control .............................................5
    3.4. Initial Registrations ......................................6
         3.4.1. $MDNSent IMAP Keyword Registration ..................6
         3.4.2. $Forwarded IMAP Keyword Registration ................7
         3.4.3. $SubmitPending IMAP Keyword Registration ............8
         3.4.4. $Submitted IMAP Keyword Registration ................9
 4. Security Considerations ........................................10
 5. Acknowledgements ...............................................10
 6. References .....................................................10
    6.1. Normative References ......................................10
    6.2. Informative References ....................................11

1. Introduction

 IMAP keywords [RFC3501] are boolean named flags that can be used by
 clients to annotate messages in an IMAP mailbox.  Although IMAP
 keywords are 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 the years, some IMAP keywords have become de-facto standards,
 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 Keywords" registry and allocating a
 special prefix for standardized keywords.

2. 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].

Melnikov & Cridland Standards Track [Page 2] RFC 5788 IMAP4 Keyword Registry March 2010

3. IANA Considerations

 IANA has established 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 to submit it to IANA:
 Subject:    Registration of IMAP keyword X
 IMAP keyword name:
 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

Melnikov & Cridland Standards Track [Page 3] RFC 5788 IMAP4 Keyword Registry March 2010

                           the registration is controlled by a
                           company, or the individual performing the
                           registration.)
 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 two 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 Reviewers for the IMAP keyword
 registry established by this document.
 The Expert Reviewer should strive for timely reviews.  The Expert
 Reviewer should take no longer than six 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 use (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 two
 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

Melnikov & Cridland Standards Track [Page 4] RFC 5788 IMAP4 Keyword Registry March 2010

 the registration.  The Expert Reviewer SHOULD refuse a registration
 if there is an already registered IMAP keyword that serves the same
 purpose, but has a different name.
 When registering an IMAP keyword for "common use", the Expert
 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 favor registering it over requiring perfect documentation
 and/or requesting a change to 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 the 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

Melnikov & Cridland Standards Track [Page 5] RFC 5788 IMAP4 Keyword Registry March 2010

 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
 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 that are no
 longer believed appropriate for use can be declared DEPRECATED by a
 change to their "intended usage" field.
 The IESG is considered the owner of all "common use" IMAP keywords
 that are published in an IETF Review document.

3.4. Initial Registrations

 IANA has registered the IMAP keywords specified in following
 subsections in the registry established by 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 an 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 Standards Track [Page 6] RFC 5788 IMAP4 Keyword Registry March 2010

 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
 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 by either a delivery
                         agent or 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

Melnikov & Cridland Standards Track [Page 7] RFC 5788 IMAP4 Keyword Registry March 2010

 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
 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

Melnikov & Cridland Standards Track [Page 8] RFC 5788 IMAP4 Keyword Registry March 2010

 Security considerations:  A server implementing this keyword as a
                           shared keyword may disclose that a
                           confidential message is scheduled 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
 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.

Melnikov & Cridland Standards Track [Page 9] RFC 5788 IMAP4 Keyword Registry March 2010

 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:

4. Security Considerations

  IMAP keywords are one of the base IMAP features [RFC3501].  This
  document doesn't change their behavior, so it does not add new
  security issues.
  A particular IMAP keyword might have specific security
  considerations, which are documented in the 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 version of this document.
 Special thanks to Chris Newman, David Harris, Lyndon Nerenberg, Mark
 Crispin, Samuel Weiler, Alfred Hoenes, Lars Eggert, and Cullen
 Jennings for reviewing different versions of this document.  However,
 all errors or omissions must be attributed to the authors of this
 document.
 The authors would also like to thank the developers of Mozilla mail
 clients for providing food for thought.

6. References

6.1. Normative References

 [Kwds]     Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
            4rev1", RFC 3501, March 2003.

Melnikov & Cridland Standards Track [Page 10] RFC 5788 IMAP4 Keyword Registry March 2010

 [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            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 Standards Track [Page 11]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5788.txt · Last modified: 2010/03/04 15:43 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki