7Internet Engineering Task Force (IETF) A. Melnikov
8Request for Comments: 5788 D. Cridland
9Category: Standards Track Isode Limited
10ISSN: 2070-1721 March 2010
13 IMAP4 Keyword Registry
17 The aim of this document is to establish a new IANA registry for IMAP
18 keywords and to define a procedure for keyword registration, in order
19 to improve interoperability between different IMAP clients.
23 This is an Internet Standards Track document.
25 This document is a product of the Internet Engineering Task Force
26 (IETF). It represents the consensus of the IETF community. It has
27 received public review and has been approved for publication by the
28 Internet Engineering Steering Group (IESG). Further information on
29 Internet Standards is available in Section 2 of RFC 5741.
31 Information about the current status of this document, any errata,
32 and how to provide feedback on it may be obtained at
33 http://www.rfc-editor.org/info/rfc5788.
37 Copyright (c) 2010 IETF Trust and the persons identified as the
38 document authors. All rights reserved.
40 This document is subject to BCP 78 and the IETF Trust's Legal
41 Provisions Relating to IETF Documents
42 (http://trustee.ietf.org/license-info) in effect on the date of
43 publication of this document. Please review these documents
44 carefully, as they describe your rights and restrictions with respect
45 to this document. Code Components extracted from this document must
46 include Simplified BSD License text as described in Section 4.e of
47 the Trust Legal Provisions and are provided without warranty as
48 described in the Simplified BSD License.
58Melnikov & Cridland Standards Track [Page 1]
60RFC 5788 IMAP4 Keyword Registry March 2010
65 1. Introduction ....................................................2
66 2. Conventions Used in This Document ...............................2
67 3. IANA Considerations .............................................3
68 3.1. Review Guidelines for the Designated Expert Reviewer .......4
69 3.2. Comments on IMAP Keywords' Registrations ...................5
70 3.3. Change Control .............................................5
71 3.4. Initial Registrations ......................................6
72 3.4.1. $MDNSent IMAP Keyword Registration ..................6
73 3.4.2. $Forwarded IMAP Keyword Registration ................7
74 3.4.3. $SubmitPending IMAP Keyword Registration ............8
75 3.4.4. $Submitted IMAP Keyword Registration ................9
76 4. Security Considerations ........................................10
77 5. Acknowledgements ...............................................10
78 6. References .....................................................10
79 6.1. Normative References ......................................10
80 6.2. Informative References ....................................11
84 IMAP keywords [RFC3501] are boolean named flags that can be used by
85 clients to annotate messages in an IMAP mailbox. Although IMAP
86 keywords are an optional feature of IMAP, the majority of IMAP
87 servers can store arbitrary keywords. Many mainstream IMAP clients
88 use a limited set of specific keywords, and some can manage (create,
89 edit, display) arbitrary IMAP keywords.
91 Over the years, some IMAP keywords have become de-facto standards,
92 with some specific semantics associated with them. In some cases,
93 different client implementors decided to define and use keywords with
94 different names, but the same semantics. Some server implementors
95 decided to map such keywords automatically in order to improve cross-
96 client interoperability.
98 In other cases, the same keywords have been used with different
99 semantics, thus causing interoperability problems.
101 This document attempts to prevent further incompatible uses of IMAP
102 keywords by establishing an "IMAP Keywords" registry and allocating a
103 special prefix for standardized keywords.
1052. Conventions Used in This Document
107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
109 document are to be interpreted as described in RFC 2119 [Kwds].
114Melnikov & Cridland Standards Track [Page 2]
116RFC 5788 IMAP4 Keyword Registry March 2010
1193. IANA Considerations
121 IANA has established a new registry for IMAP keywords.
123 Registration of an IMAP keyword is requested by filling in the
124 following template and following the instructions on the IANA pages
125 for the registry to submit it to IANA:
127 Subject: Registration of IMAP keyword X
131 Purpose (description):
133 Private or Shared on a server: (One of PRIVATE, SHARED, or BOTH.
134 PRIVATE means that each different
135 user has a distinct copy of the
136 keyword. SHARED means that all
137 different users see the same value of
138 the keyword. BOTH means that an IMAP
139 server can have the keyword as either
142 Is it an advisory keyword or may it cause an automatic action:
144 When/by whom the keyword is set/cleared:
146 Related keywords: (for example, "mutually exclusive with keywords Y
149 Related IMAP capabilities:
151 Security considerations:
153 Published specification (recommended):
155 Person & email address to contact for further information:
157 Intended usage: (One of COMMON, LIMITED USE, or DEPRECATED (i.e.,
158 not recommended for use))
160 Owner/Change controller: (MUST be "IESG" for any "common use"
161 keyword registration specified in an IETF
162 Review document. See definition of "common
163 use" below in this section. When the
164 Owner/Change controller is not a
165 Standardization Organization, the
166 registration request MUST make it clear if
170Melnikov & Cridland Standards Track [Page 3]
172RFC 5788 IMAP4 Keyword Registry March 2010
175 the registration is controlled by a
176 company, or the individual performing the
179 Note: (Any other information that the author deems interesting
180 may be added here, for example, if the keyword(s) is
181 supported by existing clients.)
183 Registration of an IMAP keyword requires Expert Review [RFC5226].
184 Registration of any IMAP keyword is initiated by posting a
185 registration request to the Message Organization WG mailing list
186 <morg@ietf.org> (or its replacement as chosen by the responsible
187 Application Area Director) and CCing IANA (<iana@iana.org>). After
188 allowing for at least two weeks for community input on the designated
189 mailing list, the expert will determine the appropriateness of the
190 registration request and either approve or disapprove the request
191 with notice to the requestor, the mailing list, and IANA. Any
192 refusal must come with a clear explanation.
194 The IESG appoints one or more Expert Reviewers for the IMAP keyword
195 registry established by this document.
197 The Expert Reviewer should strive for timely reviews. The Expert
198 Reviewer should take no longer than six weeks to make and announce
199 the decision, or notify the mailing list that more time is required.
201 Decisions (or lack of) made by an Expert Reviewer can be first
202 appealed to Application Area Directors and, if the appellant is not
203 satisfied with the response, to the full IESG.
205 There are two types of IMAP keywords in the "IMAP Keywords" registry:
206 intended for "common use" and vendor-/organization-specific use (also
207 known as "limited use"). An IMAP keyword is said to be for "common
208 use" if it is reasonably expected to be implemented in at least two
209 independent client implementations. The two types of IMAP keywords
210 have different levels of requirements for registration (see below).
2123.1. Review Guidelines for the Designated Expert Reviewer
214 Expert Reviewers should focus on the following requirements.
216 Registration of a vendor-/organization-specific ("limited use") IMAP
217 keyword is easier. The Expert Reviewer only needs to check that the
218 requested name doesn't conflict with an already registered name, and
219 that the name is not too generic, misleading, etc. The Expert
220 Reviewer MAY request the IMAP keyword name change before approving
226Melnikov & Cridland Standards Track [Page 4]
228RFC 5788 IMAP4 Keyword Registry March 2010
231 the registration. The Expert Reviewer SHOULD refuse a registration
232 if there is an already registered IMAP keyword that serves the same
233 purpose, but has a different name.
235 When registering an IMAP keyword for "common use", the Expert
236 Reviewer performs the checks described for vendor-/
237 organization-specific IMAP keywords, plus additional checks as
240 Keywords intended for "common use" SHOULD start with the "$" prefix.
241 (Note that this is a SHOULD because some of the commonly used IMAP
242 keywords in widespread use don't follow this convention.)
244 IMAP keywords intended for "common use" SHOULD be standardized in
245 IETF Review [RFC5226] documents. (Note that IETF Review documents
246 still require Expert Review.)
248 Values in the "IMAP Keywords" IANA registry intended for "common use"
249 must be clearly documented and likely to ensure interoperability.
250 They must be useful, not harmful to the Internet. In cases when an
251 IMAP keyword being registered is already deployed, Expert Reviewers
252 should favor registering it over requiring perfect documentation
253 and/or requesting a change to the name of the IMAP keyword.
255 The Expert Reviewer MAY automatically "upgrade" registration requests
256 for a "limited use" IMAP keyword to "common use" level. The Expert
257 Reviewer MAY also request that a registration targeted for "common
258 use" be registered as "limited use" instead.
2603.2. Comments on IMAP Keywords' Registrations
262 Comments on registered IMAP keywords should be sent to both the
263 "owner" of the mechanism and to the mailing list designated to IMAP
264 keyword review (see Section 3). This improves the chances of getting
267 Submitters of comments may, after a reasonable attempt to contact the
268 owner and after soliciting comments on the IMAP mailing list, request
269 the designated Expert Reviewer to attach their comment to the IMAP
270 keyword registration itself. The procedure is similar to requesting
271 an Expert Review for the affected keyword.
275 Once an IMAP keyword registration has been published by IANA, the
276 owner may request a change to its definition. The change request
277 (including a change to the "intended usage" field) follows the same
278 procedure as the initial registration request, with the exception of
282Melnikov & Cridland Standards Track [Page 5]
284RFC 5788 IMAP4 Keyword Registry March 2010
287 changes to the "Person & email address to contact for further
288 information" and "Owner/Change controller" fields. The latter can be
289 changed by the owner by informing IANA; this can be done without
290 discussion or review.
292 The IESG may reassign responsibility for an IMAP keyword. The most
293 common case of this will be to enable clarifications to be made to
294 keywords where the owner of the registration has died, moved out of
295 contact, or is otherwise unable to make changes that are important to
298 IMAP keyword registrations MUST NOT be deleted; keywords that are no
299 longer believed appropriate for use can be declared DEPRECATED by a
300 change to their "intended usage" field.
302 The IESG is considered the owner of all "common use" IMAP keywords
303 that are published in an IETF Review document.
3053.4. Initial Registrations
307 IANA has registered the IMAP keywords specified in following
308 subsections in the registry established by this document.
3103.4.1. $MDNSent IMAP Keyword Registration
312 Subject: Registration of IMAP keyword $MDNSent
315 IMAP keyword name: $MDNSent
317 Purpose (description): Specifies that a Message Disposition
318 Notification (MDN) must not be sent for any
319 message annotated with the $MDNSent IMAP
322 Private or Shared on a server: SHARED
324 Is it an advisory keyword or may it cause an automatic action:
325 This keyword can cause automatic action by
326 the client. See [RFC3503] for more details.
328 When/by whom the keyword is set/cleared:
329 This keyword is set by an IMAP client when it
330 decides to act on an MDN request, or when
331 uploading a sent or draft message. It can
332 also be set by a delivery agent. Once set,
333 the flag SHOULD NOT be cleared.
338Melnikov & Cridland Standards Track [Page 6]
340RFC 5788 IMAP4 Keyword Registry March 2010
343 Related keywords: None
345 Related IMAP capabilities: None
347 Security considerations: See Section 6 of [RFC3503]
349 Published specification (recommended): [RFC3503]
351 Person & email address to contact for further information:
352 Alexey Melnikov <alexey.melnikov@isode.com>
354 Intended usage: COMMON
356 Owner/Change controller: IESG
3603.4.2. $Forwarded IMAP Keyword Registration
362 Subject: Registration of the IMAP keyword $Forwarded
364 IMAP keyword name: $Forwarded
366 Purpose (description): $Forwarded is used by several IMAP clients to
367 specify that the message was resent to
368 another email address, embedded within or
369 attached to a new message. This keyword is
370 set by the mail client when it successfully
371 forwards the message to another email
372 address. Typical usage of this keyword is to
373 show a different (or additional) icon for a
374 message that has been forwarded.
376 Private or Shared on a server: BOTH
378 Is it an advisory keyword or may it cause an automatic action:
381 When/by whom the keyword is set/cleared:
382 This keyword can be set by either a delivery
383 agent or a mail client. Once set, the flag
384 SHOULD NOT be cleared. Notes: There is no
385 way to tell if a message with $Forwarded
386 keyword set was forwarded more than once.
388 Related keywords: None
390 Related IMAP capabilities: None
394Melnikov & Cridland Standards Track [Page 7]
396RFC 5788 IMAP4 Keyword Registry March 2010
399 Security considerations: A server implementing this keyword as a
400 shared keyword may disclose that a
401 confidential message was forwarded.
403 Published specification (recommended): [RFC5550]
405 Person & email address to contact for further information:
406 Alexey Melnikov <alexey.melnikov@isode.com>
408 Intended usage: COMMON
410 Owner/Change controller: IESG
4143.4.3. $SubmitPending IMAP Keyword Registration
416 Subject: Registration of IMAP keyword $SubmitPending
418 IMAP keyword name: $SubmitPending
420 Purpose (description): The $SubmitPending IMAP keyword designates
421 the message as awaiting to be submitted.
422 This keyword allows storing messages waiting
423 to be submitted in the same mailbox where
424 messages that were already submitted and/or
425 are being edited are stored.
427 A message that has both $Submitted and
428 $SubmitPending IMAP keywords set is a message
429 being actively submitted.
431 Private or Shared on a server: SHARED
433 Is it an advisory keyword or may it cause an automatic action:
434 This keyword can cause automatic action by
435 the client. See Section 5.10 of [RFC5550]
438 When/by whom the keyword is set/cleared:
439 This keyword is set by a mail client when it
440 decides that the message needs to be sent
443 Related keywords: $Submitted
445 Related IMAP capabilities: None
450Melnikov & Cridland Standards Track [Page 8]
452RFC 5788 IMAP4 Keyword Registry March 2010
455 Security considerations: A server implementing this keyword as a
456 shared keyword may disclose that a
457 confidential message is scheduled to be
458 sent out or is being actively sent out.
460 Published specification (recommended): [RFC5550]
462 Person & email address to contact for further information:
463 Alexey Melnikov <alexey.melnikov@isode.com>
465 Intended usage: COMMON
467 Owner/Change controller: IESG
4713.4.4. $Submitted IMAP Keyword Registration
473 Subject: Registration of IMAP keyword $Submitted
475 IMAP keyword name: $Submitted
477 Purpose (description): The $Submitted IMAP keyword designates the
478 message as being sent out.
480 A message that has both $Submitted and
481 $SubmitPending IMAP keywords set is a message
482 being actively submitted.
484 Private or Shared on a server: SHARED
486 Is it an advisory keyword or may it cause an automatic action:
487 This keyword can cause automatic action by
488 the client. See Section 5.10 of [RFC5550]
491 When/by whom the keyword is set/cleared:
492 This keyword is set by a mail client when it
493 decides to start sending it.
495 Related keywords: $SubmitPending
497 Related IMAP capabilities: None
499 Security considerations: A server implementing this keyword as a
500 shared keyword may disclose that a
501 confidential message was sent or is being
506Melnikov & Cridland Standards Track [Page 9]
508RFC 5788 IMAP4 Keyword Registry March 2010
511 Published specification (recommended): [RFC5550]
513 Person & email address to contact for further information:
514 Alexey Melnikov <alexey.melnikov@isode.com>
516 Intended usage: COMMON
518 Owner/Change controller: IESG
5224. Security Considerations
524 IMAP keywords are one of the base IMAP features [RFC3501]. This
525 document doesn't change their behavior, so it does not add new
528 A particular IMAP keyword might have specific security
529 considerations, which are documented in the IMAP keyword
530 registration template standardized by this document.
534 The creation of this document was prompted by one of many discussions
535 on the IMAP mailing list.
537 John Neystadt co-authored the first version of this document.
539 Special thanks to Chris Newman, David Harris, Lyndon Nerenberg, Mark
540 Crispin, Samuel Weiler, Alfred Hoenes, Lars Eggert, and Cullen
541 Jennings for reviewing different versions of this document. However,
542 all errors or omissions must be attributed to the authors of this
545 The authors would also like to thank the developers of Mozilla mail
546 clients for providing food for thought.
5506.1. Normative References
552 [Kwds] Bradner, S., "Key words for use in RFCs to Indicate
553 Requirement Levels", BCP 14, RFC 2119, March 1997.
555 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
556 4rev1", RFC 3501, March 2003.
562Melnikov & Cridland Standards Track [Page 10]
564RFC 5788 IMAP4 Keyword Registry March 2010
567 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
568 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
5716.2. Informative References
573 [RFC3503] Melnikov, A., "Message Disposition Notification (MDN)
574 profile for Internet Message Access Protocol (IMAP)",
575 RFC 3503, March 2003.
577 [RFC5550] Cridland, D., Melnikov, A., and S. Maes, "The Internet
578 Email to Support Diverse Service Environments (Lemonade)
579 Profile", RFC 5550, August 2009.
585 5 Castle Business Village
587 Hampton, Middlesex TW12 2BX
590 EMail: Alexey.Melnikov@isode.com
591 URI: http://www.melnikov.ca/
596 5 Castle Business Village
598 Hampton, Middlesex TW12 2BX
601 EMail: dave.cridland@isode.com
618Melnikov & Cridland Standards Track [Page 11]