Sorry for the delay, somehow this managed to slip through the cracks during
the holidays and the subsequent email backlog...

On Mon, Dec 04, 2017 at 08:22:26 -0500, Josef 'Jeff' Sipek wrote:
> 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)

Ok, I ended up going with option #1 - removing the SHOULD.  It resolves the
invalid state and nothing more.  Once resolved (by ignoring both keywords),
the email is a known state and the client can proceed as normal - whatever
that may be.

I opted for not adding the 'server-toggling MAY'.  Since this behavior
wouldn't be required to be implemented by the server, all clients wishing to
work with $HasAttachment and $HasNoAttachment would have to assume that the
toggling isn't supported.  As a result, they would have to implement the
non-server-assisted behavior anyway.  In other words, they would have to
implement more than one code path - increasing complexity for no benefit.

Furthermore, most (all?) servers out there don't understand the meaning of
each keyword and instead treat them as simple labels associated with the
email.  Including the MAY here would suggest some expectation of the server
doing more, which is definitely not the intention.

Full texts below.

Jeff.

---
Subject Registration of IMAP keyword $HasAttachment

IMAP keyword name: $HasAttachment

Purpose (description):
Many mail user agents display a hint to the user that a particular email
contains attachments.  Without any help of the server, the user agent needs
to fetch at least a part of the email to determine whether or not the email
contains an attachment.  This is not only wasteful of system resources, but
it also causes a perceivable delay in displaying the mailbox contents to the
user.

The $HasAttachment keyword can be used by the delivery agent to mark a
message as containing an attachment.  The mail user agent can then
efficiently check for the presence of this keyword and convey the
information to the user in whatever way is appropriate.

Private or Shared on a server: BOTH

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 by either a delivery agent (e.g., through an internal
mechanism) or an email client (using the normal IMAP protocol).  The client
must be able to set or clear $HasAttachment at any time.  The keyword should
be set when the delivery agent or a client has determined that the email
contains at least one attachment.  If the email does not contain any
attachments, $HasAttachment should be cleared and $HasNoAttachment should be
set instead (see note).

Related keywords: $HasNoAttachment

Related IMAP capabilities: None

Security considerations: None

Published specification (recommended):

Person & email address to contact for further information:
Josef 'Jeff' Sipek <jeff.sipek@dovecot.fi>

Intended usage: COMMON

Owner/Change controller: IESG

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.

The exact meaning of "has an attachment" is left up to the implementors.
The consequences of implementations disagreeing on what constitutes an
attachment are minor, given that $HasAttachment is intended as only a hint
to the user in the UI.
---
Subject Registration of IMAP keyword $HasNoAttachment

IMAP keyword name: $HasNoAttachment

Purpose (description):
Many mail user agents display a hint to the user that a particular email
contains attachments.  Without any help of the server, the user agent needs
to fetch at least a part of the email to determine whether or not the email
contains an attachment.  This is not only wasteful of system resources, but
it also causes a perceivable delay in displaying the mailbox contents to the
user.

The $HasNoAttachment keyword can be used by the delivery agent to mark a
message as *not* containing an attachment.  The mail user agent can then
efficiently check for the presence of this keyword and convey the
information to the user in whatever way is appropriate.

Private or Shared on a server: BOTH

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 by either a delivery agent (e.g., through an internal
mechanism) or an email client (using the normal IMAP protocol).  The client
must be able to set or clear $HasNoAttachment at any time.  The keyword
should be set when the delivery agent or a client has determined that the
email does not contain any attachments.  If the email contains at least one
attachment, $HasNoAttachment should be cleared and $HasAttachment should be
set instead (see note).

Related keywords: $HasAttachment

Related IMAP capabilities: None

Security considerations: None

Published specification (recommended):

Person & email address to contact for further information:
Josef 'Jeff' Sipek <jeff.sipek@dovecot.fi>

Intended usage: COMMON

Owner/Change controller: IESG

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.

The exact meaning of "has an attachment" is left up to the implementors.
The consequences of implementations disagreeing on what constitutes an
attachment are minor, given that $HasNoAttachment is intended as only a hint
to the user in the UI.
---