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 [EMAIL PROTECTED] (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@ietf.org https://www.ietf.org/mailman/listinfo/ietf