Internet Draft: MDN profile for IMAP                         A. Melnikov
Document: draft-melnikov-imap-keywords-00.txt            MessagingDirect
Expires: December 2002                                       J. Neystadt
Intended category: Informational                                Comverse
                                                               June 2002

                  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.

0. 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: ...
   Private or Shared on a server: private/shared/both



Melnikov                 Expires: December 2002                 [Page 1]





INTERNET DRAFT    Registration of common IMAP keywords         June 2002


   Is it an advisory keyword or may it cause an automatic action?
   When/by whom the keyword is set/cleared: ...
   >>

   <<Define mutual exclusive $Work, $Personal (and $Spam)>>

   <<Define special capabilities returned by cooperating servers?>>

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  $Important....................................................3
    3.3  $ShouldReply..................................................4
    3.4  $Spam.........................................................4
    3.5  $Adult........................................................4
   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 2002                 [Page 2]





INTERNET DRAFT    Registration of common IMAP keywords         June 2002


3.   IMAP keyword registrations

3.1 $Forwarded

   $Forwarded is used by several IMAP clients to specify that the
   message was forwarded (either inline or as an attachment) to another
   email address. This keyword is set by the mail client when it
   successfully forwards the message to another email address.


3.2 $Important

   [IMAP4] doesn't specify exact semantics of the \Flagged flag. It
   suggests that it is upto a MUA to assign any special meaning to it.
   Most intuitive meaning of \Flagged is probbably 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 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.

   <<Describe how client should display that: use described header
   fields if the $Important keyword is not set. The keyword override
   header fields.>>

   <<Added 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?>>








Melnikov                 Expires: December 2002                 [Page 3]





INTERNET DRAFT    Registration of common IMAP keywords         June 2002


3.3 $ShouldReply

   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.


3.4 $Spam

   The user may choose to mark a message as containing Spam. This
   keyword can be used to mark, group or hide offensive messages.


3.5 $Adult

   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.


4.   Security Considerations

   << 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.



Melnikov                 Expires: December 2002                 [Page 4]





INTERNET DRAFT    Registration of common IMAP keywords         June 2002


   flag_keyword    ::= "$Forwarded" / "$Important" / "$ShouldReply" /
                       "$Spam" / "$Adult" / other_keywords

   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.

   [HEADERS] Palme, J., "Common Internet Message Headers", RFC 2076,
   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
   ACI Worldwide/MessagingDirect
   Address: 22 The Quadrant, Richmond, Surrey, United Kingdom, TW9 1BP
   Phone: +44 20 8332 4508

   Email: mel@messagingdirect.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 2002                 [Page 5]





INTERNET DRAFT    Registration of common IMAP keywords         June 2002


10.  Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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.



















Melnikov                 Expires: December 2002                 [Page 6]