The proposed changes in the comments below create significiant incompatibilities with multiple interoperable client and server implementations that have been in production use and widely distributed worldwide for several years. The result of making any of these changes would be instability and inconsistency between implementations, creating an environment in which nobody can use these extensions because there is no reliable behavior. This document and its protocol are not new. Both have been around for many years, and their publication was delayed unreasonably, due to (what is now generally recognized to have been) a false belief that internationalization had to be solved first. Any of these changes would add further multi-year delay to this protocol and specification. Some of these involve considerable complexity which will require long discussion to hammer down. I recommend that these issues be punted to future work in new standards. Further comments interspersed below. On Wed, 27 Feb 2008, Dan Karp wrote: > >> 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. It does indeed result in false positives, and is arguably a kludge aimed more at Outlook's non-compliant alternatives to "re:" (which *is* defined as the One True Reply Prefix in RFC 2822) than the forward prefix problem. I don't see unambiguous benefit of instituting this incompatible change, there is cost with new false positives and instability/unreliability of behavior between implementations. I certainly do not want to redefine IETF standards as "follow whatever Microsoft [or other big vendor] does." Outlook generates non-compliant "localized reply prefixes" based upon a false notion that "re:" is an abbreviation for the English word "reply". This is a bug that should be fixed in Outlook. > 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: "worse" is a matter of opinion. Reasonable people may disagree and may consider what "most clients" do to be "worse". > - 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? Although the rule in SORT was created in the days of a much smaller Internet community, it remains a better choice intra-enterprise where userids map to a single person but host ids can be all over the place. Now, one may argue that intra-enterprise email should have a single host id, but that is not the reality. Again, this would be an incompatible change that may benefit some, will cost others, and will create instability and unreliability. > - 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. Sorting the addr-name opens a HUGE can of worms. Given the names "Bandou Mitsugoro", "Mark Crispin", "Nishimura Aiko", "Pedro Castro Gomez", and "Mao Zedong", a stupid sort will collate these as: Bandou Mitsugoro Mao Zedong Mark R. Crispin Nishimura Aiko Pedro Castro Gomez and a falsely-clever sort will collate these as: Nishimura Aiko Mark R. Crispin Pedro Castro Gomez Bandou Mitsugoro Mao Zedong Both of these are totally wrong. The actual correct collation, assuming(!) surname-first collation and Latin character ordering(!!), is: Bandou Mitsugoro Pedro Castro Gomez Mark R. Crispin Mao Zedong Nishimura Aiko due to where the surname is located in various cultures. And even that is making multiple unwarranted assumptions. The addr-name may not even be a name that has a surname e.g., a corporate name. Latin character ordering may not be correct either; in Japanese "Bandou" will collate before "Nishimura", but "Tanaka" will collate before either of these. This is why this was punted to be a sort of the addr-mailbox. Once again, changing this now would be an incompatible change that may benefit some, will cost others, and will create instability and unreliability. > - 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? Doing something like this was punted due to practicality's sake; and I don't see this changing. In practice, To sorts are rare. What little use they get is with mailing lists. Once again, changing this now would be an incompatible change that may benefit some, will cost others, and will create instability and unreliability. > - 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. This idea is definitely something that should be punted to future work. Among other things, it begs the question of "what is a group" and how an IMAP server is supposed to determine that. > - 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. I agree that cc sorts are extremely rare. Nonetheless, the implementation burden of including the capability is neglibible; and removing this may cause a negative impact to something that uses it now. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf