Subject: Re: [imapext] New Version Notification for draft-iceman-imap-specialuse-important-02.txt

From: Barry Leiba <[email-masked]>
Date: Wed, 17 Apr 2013 09:30:41 -0400

Hey, all.  Reviving this, after not having time for it for a while.
When last we spoke, the recommendation was to recast this proposal in
terms of a $Important message keyword.  This version of the draft does
that.  Comments, please.  Is this what people had in mind?

Remember that the model for this is Gmail's "important" flag, where
messages are marked as "important" heuristically, based on what the
system has seen you do with similar messages.  Users can also set or
clear the "important" flag, and the system will use that action to
modify its heuristics.  The "\Important" mailbox is then a collection
of some of the "important" messages (in Gmail's case, those that are
important and not archived).

This spec aims to generalize that, because Eric and I think it's a
useful model, apart from what Gmail specifically does with it.

Barry

On Mon, Apr 15, 2013 at 1:56 PM,  <[email-masked]> wrote:
>
> A new version of I-D, draft-iceman-imap-specialuse-important-02.txt
> has been successfully submitted by Barry Leiba and posted to the
> IETF repository.
>
> Filename:        draft-iceman-imap-specialuse-important
> Revision:        02
> Title:           IMAP $Important Keyword and \Important Special-Use Attribute
> Creation date:   2013-04-15
> Group:           Individual Submission
> Number of pages: 7
> URL:             http://www.ietf.org/internet-drafts/draft-iceman-imap-specialuse-important-02.txt
> Status:          http://datatracker.ietf.org/doc/draft-iceman-imap-specialuse-important
> Htmlized:        http://tools.ietf.org/html/draft-iceman-imap-specialuse-important-02
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-iceman-imap-specialuse-important-02
>
> Abstract:
>    RFC 6154 created an IMAP Special-Use LIST extension and defined an
>    initial set of attributes.  This document defines a new attribute,
>    "\Important", and establishes a new IANA registry for IMAP folder
>    attributes, registering the attributes defined in RFCs 3348, 3501,
>    and 6154.  This document also defines a new IMAP keyword,
>    "$Important", and registers it in the registry defined in RFC 5788.

---

From: Timo Sirainen <[email-masked]>
Date: Wed, 17 Apr 2013 16:43:03 +0300

> that.  Comments, please.  Is this what people had in mind?

Looks ok to me.

BTW. This reminds me about wanting to create a standardized
$HasAttachments keyword that is set by the server and the client can
read/change it.

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 17 Apr 2013 10:43:12 -0400

Hi Barry,

> useful model, apart from what Gmail specifically does with it.

I am still having a hard time figuring out how $Important is really any 
different from \Flagged. Taking a look at the two points in the definition 
in the current draft (Section 2):

1. Importance vs urgency. I don't see how users are expected to understand 
the difference between these. Even if it is, I don't like the fact that you 
say it is used for triage as I think that implies more than a two-level 
state (e.g., the popular "getting things done" methodology uses multiple 
"levels" of priority for tasks and workflows). Maybe a combination of 
\Flagged and $Important provides multiple levels, e.g., \Flagged+$Important 
== top priority, \Flagged=next level down, $Important=next level below 
that, neither=low priority (and of course we also have $Junk which arguably 
means the lowest "priority" of all). But using those in combination does 
not seem right. Perhaps we need $Priority1, $Priority2, ... keywords to 
cover a multi-level priority.

2. Heuristically set: the fact that the server might set it is irrelevant - 
nothing stops a server from doing that with \Flagged (or indeed any other 
keyword or flag).

It is also not clear whether there might be side-effects of the user 
changing $Important. One thing Eric Iceman mentioned was that users can 
"train" their (GMail) server by copying/moving messages into the \Important 
mailbox - that is not discussed as a possibility for \Important in the 
draft right now. But wouldn't the same also apply to adding/removing the 
$Important keyword? If so, then I would tend to see that as a distinction 
from $Flagged, and that should probably be mentioned in the spec too.

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Wed, 17 Apr 2013 11:03:18 -0400

> the difference between these.

Gmail users seem to.

It's the sense of "this message came from someone you often correspond
with," "this message is part of a discussion thread you've been
participating in," or "this message has keywords that you seem to
consider significant," as opposed to "this message comes from someone
you don't know, and it's inviting you to attend a conference you've
never paid attention to before."

Whereas "urgency" has the sense that "this message is something you
need to deal with right away."  Usually, that's because you marked it
that way.  In Gmail terms, that's "starred", and that's exposed as
\Flagged in IMAP.

> Even if it is, I don't like the fact that you
> "levels" of priority for tasks and workflows).

It might be that something other than a binary indicator would be
useful.  This isn't that, and isn't meant for that.  Do you think the
distinction I made above is not useful?  There are certainly a lot of
Gmail users who think it is.  Do you, perhaps, have a suggestion for a
better way to say this than what I've said in the document?  (I can
certainly put some of what's above into the document, as an example
use case.)

> nothing stops a server from doing that with \Flagged (or indeed any other

I don't agree at all that it's irrelevant.  In the vast majority of
cases, \Flagged is set by the user.  It might also be set by a Sieve
script or the equivalent (I do have some Gmail filters that set it),
but that's also set by the user through a rule the user created.  Do
you actually know of any servers that set \Flagged heuristically,
without an explicit rule from the user?

The whole point here is that $Important is *intended* to be set
heuristically, whereas \Flagged is *intended* to be set by the user.
That it might sometimes be done otherwise is a side point.

> mailbox - that is not discussed as a possibility for \Important in the draft
> right now. But wouldn't the same also apply to adding/removing the

Hm.  I took this out, because I understood that people thought that
use case was problematic.  I'm happy to add it back in (I think it's a
significant and useful case).

Barry

---

From: Pete Maclean <[email-masked]>
Date: Wed, 17 Apr 2013 17:48:57 -0400

I made a pitch before for clarification to be added as to whether a 
mailbox flagged as  \Important is intended to hold only $Important 
messages or not.  I see this has not been done and I am wondering 
why.  Does the document make it clear to others and just not to 
me?  Or is there an intention to leave this deliberately vague?  I 
also wonder if there is an intention that a user's mail store should 
only ever have, at most, a single \Important mailbox.  The phrase

	the identity of a user's "\Important" mailbox

at the top of page 3 suggests that this is the case but it seems 
hardly as clear as something should be in an RFC.

Pete Maclean

---

From: Barry Leiba <[email-masked]>
Date: Wed, 17 Apr 2013 18:08:06 -0400

> I made a pitch before for clarification to be added as to whether a mailbox
> flagged as  \Important is intended to hold only $Important messages or not.
> I see this has not been done and I am wondering why.  Does the document make
> it clear to others and just not to me?  Or is there an intention to leave
> this deliberately vague?

Hm.  You don't think this is clear?:

   In an
   implementation that also supports the "$Important" keyword, this
   special use is likely to represent a virtual mailbox collecting
   messages (from other mailboxes) that are marked with the "$Important"
   keyword.

This is in the same vein as the descriptions in RFC 6154 of "\Flagged"
and "\Drafts".  It's "deliberately vague" in the same way: it's
suggesting an implementation, but not requiring it.

> I also wonder if there is an intention that a
> user's mail store should only ever have, at most, a single \Important
> mailbox.  The phrase
>
> at the top of page 3 suggests that this is the case but it seems hardly as
> clear as something should be in an RFC.

Again, from RFC 6154:

   All of the above attributes are OPTIONAL, and any given server or
   message store may support any combination of the attributes, or none
   at all.  In most cases, there will likely be at most one mailbox with
   a given attribute for a given user, but in some server or message
   store implementations it might be possible for multiple mailboxes to
   have the same special-use attribute.

This attribute is no different to any other attribute in that regard.

Barry