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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf