Let's step back for a moment.
The purpose of sorting in mail clients is so that users can find
messages they're looking for.
After sorting on INTERNALDATE, the user skips down the "Received" column
to the range that their target messages fall in. And, voila! The
messages are there.
After sorting on SUBJECT, the user skips through the results to the set
of messages with the correct normalized subject. This works because the
user mentally normalizes the Subject header in the same way that the
SORT extension does. (The transform's easy to do, and years of mail
client use have trained them to do this; they're not looking under 'R'
for "re: Your Brains".) And, voila! They find the messages.
But sorting on FROM? That's where things break down for the draft.
I took a look at 7 different mail clients: Gmail, mutt, Outlook Express,
PC-Pine, Thunderbird, Yahoo! Mail, and Zimbra. In every single one of
these clients, there is a list of mail messages. And in that list,
every client has a "From" column. And every one of those "From" columns
contains the RFC2822 display-name of the From header of the relevant
message, or the RFC2822 addr-spec if there's no display-name. Every
single one.
Gmail ("search, not sort") doesn't allow you to sort on "From". But
every other client offers a "From" sort. And every client *but* PC-Pine
does it exactly the same way: A straight text sort on the data displayed
in the "From" column. And this makes sense, because a user knows the
name of the author of the message they're trying to find, and they can
skip to the right part of the list. Things work because (a) the user
knows the sort key of the message, (b) the sort key is displayed in the
user interface, and (c) the list is ordered on that displayed sort key.
It's just as intuitive as the received-date search.
PC-Pine is different. Looking at the first page of results when I point
it at the INBOX of my test account, I see the following "FROM sorted"
list (names but not sort order have been changed to protect the
innocent):
N 21 Jun 21 Betsy Avertain (787) ...
N 22 Sep 24 Hurricane Electric, Inc. (3465) ...
N 23 Sep 19 Waverly Bindle (11K) ...
N 24 Dec 7 boletim@xxxxxxxxxxxxxxx (12K) ...
N 25 Feb 23 Brian Pearson (5878) ...
N 26 Jan 24 patrick walton (66K) ...
N 27 Nov 9 build (2022) ...
N 28 Nov 18 Calvin Poutine (6275) ...
29 Feb 8 Leonardo Merman (2535) ...
Those are the messages that PC-Pine, using the FROM sort rules as
defined in the draft, has decided to sort in the "B-C" range. Note that
the sort key itself (the local-part of the RFC2822 addr-spec) isn't
displayed at all. And it's not just PC-Pine: NO CLIENT that I know of
displays that information by default in the message listing; most if not
all can't even be configured to show it.
So if I'm looking for messages from Pat Walton, I'm going to first look
under "P" and not find anything, then wonder if I haven't actually filed
his messages into a different mailbox, then rack my brain until if I'm
lucky I remember that his username is actually "bpw", then skip to
somewhere in the "B"s and start trying to remember if Brian Pearson's
username was "brianp" (in which case I need to scroll up to find the
block of messages from Pat) or "bpearson" (in which case I need to
scroll down).
In order to find a message in this "sorted" list, you have to first
remember a piece of information that the client will not display. If
you can't remember this piece of information -- and, in the world of
display-name-based autocomplete and correspondents you rarely send
mail to, that's a large and growing probability -- you're completely
hosed. You then have to guess roughly the right position in the list to
jump to, and then in order to scroll/page you have to again remember a
non-displayed piece of information for each sender in the page you're
looking at.
This is not a joke case or an outlier. This is reality. I've
personally had usernames that started with "y.", "li", "da", "dk", "t-",
and "ka", most of them not by choice.
There is a reason that your cell phone's address book sorts by name,
not by phone number.
> I see no reason to remove/deprecate the FROM, TO, and CC sorts.
>
> You have presented no reason other than your dislike of their
> definition. The provision of FROM, TO, and CC sorts in no way blocks
> future extensions that offer other forms of sorting these (and other
> fields).
Once the draft makes it to Proposed Standard, getting a second draft out
with a variant version of these sorts becomes exponentially harder.
Getting server and client uptake for that revision is even less likely.
It is better for "the ecosystem" (I cannot believe I just typed that) to
solve the problem just once and to do it as correctly as possible.
There is a clear consensus in the mail user agent marketplace for how
address sorts should behave. Intentionally specifying a different
algorithm, especially one whose results can be as counterintuitive as
the one in the draft, seems unwise.
> SORT is implemented by at least two clients and at least four servers.
>
> All of these would have to change to support the proposed crippled
> SORT. Worse, my client would require substantial new, special case
> code to restore the functionality lost due to crippled SORT; and after
> this work will have worse performance.
Legacy servers such as yours would advertise "SORT". Legacy clients
looking for "SORT" would find it and use it. Nothing would break.
New revisions of the legacy servers would advertise both the legacy
"SORT" and the standard "SORT=BASE". Legacy clients would see "SORT"
and behave exactly as before. New clients would see both "SORT" and
"SORT=BASE" and act accordingly.
I believe that your client already does client-side FROM sorting for
servers that don't advertise SORT. Determining whether to do client- or
server-side FROM sorting based on whether the server advertised "SORT"
or just "SORT=BASE" is probably on the order of 10 lines of code.
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf