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
AbstractThe 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.
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 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. RFC 2119 [Kwds].
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 <firstname.lastname@example.org> (or its replacement as chosen by the responsible Application Area Director) and CCing IANA (<email@example.com>). 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).
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. 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.
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. 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.
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 <firstname.lastname@example.org> Intended usage: COMMON Owner/Change controller: IESG Note:
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 <email@example.com> Intended usage: COMMON Owner/Change controller: IESG Note: 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 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 <firstname.lastname@example.org> Intended usage: COMMON Owner/Change controller: IESG Note: 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 <email@example.com> Intended usage: COMMON Owner/Change controller: IESG Note: 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. [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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [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. http://www.melnikov.ca/ Dave Cridland Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK EMail: firstname.lastname@example.org