> > 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.
You're right. Sorry about that. I apologize for the inflammatory tone
of my previous remarks, and I'll try not to use such provocative
language going forward.
I think that a FROM sort is important, but I don't feel that many
clients at all will be able to make use of the FROM sort as specified in
revision 19 of the SORT draft. I realize that it's probably too late in
the process to make substantive tweaks to the sorting algorithms in
SORT. But I also realize that if a variant of the FROM sort is included
in the published SORT RFC, the probability that a more usable SORT FROM
will ever be published becomes exponentially less likely.
So I think that it's a very good idea that "these issues be punted to
future work in new standards," as you put it. So I'll again put forth a
kick-the-can-down-the-road proposal:
... 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 [an
alternative] algorithm for FROM sorting.
> 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.
The point I was trying to make is that including sort criteria in the
proposed RFC should be based on client utility, not on whether it's easy
or hard to add them. And, as you've already stated, "cc sorts are
extremely rare" and "In practice, To sorts are rare."
I understand that you don't want to break interop for clients and
servers that have implemented draft versions of the SORT extension. The
SORT=BASE capability should address that issue.
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf