On Wed, 27 Feb 2008, Dan Karp wrote: > But we can't publish a SORT draft in which FROM sorting is as broken as > it is in this draft. We really can't. It's worse than useless in its > present form, and leaving it as-is is significantly worse than just > omitting the FROM sort altogether. I object to this statement and similar earlier statements. They are needlessly provocative (among other things, Pine and Alpine have used and documented these "worse than useless" facilities for nearly 20 years), and presume that one person's opinions are proven fact in the face of contrary opinion. Furthermore, they disregard multiple interoperable client and server implementations that have used the current definitions for over a decade. > Apologies for not commenting sooner. For my server, implementing > sorting is sufficiently difficult that I'd decided to permanently skip > the SORT draft. But I was just informed that SORT has been made a > prerequisite for Lemonade, and so I did my first thorough read-through > of the draft last weekend. Nothing requires that any client implements SORT. If you want to define and implement an extended SORT, by all means start an effort to get that going. The implementation convenience in one server does not justify breaking a long-term framework that existing implementations depend upon. It especially not removing capabilities that are used by existing widely-distributed client implementations. There might be some merit if there was some notable technical difficulty in implementing the specification on a server. But there is not. The ability to generate the IMAP ENVELOPE is required in the base specification and consequently all the data needed to implement FROM/TO/CC sorting are present. This isn't a matter of "can not do", it is a matter of "not wanting to do." Any one of us can easily come up with a long list of facilities in Internet specifications that we, as individuals, consider "useless" and thus should be removed. However, one person's "useless" feature may be another's vitally-important feature. The time to axe "useless" features is when they are first proposed, not when there is over a decade of use and deployment (in IMAP; nearly two decades in Pine). -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf