Network Working Group A. Melnikov
Internet-Draft D. Cridland
Intended status: Standards Track Isode Limited
Expires: May 22, 2010 November 18, 2009
IMAP4 Keyword Registry
draft-melnikov-imap-keywords-07
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 May 22, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
Melnikov & Cridland Expires May 22, 2010 [Page 1]
Internet-Draft IMAP4 Keyword Registry November 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. Comments on IMAP Keywords' Registrations . . . . . . . . . 6
3.2. Change Control . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Initial registrations . . . . . . . . . . . . . . . . . . 6
3.3.1. $MDNSent IMAP keyword registration . . . . . . . . . . . . 7
3.3.2. $Forwarded IMAP keyword registration . . . . . . . . . . . 8
3.3.3. $SubmitPending IMAP keyword registration . . . . . . . . . 9
3.3.4. $Submitted IMAP keyword registration . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . 11
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 13
Melnikov & Cridland Expires May 22, 2010 [Page 2]
Internet-Draft IMAP4 Keyword Registry November 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 May 22, 2010 [Page 3]
Internet-Draft IMAP4 Keyword Registry November 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 OBSOLETE)
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.)
Note: (Any other information that the author deems interesting
may be added here, for example if the keyword(s) is
supported by existing clients.)
There are two types of IMAP keywords in the "IMAP Keywords" registry:
Melnikov & Cridland Expires May 22, 2010 [Page 4]
Internet-Draft IMAP4 Keyword Registry November 2009
intended for common use and vendor (organization) specific. Naming
conventions and registration policy is different for two types.
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.) Vendor
specific keywords MUST start with the "vnd." prefix, which is
followed by the vendor name from the "Vendor Subtrees Registry"
[I-D.cridland-acap-vendor-registry] and another ".".
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 keyword is registered by IANA (if it is a vendor
specific IMAP keyword), or reviewed by one of Designated Experts (if
the keyword is intended for common use).
Registration of an IMAP keyword intended for common use (whether or
not they use the "$" prefix) requires Expert Review [RFC5226]. After
allowing for at least two weeks for community input on the designated
mailing list (as described above), 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, one of which is
designated as the primary Expert Reviewer. IMAP keywords intended
for common use SHOULD be standardized in IETF Review [RFC5226]
documents.
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 appealed to
the IESG.
Expert Reviewers should focus on the following requirements. 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.
Registration of vendor specific IMAP keywords is done on First Come
First Served [RFC5226] basis and doesn't require the Expert Review.
Melnikov & Cridland Expires May 22, 2010 [Page 5]
Internet-Draft IMAP4 Keyword Registry November 2009
However such review is still encouraged. Should the review be
requested by registrant or at IANA's sole discretion, the Expert
Reviewer should encourage vendors to avoid defining similar but
incompatible values and instead agree on a single IMAP keyword for
common use.
3.1. Comments on IMAP Keywords' Registrations
Comments on registered IMAP Keywords should first be sent to the
"owner" of the mechanism and then to the mailing list designated to
IMAP keyword review (see Section 3).
Submitters of comments may, after a reasonable attempt to contact the
owner and after soliciting comments on the IMAP mailing list, request
IANA to attach their comment to the IMAP keyword registration itself
by sending mail to <iana@iana.org>. At IANA sole discretion, IANA
may attach the comment to the IMAP keyword registration.
3.2. Change Control
Once an IMAP keyword registration has been published by IANA, the
author may request a change to its definition. The change request
follows the same procedure as the 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 sending 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 author 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 may not be deleted; keywords which are no
longer believed appropriate for use can be declared OBSOLETE 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.3. Initial registrations
IANA is requested to register IMAP Keywords specified in subsections
of this section in the registry established in this document.
Melnikov & Cridland Expires May 22, 2010 [Page 6]
Internet-Draft IMAP4 Keyword Registry November 2009
3.3.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.
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
Melnikov & Cridland Expires May 22, 2010 [Page 7]
Internet-Draft IMAP4 Keyword Registry November 2009
Owner/Change controller: IESG
Note:
3.3.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
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.
Melnikov & Cridland Expires May 22, 2010 [Page 8]
Internet-Draft IMAP4 Keyword Registry November 2009
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.3.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.
Melnikov & Cridland Expires May 22, 2010 [Page 9]
Internet-Draft IMAP4 Keyword Registry November 2009
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
Note:
3.3.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
Melnikov & Cridland Expires May 22, 2010 [Page 10]
Internet-Draft IMAP4 Keyword Registry November 2009
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>
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.
Melnikov & Cridland Expires May 22, 2010 [Page 11]
Internet-Draft IMAP4 Keyword Registry November 2009
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 HInes 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
[I-D.cridland-acap-vendor-registry]
Cridland, D., "The Internet Assigned Number Authority
(IANA) Application Configurations Access Protocol (ACAP)
Vendor Subtrees Registry",
draft-cridland-acap-vendor-registry-00 (work in progress),
July 2009.
[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
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.
Melnikov & Cridland Expires May 22, 2010 [Page 12]
Internet-Draft IMAP4 Keyword Registry November 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 May 22, 2010 [Page 13]
