Internet Draft: Common IMAP keywords A. Melnikov
Document: draft-melnikov-imap-keywords-01.txt Isode
Expires: December 2003 J. Neystadt
Intended category: Informational Comverse
June 2003
Registration of common IMAP keywords
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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.
A revised version of this draft document will be submitted to the RFC
editor as an Informational document. Discussion and suggestions for
improvement are requested, and should be sent to the IMAP4 Mailing
list (imap@CAC.Washington.EDU). To subscribe to the list, send email
to <listproc@u.washington.edu> with the text "subscribe imap
YourName" in the body of the message. Distribution of this memo is
unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Table of Contents
0. To do ....................................................... 1
1. Abstract .................................................... 2
2. Conventions Used in this Document ........................... 2
3. IMAP keyword registrations .................................. 3
3.1 $Forwarded .................................................. 3
3.2 $Spam ....................................................... X
3.3 $Work ....................................................... X
Melnikov Expires: December 2003 [Page 1]
INTERNET DRAFT Registration of common IMAP keywords June 2003
3.4 $Personal ................................................... X
3.5 $Adult ...................................................... X
3.6 $ShouldReply ................................................ X
3.7 $Important .................................................. X
4. Security Considerations ..................................... 4
5. Other considerations ........................................ 4
6. Formal Syntax ............................................... 4
7. Acknowledgments ............................................. 5
8. References .................................................. 5
9. Author's Addresses .......................................... 5
10. Full Copyright Statement .................................... 6
1. Abstract
The aim of this document is to document some common [IMAP4] keywords
for the purpose of improving interoperability between different IMAP
mail clients. The document both documents some keywords already in
use, as well as introduces several new ones.
2. Conventions Used in this Document
"C:" and "S:" in examples show lines sent by the client and server
respectively.
The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in
this document when typed in uppercase are to be interpreted as
defined in "Key words for use in RFCs to Indicate Requirement Levels"
[KEYWORDS].
Melnikov Expires: December 2003 [Page 2]
INTERNET DRAFT Registration of common IMAP keywords June 2003
3. IMAP keyword registrations
3.1 $Forwarded
Purpose: $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.
Private or Shared on a server: either
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 a mail client. Once set the flag SHOULD
NOT be cleared.
Notes: There is no way to tell if the message with $Forwarded flags
was forwarded more than once.
Corresponding ANNOTATE attribute: "/message/flags/$forwarded"
(default mapping as described in ANNOTATE)
Additional IMAP capabilities: none.
Security Considerations: A server implementing this keyword as a
shared keyword, may disclose that a confidential message was
forwarded.
3.2 $Spam
Purpose: The user (or a delivery agent on behalf of the user) may
choose to mark a message as containing Spam. This keyword can be used
to mark, group or hide offensive messages.
Private or Shared on a server: private
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 a mail client on users behalf. The user
must be able to set and unset this keyword. If the mail client hides
all messages with this flag from the current view, the mail client
MUST implement a mode when it is possible to see all messages marked
as $Spam.
Melnikov Expires: December 2003 [Page 3]
INTERNET DRAFT Registration of common IMAP keywords June 2003
Notes: There are existing clients that use mutually exclusive
keywords Junk and NoJunk to mark a message as definitely
containing/definitely non containing spam.
This keyword is mutually exclusive with $Work and $Personal. If more
than one of the $Spam, $Work or $Personal keywords is set for a
message, the mail client MUST treat this as if none of them is set.
Corresponding ANNOTATE attribute: "/message/flags/$spam"
(default mapping as described in ANNOTATE)
Additional IMAP capabilities: ?.
Security Considerations: A message marked with $Spam keyword by one
user might not be considered spam by another (or even by the same
user under different circumstances), so no automatic action can be
initiated when this flag is set.
<<Should we use Junk/NoJunk for historical reasons? If not, should we
add $NoSpam?>>
3.3 $Work
Purpose: The user (or a delivery agent on behalf of the user) may
choose to mark a message as related to work.
Private or Shared on a server: private
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 a mail client on users behalf. The user
must be able to set and unset this keyword.
Notes: This keyword is mutually exclusive with $Spam and $Personal.
If more than one of the $Spam, $Work or $Personal keywords is set for
a message, the mail client MUST treat this as if none of them is set.
Corresponding ANNOTATE attribute: "/message/flags/$work"
(default mapping as described in ANNOTATE)
Additional IMAP capabilities: ?.
Security Considerations: <<same as $Spam>>.
3.4 $Personal
Melnikov Expires: December 2003 [Page 4]
INTERNET DRAFT Registration of common IMAP keywords June 2003
Purpose: The user (or a delivery agent on behalf of the user) may
choose to mark a message as personal.
Private or Shared on a server: private
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 a mail client on users behalf. The user
must be able to set and unset this keyword.
Notes: This keyword is mutually exclusive with $Spam and $Work. If
more than one of the $Spam, $Work or $Personal keywords is set for a
message, the mail client MUST treat this as if none of them are set.
Corresponding ANNOTATE attribute: "/message/flags/$personal"
(default mapping as described in ANNOTATE)
Additional IMAP capabilities: ?.
Security Considerations: <<same as $Spam>>.
3.5 $Adult
Purpose: The user may choose to mark a message as being inappropriate
for minors. A mail client equipped with parental control
functionality MUST use this keyword to prevent the message from being
displayed to a minor user. If recognized by the server, this keyword
SHOULD be implemented as a shared keyword.
Private or Shared on a server: shared(?)
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 a mail client on users behalf. The user
must be able to set and unset this keyword. If the mail client hides
all messages with this flag from the current view, the mail client
MUST implement a mode when it is possible to see all messages marked
as $Adult.
Notes: none.
Corresponding ANNOTATE attribute: "/message/flags/$adult"
(default mapping as described in ANNOTATE)
Melnikov Expires: December 2003 [Page 5]
INTERNET DRAFT Registration of common IMAP keywords June 2003
Additional IMAP capabilities: none.
Security Considerations: A message marked with $Adult keyword by one
user might not be considered inappropriate for minors by another, so
no automatic action can be initiated when this flag is set.
<<Should we define $AdultPG, $Adult15, $Adult18, etc.?>>
3.6 $ShouldReply
Purpose: The user may mark a message with this keyword to specify
that the message requires a reply. One possible use of this keyword
is to group in some way all messages having this keyword. Another
possible use would be to periodically pop up a dialog requesting the
user to send a reply. When a reply to this message is sent, the mail
client MUST remove this keyword and MUST set the \Answered flag.
Private or Shared on a server: private
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 a mail client on users behalf (for
example, "should reply to all messages from boss with particular
subject"). The user must be able to set and unset this keyword.
Notes: <<popping up a dialog asking for reply each time the client
sees this flag might be a bad UI idea>>.
Corresponding ANNOTATE attribute: "/message/flags/$shouldreply"
(default mapping as described in ANNOTATE)
Additional IMAP capabilities: none.
Security Considerations: ...
3.7 $Important
Purpose: <<[IMAP4] doesn't specify exact semantics of the \Flagged
flag. It suggests that it is up to a MUA to assign any special
meaning to it. Most intuitive meaning of \Flagged is probably to mark
that message as important. However since the same user can use
multiple MUAs from different vendors, there are some MUAs that use it
for different purposes. In order to introduce a consistent
"Important" mark a new flag is required. This document defines a new
Melnikov Expires: December 2003 [Page 6]
INTERNET DRAFT Registration of common IMAP keywords June 2003
keyword $Important for this purpose.>>
The server that recognizes $Important SHOULD automatically set it on
a message injection if the root bodypart of that message contains the
header field "Importance" with the value "High". The server SHOULD
also set this keyword if the root body part contains either a header
field "Priority" with the value of "urgent" [HEADERS] or a header
field "X-Priority" with the value "1" or "2".
Note that a header field value comparison MUST be done after removing
RFC 822 comments (see section 3.2.3 of [RFC 2822]). For example, the
"X-Priority" header field with the value "1 (Highest)" and "1" MUST
be treated the same way.
Private or Shared on a server: private
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 a mail client on users behalf as
described above. The user must be able to set and unset this
keyword.
<<The absence of this keyword means use the algorithm above?>>
Notes: ...
<<Describe how client should display that: use described header
fields if the $Important keyword is not set. The keyword overrides
header fields.>>
<<Add mutual exclusive $Important/$Normal/$Unimportant, so that we
can override the meaning prescribed by headers?>>
<<Separate Importance from Priority? I don't see much difference,
except for Priority controlling delivery speed, that most MTAs
probably ignore anyway. Define separate flags?>>
Corresponding ANNOTATE attribute: ...
Additional IMAP capabilities: ?.
Security Considerations: ...
4. Security Considerations
Melnikov Expires: December 2003 [Page 7]
INTERNET DRAFT Registration of common IMAP keywords June 2003
<< Danger of an automatic initiation of an action based on $Spam or
$Adult keywords >>
5. Other considerations
<< ANNOTATE extension is supposed to replace this. Describe how to
map the keywords defined in this document to ANNOTATE attributes. >>
6. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].
Non-terminals referenced but not defined below are as defined by
[IMAP4].
Except as noted otherwise, all alphabetic characters are case-
insensitive. The use of upper or lower case characters to define
token strings is for editorial clarity only. Implementations MUST
accept these strings in a case-insensitive fashion.
flag_keyword ::= spe_keywords / other_keywords
spe_keywords ::= "$" ( "Forwarded" / "Important" / "ShouldReply" /
"Spam" / "Work" / "Personal" / "Adult" )
other_keywords ::= atom
7. Acknowledgments
The creation of this document was prompted by one of many discussions
on the IMAP mailing list.
8. References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, University of Washington, December 1996.
[RFC 2822] Resnick, P., "Internet Message Format", RFC 2822, QUALCOMM
Incorporated, April 2001.
[] Palme, J., "Common Internet Message Headers", RFC 2076,
Melnikov Expires: December 2003 [Page 8]
INTERNET DRAFT Registration of common IMAP keywords June 2003
Stockholm University/KTH, February 1997.
[ANNOTATION] Gellens, R., Daboo, C., "IMAP ANNOTATE Extension", work
in progress, <http://www.ietf.org/internet-drafts/draft-ietf-imapext-
annotate-xx.txt>
9. Author's Addresses
Alexey Melnikov
Isode Limited
Address: 28 Gloucester Road, Teddington, Middlesex, United Kingdom, TW11 0NU
Phone: +44 77 53759732
Email: mel@isode.com
John Neystadt
Comverse Technology
Address: Habarzel 29, Ramat Hahayal, Tel-Aviv, Israel, 69710
Phone: +972-3-645-4185
Email: john@comverse.com
Melnikov Expires: December 2003 [Page 9]
INTERNET DRAFT Registration of common IMAP keywords June 2003
10. Full Copyright Statement
Copyright (C) The Internet Society (2002-2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Appendix A. To do list and open issues
Open issues are enclosed in << and >> through out this document.
This document is still very raw. Comments are encouraged.
<< Define a regular template?:
Purpose (description): ...
Private or Shared on a server: private/shared/both
Is it an advisory keyword or may it cause an automatic action?
When/by whom the keyword is set/cleared: ...
Notes: (e.g. - limitations, mutually exclusive with ...)
How the flag should be mapped to ANNOTATE (especially for mutually
exclusive flags)
Additional IMAP capability strings if the server is required to do
Melnikov Expires: December 2003 [Page 10]
INTERNET DRAFT Registration of common IMAP keywords June 2003
special processing ...
Security Considerations: ...
>>
<<Define special capabilities returned by cooperating servers?>>
<<Register "$" prefix for user defined keywords with special
semantics?>>
<<Add mutually exclusive $Important/$Unimportant/$NormalImportance?>>
<<Add comment about Mozilla $LabelN keywords?>>
<<Mozilla uses the following labels:
Important/Work/Personal/ToDo/Later. Labels in Mozilla are mutually
exclusive (i.e. at least one or none). I personally disagree that
Important is mutually exclusive with either Work or Personal. Same
about ToDo. Not sure what is Later>>
<<Replace $ShouldReply with a more generic $ToDo?>>
Melnikov Expires: December 2003 [Page 11]
