Re: [imapext] Registering $hasAttachment & $hasNoAttachment

Josef 'Jeff' Sipek <jeff.sipek@dovecot.fi> Mon, 04 December 2017 13:22 UTC

Return-Path: <jeff.sipek@dovecot.fi>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865021243F6 for <imapext@ietfa.amsl.com>; Mon, 4 Dec 2017 05:22:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9J4JdeY-asF for <imapext@ietfa.amsl.com>; Mon, 4 Dec 2017 05:22:29 -0800 (PST)
Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id C2D411200B9 for <imapext@ietf.org>; Mon, 4 Dec 2017 05:22:28 -0800 (PST)
Received: from meili (josefsipek.net [71.174.113.7]) by mail.dovecot.fi (Postfix) with ESMTPSA id 5A6112B3CD2; Mon, 4 Dec 2017 15:22:27 +0200 (EET)
Date: Mon, 4 Dec 2017 08:22:26 -0500
From: Josef 'Jeff' Sipek <jeff.sipek@dovecot.fi>
To: Alexey Melnikov <aamelnikov@fastmail.fm>
Cc: Neil Jenkins <neilj@fastmailteam.com>, imapext@ietf.org
Message-ID: <20171204132225.GD1632@meili>
References: <20171203235834.GB1632@meili> <1512346907.3913979.1192707160.32EA0EE2@webmail.messagingengine.com> <3A29C592-4FAE-49DB-B6D9-1AC5F3CC42A8@fastmail.fm>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3A29C592-4FAE-49DB-B6D9-1AC5F3CC42A8@fastmail.fm>
User-Agent: Mutt/1.8.3 (2017-05-23)
Archived-At: <https://mailarchive.ietf.org/arch/msg/imapext/2Sj0-r3TgQhSANVBPBk1xgwn_lg>
Subject: Re: [imapext] Registering $hasAttachment & $hasNoAttachment
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Dec 2017 13:22:30 -0000

On Mon, Dec 04, 2017 at 10:25:16 +0000, Alexey Melnikov wrote:
> > On 4 Dec 2017, at 00:21, Neil Jenkins <neilj@fastmailteam.com> wrote:
> >> On Mon, 4 Dec 2017, at 10:58 AM, Josef 'Jeff' Sipek wrote:
...
> >> Note:
> >> $hasAttachment and $hasNoAttachment are mutually exclusive.  If more than
> >> one of them is set for a message, the email client MUST treat this as if
> >> neither of them is set and SHOULD remove both of them from the IMAP
> >> server.
> > 
> > Surely it SHOULD remove the one that is incorrect rather than both?
> 
> I think everything after "and SHOULD" can be deleted. As presence of both
> means neither is present, both what is written above and what you suggest
> is a reasonable course of action.

Right.  Dropping the SHOULD would leave it least constrained.  Suggesting
that either they both get dropped, or that only the correct one remains is
an additional (but very weak) "constraint".

So, the options are:

1. remove the SHOULD completely
2. use SHOULD remove both keywords
3. use SHOULD keep only correct keyword

The $Junk & $NotJunk IANA registration texts [1,2] use option #2.

Finally, I received a suggestion off-list to possibly add something like:

	Whenever a client sets $HasAttachment, the server MAY assist by
	automatically clearing $HasNoAttachment. (and vice versa)


All three options are fine by me (either with or without the server MAY
addition).  I think I have a slight preference for #1 just because it merely
resolves the invalid state.  Once resolved (by ignoring both keywords), the
email is a known state and the client can proceed as normal - whatever that
may be.

Jeff.

[1] https://www.iana.org/assignments/imap-keywords/junk/junk-template
[2] https://www.iana.org/assignments/imap-keywords/notjunk/notjunk-template

-- 
The obvious mathematical breakthrough would be development of an easy way to
factor large prime numbers.
		- Bill Gates, The Road Ahead, pg. 265