> The IESG is considering the following document again now that > important dependencies are ready: > > - 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS' > <draft-ietf-imapext-sort-19.txt> as a Proposed Standard Outlook (and some other clients) has an alternative solution to the problem of localized followup/reply prefixes during the base subject extraction process. I believe it treats *any* string of 1 to 3 letter characters followed by a colon as an ignorable prefix. This may result in too many false positives, but it's an alternative that you may want to consider. Also, the proposed sorting rules for the address fields (FROM, TO, and CC) are in general worse than the rules that most clients currently use for sorting on these headers: - The sort criteria for FROM, TO, and CC are based only on the local-part of the first address in the header. So <larry@xxxxxxxxxx> and <larry@xxxxxxxxxx> sort together, which seems really wrong. Is there a compelling reason not to combine the addr-mailbox with the addr-host when generating the sort key? - The vast majority of mail clients display the decoded addr-name in the "From" column, falling back to addr-mailbox@addr-host if addr-name is NIL or blank. It's these strings that need to be in sorted order. If the server-side FROM sort results in the client displaying a "From" column that's not sorted, the server-side sort isn't useful. - Multi-recipient messages are very common, and there is no semantic meaning to the order of recipients in the To and cc headers. Messages sent to "<A>, <B>" and those sent to "<B>, <A>" should really sort together since they have the same set of recipients. Would it be acceptable to parse the relevant header, determine which address sorts "highest", and always use that address as the sort key for the message? - Likewise, we should give serious consideration to completely ignoring groups when determining a message's sort key. While a fully-qualified address means the same thing from one message to another, the membership of a group can easily change from one message to the next. - I don't think I've ever seen a client that displays a "cc" column in the UI. In fact, I can't come up with a remotely plausible use case for when a user would want to sort on CC. Unless there's a real reason for including CC sorting, it should be dropped from the draft. _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf