Subject: Re: [MORG] sortdisplay

From: Dan Karp <[email-masked]>
Date: Thu, 5 Feb 2009 09:47:30 -0800 (PST)

> Shouldn't it also define DISPLAYTO? I'd think that's also important,
> especially in "Drafts" and "Sent messages" mailboxes.

I've been wrestling with this, and the problem I have is that the "To"
header is multivalued, but the order of those addressees has no meaning.
If "To: Alexey, Timo" sorts different from "To: Timo, Alexey", you may
have a problem.  And no matter how you slice it, "To: Alexey, Timo" is
probably not going to sort with "To: Timo", which is a bummer if I'm
trying to find messages sent to Timo.

So I'm planning on punting on DISPLAYTO unless we can do better than
"kinda useful sometimes".  Ideas?

> Should RFC2822 references be RFC5322 instead?

Absolutely.  Will fix in the next version.

---

From: Timo Sirainen <[email-masked]>
Date: Thu, 05 Feb 2009 12:57:00 -0500

> "kinda useful sometimes".  Ideas?

Is this really a problem? In my "Sent Messages" mailbox only 25 of 17457
messages have multiple recipients. I think most other people also put
only one recipient to To: field and the rest to Cc. That's also how
clients usually do the replying.

---

From: Timo Sirainen <[email-masked]>
Date: Thu, 05 Feb 2009 14:10:30 -0500

On Thu, 2009-02-05 at 09:47 -0800, Dan Karp wrote:
> And no matter how you slice it, "To: Alexey, Timo" is

Well, it would be possible to duplicate the seq/uid in the reply for
each recipient.. But I don't know if that's a good idea.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 6 Feb 2009 11:11:13 +0100

> each recipient.. But I don't know if that's a good idea.

I think not at all a good idea.

Arnt

---

From: Timo Sirainen <[email-masked]>
Date: Fri, 06 Feb 2009 12:59:01 -0500

> clients usually do the replying.

I think we want to create extensions that help clients do what they
want? Most clients allow sorting by To:, and I'd think that most (all?)
of them simply do the To: sorting by the first address. I can verify
that this happens with Evolution and Thunderbird.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 06 Feb 2009 13:13:18 -0500

>> clients usually do the replying.

This is *very* much *not* true of my mailbox and my client.  Please, let's not 
make these kinds of assumptions as we develop protocols.

> that this happens with Evolution and Thunderbird.

Yes, all clients I'm aware of treat most fields as unfolded strings for the 
purpose of sorting.  Which basically means that the first "to" wins (though most 
will sort multiple "to" addresses after all single ones, for this reason).

Barry

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 6 Feb 2009 22:16:51 +0100

Barry Leiba writes:
> This is *very* much *not* true of my mailbox and my client.  Please, 
> let's not make these kinds of assumptions as we develop protocols.

We don't really have a better option.

RFCs 822-5322 say To can contain multiple addresses.

RFC 5256 says the SORT command sorts messages. Knuth vol 2 and surely a 
thousand other tomes say one item ends in exactly one point in the sort 
order. 5256 several times (e.g. the FROM key) helps by saying that when 
there's more than one potential sort key, one is chosen, thus 
preserving cardinality with the message.

There is is: A conflict. Now we have to live with it. We can pick one TO 
address and sort on that, or just use 5256's TO key.

>> want? Most clients allow sorting by To:, and I'd think that most 
>> (all?) of them simply do the To: sorting by the first address. I can 
>> verify that this happens with Evolution and Thunderbird.

Good enough for me, since I've never heard any relevant user complaints.

Arnt

---

From: Barry Leiba <[email-masked]>
Date: Fri, 06 Feb 2009 16:23:33 -0500

> We don't really have a better option.

The rest of your explanation isn't needed; you misunderstand me.

We obviously have to pick a way to sort on "to" that makes sense.  That mechanism 
has to take into account whether there's one or multiple "to" addresses.  My 
point isn't that what we're settling on it wrong.  It's that as we design these 
protocol, we should not make assumptions about how people use email, and, in 
particular, how people address their email.

Carry on....

Barry