Dan Karp writes:
The problem with this is that it probably underspecifies.
Yes, I agree. But on the other hand it's close to the actual code.
One of the requirements of a SORT ordering is that there is a single valid value for any given message.
The name of this particular sort key says the key is that used for display, so IMO it had better be that.
This allows clients to catch the addition of a new message and slot it into the "correct" place in the list without having to issue a new SORT. It's certainly not a perfect plan, as any text-based sort ordering runs into big issues when the system hits a malformed header or when one side can parse the charset in a 2047 encoded-word and the other can't. But it's the rule.
I wonder if these concerns could be addressed by defining the sort key as equal to the addr-name sent by the server in response to FETCH-ENVELOPE. IIRC that's still 2047-encoded, but "like the addr-name you send for FETCH ENVELOPE, but 2047-decoded" is realistic and still simple.
Arnt