summaryrefslogtreecommitdiff
path: root/imap/docs/rfc/rfc5788.txt
diff options
context:
space:
mode:
Diffstat (limited to 'imap/docs/rfc/rfc5788.txt')
-rw-r--r--imap/docs/rfc/rfc5788.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/imap/docs/rfc/rfc5788.txt b/imap/docs/rfc/rfc5788.txt
new file mode 100644
index 00000000..fe0de709
--- /dev/null
+++ b/imap/docs/rfc/rfc5788.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+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]
+
generated by cgit v1.2.3-54-g00ecf (git 2.44.0) at 2024-07-10 23:09:16 +0000