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

From: Barry Leiba <[email-masked]>
Date: Tue, 15 Jan 2013 15:37:13 -0500

I've given Eric a hand in creating a simple I-D to define a new
special-use mailbox attribute, which Google uses and which seems to
make sense to standardize.  As the document says, "\Important",
defined here, differs from "\Flagged", in that the latter typically
contains messages with the \Flagged flag, while "\Important" contains
messages that have been heuristically determined to be "important" to
the user.  So \Flagged groups messages that the user has marked, while
\Important groups ones the system has identified.

The document also creates a registry for special-use attributes, and
registers all those from the special-use spec.

Please give it a once-over, and comment.  If it looks good to folks,
I'll ask Murray to handle it in appsawg, or see if Pete wants to
AD-sponsor it.

Barry, as participant

On Tue, Jan 15, 2013 at 1:18 PM,  <[email-masked]> wrote:
>
> A new version of I-D, draft-iceman-imap-specialuse-important-00.txt
> has been successfully submitted by Eric Iceman and posted to the
> IETF repository.
>
> Filename:        draft-iceman-imap-specialuse-important
> Revision:        00
> Title:           IMAP LIST Special-Use Attribute: \Important
> Creation date:   2013-01-14
> WG ID:           Individual Submission
> Number of pages: 6
> URL:             http://www.ietf.org/internet-drafts/draft-iceman-imap-specialuse-important-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-iceman-imap-specialuse-important
> Htmlized:        http://tools.ietf.org/html/draft-iceman-imap-specialuse-important-00
>
> 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 Special-
>    Use LIST extension folder attributes, updating RFC 6154.
>

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 16 Jan 2013 22:34:25 +0000

Hi Barry,

On 15/01/2013 20:37, Barry Leiba wrote:
> Please give it a once-over, and comment.
This basically looks fine, but I think you should change the registry to 
be the registry of all mailbox attributes (including the ones defined in 
RFC 3501 and LIST-EXTENDED). The designated expert would have to check 
for conflicts with these names anyway, so make it easier for her/him.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 17 Jan 2013 10:51:08 -0500

> This basically looks fine, but I think you should change the registry to be
> the registry of all mailbox attributes (including the ones defined in RFC
> 3501 and LIST-EXTENDED). The designated expert would have to check for
> conflicts with these names anyway, so make it easier for her/him.

That makes sense, and it's a good idea; we'll make that change.

Barry

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 17 Jan 2013 11:24:29 -0500

Hi Barry,

> I'll ask Murray to handle it in appsawg, or see if Pete wants to

I don't think there is enough detail to properly explain the intent of the 
\Important flag. Specifically:

1) Are clients allowed to set the \Important flag on a CREATE or is it 
expected that only the server manages use of this flag?

2) What if the flag appears on multiple mailboxes? How is the user expected 
to differentiate between the possible use cases listed in Section 2? This 
is important because there is an implication that copying messages into 
"important" mailboxes may have side-effects, and it really needs to be 
absolutely clear to the user what those might be and how those side-effects 
may differ across different \Important mailboxes.

3) The example in section 2 of users copying messages into the mailbox to 
"train" the system seems wrong. Why should a user have to duplicate (copy) 
(or perhaps move) messages around to "train" the server. Shouldn't that be 
handled by message keywords instead? i.e., a $Important flag that can be 
set on a message to tell the server to "train"?

4) What is the expected client behavior here? I am assuming that the 
expectation is that clients should show \Important mailboxes more 
prominently than non-\Important ones?

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Thu, 17 Jan 2013 12:40:27 -0500

> \Important flag.

Interesting.  The detail is comparable to (actually, a bit more than)
what's in 6154 for the other special-use attributes.  Perhaps you'd
wish that those were also more richly specified, but the water under
that bridge has sailed, to horribly mix some metaphors.

> expected that only the server manages use of this flag?

I don't see why this is any different to any of the other special-use
attributes in that regard, nor why we'd have to say that.

> to differentiate between the possible use cases listed in Section 2? This is
> important because there is an implication that copying messages into

I don't see why this is any different to the others either.  6154 says
this about that, in general:

   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.

Other special-use attributes have side effects as well, even if
they're not specified in 6154 (again, bridges and water, and all
that).  If you copy a message in to a mailbox with the \Junk
attribute, servers might take that as an indication that it was spam
that got missed, and pass it to their spam learning engine.  Messages
in a mailbox with the \Trash or \Junk attributes will probably be
auto-deleted by the server after a period of time.

As with all special-use mailboxes, the exact meaning is server-dependent.

> handled by message keywords instead? i.e., a $Important flag that can be set
> on a message to tell the server to "train"?

That's probably a good point.  Eric will need to weigh in on that one,
but it might be better to remove that (and the side effect it
implies).  Eric?

> prominently than non-\Important ones?

That'd be up to the client, as with all the other mailbox special
uses.  This is giving information to the client, and we're not here to
say what the UI should do with it.  Similarly, RFC 3501 doesn't say
anything about what a client should do with \Marked, or, for that
matter, \Noinferiors.

Barry

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 17 Jan 2013 14:21:40 -0500

Hi Barry,

> attributes in that regard, nor why we'd have to say that.

This could be more a deficiency of 6154 in that it does not let the client 
know which special use flags would be acceptable for use with CREATE. That 
makes it hard to build a UI that only shows valid options to the user.

>> 2) What if the flag appears on multiple mailboxes? How is the user
>> expected to differentiate between the possible use cases listed in
>> Section 2? This is important because there is an implication that
>> copying messages into "important" mailboxes may have side-effects, and
>> it really needs to be absolutely clear to the user what those might be
>> and how those side-effects may differ across different \Important
>> mailboxes.
>

That is not true. Several flag definitions in 6154 (e.g. \Sent, \Draft) 
state that they can have special meaning to a client as well - i.e. that is 
where clients automatically store things. So, are clients allowed to treat 
\Important as a place to automatically store "important" messages? This 
touches on my point #4.

>> "train" the system seems wrong. Why should a user have to duplicate
>> (copy) (or perhaps move) messages around to "train" the server.
>> Shouldn't that be handled by message keywords instead? i.e., a
>> $Important flag that can be set on a message to tell the server to
>> "train"?
>

I still wonder whether what should be defined here as a $Important key word 
with the meaning that it is something set by the server itself as opposed 
to \Flagged (message flag) set only by users. Then the \Important mailbox 
is really a match for \Flagged (mailbox flag) - i.e. "virtual". I think 
that makes more sense because it is the messages content itself that likely 
defines importance as that should "stick" to the message no matter what 
mailbox it might be moved to.

> anything about what a client should do with \Marked, or, for that

Right, but as noted in #2 above, 6154 does state what clients might be 
expected to do for \Drafts, \Sent etc

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Thu, 17 Jan 2013 14:38:03 -0500

> makes it hard to build a UI that only shows valid options to the user.

Right, there is no discovery at all.  A server can allow these on
CREATE or not, as it pleases, and you can't know.  That's how 6154 was
designed, for better or worse.

> \Important as a place to automatically store "important" messages? This

No, that *is* true: the descriptions of \Sent and \Draft, for example
are very clear that the exact meaning is server-dependent.  For
example, \Sent says this:

        Some server implementations might put messages here
        automatically.  Alternatively, this might just be advice that a
        client save sent messages here.

That looks server-dependent to me.  If SentMail has the \Sent
attribute, a client has no idea from the description in 6154 whether
it can do "COPY 234 SentMail" or not.  And it has no idea whether the
server will automatically put anything there.  The description of
\Sent is just giving examples of how this is sometimes used.

> with the meaning that it is something set by the server itself as opposed to
> \Flagged (message flag) set only by users. Then the \Important mailbox is
> really a match for \Flagged (mailbox flag) - i.e. "virtual". I think that
> makes more sense because it is the messages content itself that likely

That's a good point.  And that's certainly how Gmail works: the
message is marked important or not, and the "\Important" mailbox is a
virtual mailbox that "contains" all messages marked as important.
Eric, would you want to extend this spec to also define a message
keyword, as Cyrus suggests?

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 17 Jan 2013 19:46:31 +0000

On 17/01/2013 19:38, Barry Leiba wrote:
  [...]
> keyword, as Cyrus suggests?
Can we reuse one already used for the same purpose by Thunderbird 
("$Label1")? I know it is misnamed, but it is widely deployed...

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 17 Jan 2013 15:00:28 -0500

Hi Alexey,

> ("$Label1")? I know it is misnamed, but it is widely deployed...

What exactly does Thunderbird use that for? How is it displayed in the UI?

-- 
Cyrus Daboo

---

From: David Bienvenu <[email-masked]>
Date: Thu, 17 Jan 2013 12:08:13 -0800

It's just the keyword that Thunderbird sets on an imap message when the 
user tags a message as "Important". The color associated with that tag 
is displayed in the message list, and the tag is displayed in the 
message header area when displaying a message as "Tags Important".

I think using \Important would be much less obscure than using $label1.

- David

---

From: Barry Leiba <[email-masked]>
Date: Thu, 17 Jan 2013 15:10:39 -0500

I've posted an -01 version that includes changes based on Alexey's
comment (so please make sure I got those changes right), and which has
a placeholder comment about Cyrus's suggestion.

Barry

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 17 Jan 2013 16:26:30 -0500

Hi Barry,

--On January 17, 2013 at 2:38:03 PM -0500 Barry Leiba 
<[email-masked]> wrote:

>> state that they can have special meaning to a client as well - i.e. that
>> is where clients automatically store things. So, are clients allowed to
>> treat \Important as a place to automatically store "important" messages?
>> This touches on my point #4.
>

All I am saying is that sensible use of \Sent depends on clients agreeing 
on the meaning of that text too.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 17 Jan 2013 16:39:46 -0500

Hi David,

--On January 17, 2013 at 12:08:13 PM -0800 David Bienvenu 
<[email-masked]> wrote:

> user tags a message as "Important". The color associated with that tag is
> displayed in the message list, and the tag is displayed in the message
> header area when displaying a message as "Tags Important".
>

Hrrm, I mapped the \Flagged message flag to "Important" in Mulberry's UI as 
I thought \Flagged was meant to indicate that. Other apps also use \Flagged 
but often refer to it as "Flag" for "Flagged". Does TBird use \Flagged for 
anything?

-- 
Cyrus Daboo

---

From: David Bienvenu <[email-masked]>
Date: Thu, 17 Jan 2013 13:43:06 -0800

On 01/17/2013 01:39 PM, Cyrus Daboo wrote:
> Hrrm, I mapped the \Flagged message flag to "Important" in Mulberry's 
> UI as I thought \Flagged was meant to indicate that. Other apps also 
> use \Flagged but often refer to it as "Flag" for "Flagged". Does TBird 
> use \Flagged for anything?
>
Yes, Thunderbird uses \Flagged for the starring of messages, which is a 
renaming of the "flag message" feature.

- David

---

From: Pete Maclean <[email-masked]>
Date: Fri, 18 Jan 2013 11:37:10 -0500

I am with Cyrus in that I would like to see this new flag defined a 
little more tightly.  I have major customers who are unhappy about 
the lack of specificity of existing IMAP flags.

For one thing, this draft, to my reading, does not make it clear 
enough whether the \Important flag is intended to mark a mailbox that 
is special in that it contains important messages and only important 
messages or to flag a mailbox that happens to contain some important 
messages along with possibly unimportant ones.  My guess is that the 
intention is the former but, if so, I would like to see that stated.

Pete Maclean

At 03:10 PM 1/17/2013, Barry Leiba wrote:
>_______________________________________________
>imapext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/imapext

---

From: <[email-masked]>
Date: Tue, 22 Jan 2013 15:46:31 -0800 (PST)

> but it might be better to remove that (and the side effect it

For better or worse, the way Gmail has exposed the "Priority Inbox" in
IMAP for years (in XLIST and later in SPECIAL-USE) has been via a
folder with this special attribute.  For Gmail, COPYing into it is
something user's can do to train the system and we're obliged to keep
that working.  And, it seemed like a reasonable scenario to offer it
an example possible way to interact with this folder for the purpose
of this RFC, but, that said, I do agree with you, Cyrus, that a
keyword is certainly more fitting for this particular use (and perhaps
for other virtual mailboxes defined in RFC 6154).  I'm certainly in
agreement with adding an $Important keyword and will pass that on to
the rest of the team.

Eric