> > If there's a problem with the draft -- for instance, that the FROM > > sort is useless from a client standpoint or that the CC sort will > > never be used by a real-world client -- then it should be fixed > > before reaching RFC status. If the resulting RFC is not protocol- > > or algorithm-equivalent to revision 19 of the SORT draft, then this > > would not be the first time that an extension's CAPABILITY string > > would have to change at the time of publication. > > I don't see a > > point in breaking a lot of client and server > implementations that > > implement the draft in its current form. The > draft has stayed > > almost the same for at least 5 years (I implemented > it then the > > first time). If you change the CAPABILITY string, nothing should break. In fact, I'd have no objections to completely removing the FROM, TO, and CC sorts from the draft and publishing it as SORT=BASE. Then any existing server implementation could advertise both SORT and SORT=BASE, indicating that they support both the published RFC as well as the 3 deprecated address sorts. A subsequent draft could define SORT=FROM, with a significantly less broken algorithm for FROM sorting. 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 think these changes should have been discussed long before reaching > last call. The draft is over 10 years old already! 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. _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf