[MORG] IMAP Keyword IANA registration request for $Junk and $NotJunk

Alexey Melnikov <alexey.melnikov@isode.com> Wed, 25 August 2010 09:36 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: morg@core3.amsl.com
Delivered-To: morg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 099923A685E for <morg@core3.amsl.com>; Wed, 25 Aug 2010 02:36:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.586
X-Spam-Level:
X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQnW-X88Gcom for <morg@core3.amsl.com>; Wed, 25 Aug 2010 02:36:36 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 777063A6957 for <morg@ietf.org>; Wed, 25 Aug 2010 02:36:33 -0700 (PDT)
Received: from [172.16.2.144] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <THTkMABIEEZ9@rufus.isode.com>; Wed, 25 Aug 2010 10:36:51 +0100
Message-ID: <4C74E427.1060001@isode.com>
Date: Wed, 25 Aug 2010 10:36:39 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: morg@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: iana@iana.org
Subject: [MORG] IMAP Keyword IANA registration request for $Junk and $NotJunk
X-BeenThere: morg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Messaging Organization <morg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/morg>, <mailto:morg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/morg>
List-Post: <mailto:morg@ietf.org>
List-Help: <mailto:morg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/morg>, <mailto:morg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Aug 2010 09:36:38 -0000

I would like to request registration of $Junk/$NotJunk IMAP keywords in 
the IANA IMAP Keyword registry established by RFC 5788.
The two registrations are described below:

-------------------------------------------------------
   Subject:    Registration of IMAP keyword $Junk


   IMAP keyword name:  $Junk

   Purpose (description):
       The user (or a delivery agent on behalf of the user)
       may choose to mark a message as definitely
       containing junk ($Junk; see also the related keyword
       $NotJunk). The $Junk keyword
       can be used to mark (and potentially move/delete
       messages later), group or hide undesirable messages.

   Private or Shared on a server:  BOTH (see Note 3)

   Is it an advisory keyword or may it cause an automatic action:
       This keyword is advisory.

   When/by whom the keyword is set/cleared:
       $Junk can be set either by a delivery agent or a mail client
       on users behalf. The user must be able to set or clear $Junk
       at any time.
       If the mail client hides all messages with $Junk keyword
       from the current view, the mail client MUST implement a mode
       when it is possible to see all messages marked as $Junk.

   Related keywords: $NotJunk

   Related IMAP capabilities:  None

   Security considerations:
       A message marked the with $Junk keyword by one
       user might not be considered junk by another (or even by the same 
user
       under different circumstances).  Any automated action taken by 
the mail
       system or by the MUA in response to this keyword needs to take 
that into
       account.  Destructive action (such as expunging a message as soon as
       the $Junk keyword is applied) can cause loss of desired messages, and
       mail systems and MUAs SHOULD NOT take such actions.

   Published specification (recommended):

   Person & email address to contact for further information:
       Alexey Melnikov <alexey.melnikov@isode.com>

   Intended usage:  COMMON

   Owner/Change controller:  IESG

   Note:
    1). $Junk and $NotJunk are mutually exclusive. If more than one of
        them is set for a message, the mail client MUST treat this as if
        neither of them is set and SHOULD remove both of them from the IMAP
        server.

    2). There are existing clients that use mutually exclusive keywords
        Junk and NotJunk to mark a message as definitely containing
        /definitely non containing junk information. Use of
        "Junk"/"NotJunk" is deprecated, mail clients should be using
        "$Junk"/"$NotJunk" instead.

    3). Because different users might have differing views of what
        constitutes "junk", server implementations SHOULD favor the use
        of a private keyword, to allow the most flexibility.  However,
        because it will often be the case that there's broad agreement
        on the categorization of most messages in this regard, it
        will make the most sense for systems that implement
        shared messages to use a shared keyword, and to allow
        individual users to override that designation for themselves.
        An implementation might even take multiple overrides as a
        suggestion to change the shared flag, and consider that a
        useful optimization.

--------------------------------------------------

   Subject:    Registration of IMAP keyword $NotJunk


   IMAP keyword name:  $NotJunk

   Purpose (description):
       The user (or a delivery agent on behalf of the user)
       may choose to mark a message as definitely not containing junk
       ($NotJunk; see also the related keyword
       $Junk). The $NotJunk keyword can be used to mark, group
       or show messages that the user wants to see.

   Private or Shared on a server:  BOTH (see Note 3)

   Is it an advisory keyword or may it cause an automatic action:
       This keyword is advisory.

   When/by whom the keyword is set/cleared:
       $NotJunk can be set either by a delivery agent
       or a mail client on users behalf. The user must be able to
       set or clear $NonJunk at any time.

   Related keywords: $Junk

   Related IMAP capabilities:  None

   Security considerations:
       A message marked with $NotJunk keyword by one user might not be 
considered
       not to be junk by another user (or even by the same user under 
different
       circumstances). Any automated action taken by the mail system or by
       the MUA in response to this keyword needs to take that into account.

   Published specification (recommended):

   Person & email address to contact for further information:
       Alexey Melnikov <alexey.melnikov@isode.com>

   Intended usage:  COMMON

   Owner/Change controller:  IESG

   Note:
    1). $Junk and $NotJunk are mutually exclusive. If more than one of
        them is set for a message, the mail client MUST treat this as if
        none of them is set and SHOULD remove both of them from the IMAP
        server.

    2). There are existing clients that use mutually exclusive keywords
        Junk and NotJunk to mark a message as definitely containing
        /definitely non containing junk information. Use of
        "Junk"/"NotJunk" is deprecated, mail clients should be using
        "$Junk"/"$NotJunk" instead.

    3). Because different users might have differing views of what
        constitutes "junk", server implementations SHOULD favor the use
        of a private keyword, to allow the most flexibility.  However,
        because it will often be the case that there's broad agreement
        on the categorization of most messages in this regard, it
        will make the most sense for systems that implement
        shared messages to use a shared keyword, and to allow
        individual users to override that designation for themselves.
        An implementation might even take multiple overrides as a
        suggestion to change the shared flag, and consider that a
        useful optimization.