Subject: Re: [Extra] "IMAP $Important Keyword and \Important Special-Use Attribute"

From: Barry Leiba <[email-masked]>
Date: Thu, 8 Feb 2018 12:03:58 -0500

I'm coming back to this after some time: two comments in favour of
moving forward, no one thinking it's a bad idea, and the only comment
being that the distinction between \Flagged and $Important might not
be clear enough.  I'd also like to know if people will implement this
if we publish it.

On the distinction question, I really don't see what I can say that's
clearer than the contents of Section 2, which I reproduce here for
convenience:

---------------------------------------
2.  Definition of the '$Important' Message Keyword

   The "$Important" keyword is a signal that a message is likely
   important to the user.  The keyword can be set by the user, or
   automatically by the system based on available signals (such as who
   the message is from, who else the message is addressed to, evaluation
   of the subject or content, or other heuristics).

   This is distinct from the "\Flagged" system flag in two ways:

   1.  "$Important" carries a specific meaning of importance, as opposed
       to urgency.  It is meant to be used for a form of triage, with
       "\Flagged" remaining as a designation of special attention or
       particular urgency.

   2.  The setting of "$Important" is expected to be based at least
       partly on heuristics, whereas "\Flagged" is intended to be set by
       the user.
---------------------------------------

What Neil suggests isn't quite right, because we *do* want the user to
be able to set $Important, even if we don't expect it to be the
primary way $Important is set.  Maybe if I change the way the
explanation is focused it will help.  How's this new version look to
people?:

---------------------------------------
2.  Definition of the '$Important' Message Keyword

   The "$Important" keyword is a signal that a message is likely
   important to the user.  The keyword is generally expected to be set
   automatically by the system based on available signals (such as who
   the message is from, who else the message is addressed to, evaluation
   of the subject or content, or other heuristics).  While the keyword also
   can be set by the user, that is not expected to be the primary usage.

   This is distinct from the "\Flagged" system flag in two ways:

   1.  "$Important" carries a specific meaning of general importance, as
       opposed to follow-up or urgency.  It is meant to be used for a form of
       triage, with "\Flagged" remaining as a designation of special attention,
       need for follow-up, or time-sensitivity.  In particular, the sense of
       "$Important" is that other messages that are "like this one" according to
       some server-applied heuristics will also be $Important.

   2.  The setting of "$Important" is expected to be based at least
       partly on heuristics, generally set automatically by the server, whereas
       "\Flagged" is only intended to be set by the user with some sort of
       "flag this message" or "put a star on this message" interface.
---------------------------------------

Does that help?

Barry

On Wed, Nov 15, 2017 at 9:29 PM, Neil Jenkins <[email-masked]> wrote:
> On Thu, 16 Nov 2017, at 12:06 AM, Josef 'Jeff' Sipek wrote:
>
> My only concern here is that the distinction between $Important and
> \Flagged is a bit confusing.
>
>
> I agree the naming is a bit annoying, but I think the difference can be made
> clear:
>
> \Flagged: the user explicitly marked this as important.
> $Important: the server (using some unspecified algorithm) marked this as
> important.
>
>
> (Of course, clients may be able to help train the server by allowing users
> to toggle the $Important flag on messages the server miscategorised, which
> does blur the distinction somewhat…)
>
> FWIW, the \Flagged definition in RFC 6154 doesn't help this at all:
>
> This mailbox presents all messages marked in some way as
> "important".
>
> This is an unfortunate wording.
>
>
> Ouch, agreed.
>
> Overall though I'm in favour of this draft, and an IANA registry for
> special-use names is definitely a step forward (we'll use it for JMAP too).
>
> Neil.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 9 Feb 2018 11:26:29 +0000

Hi Barry,

With my implementer's hat on:

On 08/02/2018 17:03, Barry Leiba wrote:

> be clear enough.
In case I didn't say this earlier: I am somewhere in between "this is 
useful" and "this is not harmful and other people implemented it, so we 
should at least document it".
>    I'd also like to know if people will implement this
> if we publish it.
Maybe :-).
> clearer than the contents of Section 2, which I reproduce here for
I think this version is much better.

Thank you,
Alexey
> _______________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra

---

From: Barry Leiba <[email-masked]>
Date: Fri, 9 Feb 2018 09:18:25 -0500

Thanks for the input, Alexey.

>> I'd also like to know if people will implement this

I'd prefer " Probably :-) ", but I'll take it...

Barry

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 9 Feb 2018 15:25:13 +0000

> I'd prefer " Probably :-) ", but I'll take it...

As I see it, the distinction between \Flagged and $Important is too subtle 
to be reliably implemented and understood.

But I'll accept the registration. The subtlety not a blocking problem 
IMSNHO.

Arnt

---

From: Barry Leiba <[email-masked]>
Date: Fri, 9 Feb 2018 11:34:42 -0500

> to be reliably implemented and understood.

Hm.
The intent here is this:

On the server side:

-  \Flagged is set or cleared in response to an explicit command from
the client.

-  $Important is set via a heuristic process performed by the server,
usually involving analysis of header fields, what mailbox the message
is filed in, perhaps message content, attachments, and such.  It may
then be set or cleared in response to an explicit command from the
client, and the server may use that to adjust the heuristics in the
future.  It's also possible that the server will re-evaluate this and
make a message $Important later if the user accesses the message
frequently, for example.

On the client side:

- Typically, an icon such as a flag or a star, or an indication such
as red or bold text, is associated with \Flagged, and the UI provides
a way for the user to turn that icon or indication on or off.
Manipulation of the this results in a command to the server.

- Typically, a lesser indication is used for $Important.  The client
might or might not provide the user with a way to manipulate it.  If
it does, manipulation results in a command to the server.

Does that help you make an implementable distinction?  Would it help
to include a non-normative section of the document describing how this
is typically handled?

Barry

---

From: Neil Jenkins <[email-masked]>
Date: Wed, 14 Feb 2018 13:12:26 +1100

This description (intent on server and client) seems clear to me, and I
feel adequately distinguishes the two.
Neil.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 26 Feb 2018 06:20:24 -0800

I've posted draft-leiba-extra-specialuse-important-01, which has the
two text changes discussed here.

Does the working group want to take this as a working-group document?

Barry

---

From: Stan Kalisch <[email-masked]>
Date: Wed, 28 Feb 2018 19:23:56 -0500

Hi Barry,

> On Feb 26, 2018, at 9:20 AM, Barry Leiba <[email-masked]> wrote:
> 

I've only been able to take a quick look at this document, but in line 113, the phrase "specific meaning of general" strikes me as a bit awkward.  So I suggest the

OLD:

be rephrased as,

NEW:
1.  "$Important" specifies a meaning of general importance, as

or,

1.  "$Important" denotes a meaning of general importance, as

, etc.

Thanks,
Stan