Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard

[Mark Crispin <[e-mail]>]

On Mon, 3 Mar 2008, Dave Cridland wrote:
> I can think of circumstances where sorting by the full email address is 
> useful (which would also catch the above), and where sorting by the full name 
> is also useful.

I agree with all this; which is why the SORT/THREAD specification is 
extensible.  I have said many times that I would support a follow-on 
specification that adds new sort keys and thread algorithms.  As long as 
the keys are not preposterous I would seriously consider implementing 
them.  I might even implement a preposterous key if the implementation is 
straightforward.

My objections are not -- and have never been -- about adding new keys. 
My objections are to ademand that existing keys with a long history be 
removed.

If the keys in question are difficult to implement in a server, then the 
server is fundamentally flawed in its frameworks.  The most plausible 
explanation would be a server that uses a database back end that doesn't 
have ready access to the necessary addr-mailbox components.  That's no 
excuse.  The same data are needed to deliver satisfactory ENVELOPE 
performance; if the server can not do that well then it is not doing IMAP 
well.

Then there is the postulate that the presence of "useless" keys will make 
it more difficult to add "more useful" keys.  That would happen in only 
two scenarios:
  (1) The existing keys are good enough.
and/or
  (2) Nobody cares enough about the issue.

Neither is a justification to remove functionality.

If something is "good enough", then it should win especially when it is 
entrenched for decades.  The ridiculous notion that "good enough" must 
yield to "perfect" has led to the current situation where the IETF never 
gets anything done.

And, if nobody cared enough about the issue, then the "more useful" keys 
are a solution in search of a problem and should die.

Put another way, we should add new sort keys iff the current set of keys 
are not "good enough" AND some consituency cares.  I consider both 
conditions to be plausible; but my stake is that these new keys are 
additions, not replacements, for the existing keys.

> Threads "changing" is indeed a problem for many cases - I'm not sure I see 
> the value in ordering by subject to address it though - could you explain a 
> bit more? (I'm not saying there's no value, I just can't visualize how this 
> helps).

Typically, the thread-changer thinks that he has broken the thread by 
changing the subject, but did not do anything about the references links. 
A SUBJECT sort or ORDEREDSUBJECT thread breaks the thread, since neither 
uses the references links at all.

Now, there are also cases where the subject changes but the thread is 
legitimately the same.  That's why I don't use just one collation; I 
normally use THREAD=REFERENCES by default but switch to other collations 
when the situation is such that I think one of them will do a better job.

> Hard - one has to consider what the flag's precedence is, and how to order 
> flag combinations. Some cases are easy - one might say that (\Flagged) > 
> (\Flagged \Seen) > () > (\Seen), but where user-defined keywords are heavily 
> used, any sort order really needs to be client-defined.

I agree.  If flag sorting is done at all, it needs to be engineered 
carefully and probably via a client-defined mechanism.

> I've seen people doing both "Sent" and "Received" date sorts.

Strong agreement.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.