On Sun, 2 Mar 2008, Dan Karp wrote:
> Once the draft makes it to Proposed Standard, getting a second draft out
> with a variant version of these sorts becomes exponentially harder.
When there is both a de facto standard that has existed for over 10 years,
and a completely incompatible de jure standard created because some guy
didn't like the de facto standard, then getting any standard becomes
impossible.
The SORT specification is infinitely extensible. The original keys are
there, and remain there forever. However, nothing prevents the creation
of FROM2, FROM.PLUS, ZIMBRAFROM, etc. as extensions to the keys. That is,
all new forms of SORT would be a superset.
The only thing that a client need concern itself about with a server is if
the server implements (at least) the SORT level it desires. If the client
just cares about the original, 10+ year old, keys, then any server SORT
will work, because all SORT is a superset of the original.
Should you get your way, there would be now two incompatible sets of keys.
There would be the set that has been around for more than a decade, and
the new incompatible set that *subsets* the original set instead of
*supersets* it.
Clients would have to know which set is implemented by the server. If the
server implements the wrong set, then the client will have to do all the
work in the client. The end result is sufficient fear, uncertainty, and
doubt that nobody will use server-based SORT at all.
> There is a clear consensus in the mail user agent marketplace for how
> address sorts should behave.
Empirical testing of a few clients does not constitute a "concensus".
> New revisions of the legacy servers would advertise both the legacy
> "SORT" and the standard "SORT=BASE". Legacy clients would see "SORT"
> and behave exactly as before. New clients would see both "SORT" and
> "SORT=BASE" and act accordingly.
I already explained why this can not work.
SORT=BASE, by definition in the current SORT specification, is a
*superset* of the 10+ year SORT.
A server which supports the base-level SORT extension indicates this
with a capability name which starts with "SORT". Future,
upwards-compatible extensions to the SORT extension will all start
with "SORT", indicating support for this base level.
Consequently, current software does
if (strcasencmp (cap,"SORT",4)) hasSort = 1;
Your demand has the effect of breaking this software. The new extension
would have to be called something like ZIMBRASORT, since the 10+ year old
SORT specification reserves the entire SORT* extension namespace for
upwards-compatible extensions. ZIMBRASORT, by being a subset (and hence
incompatible) must therefore have a different name.
The result is that, with IMAP sorting forked into two incompatible forms
of sort, nobody will implement either.
> I believe that your client already does client-side FROM sorting for
> servers that don't advertise SORT.
Yes, and it is as slow as cold molasses in January when such a server is
encountered. Users generally don't even try to sort or thread on such
deficient servers since it is entirely too painful.
I do not understand why you are so insistant upon demanding that
something that has been in use for 10+ years be removed. Forks in
specifications are bad things.
Let me take that back. Forks in specifications are not bad things; forks
in specifications are VERY bad things. The Achilles' heel of UNIX has
been the multiplicity of forks; and it's not just the forks of SysV vs.
BSD vs. Linux but incompatible forks within SysV, BSD, and Linux.
When IMAP forked in the past the result was incredible chaos and confusion
that should never be repeated. Ever since IMAP has gone to considerable
effort to maintain upwards compatibility and not fork. That is why, among
other things, we have BODY and BODYSTRUCTURE. That is why IMAP has at
times chosen ugly syntax and mechanisms, because doing so provided the
functionality without creating a fork.
If it was difficult to implement the keys in question, that would be one
thing; but it is utterly trivial to do so. The necessary framework is
provided by virtue of the ENVELOPE (a base specification requirement since
the very beginnings of IMAP) and SUBJECT sorting. A high school kid can
implement these keys with that framework in place.
Nothing prevents the addition of the "better" keys that you advocate,
other than your vaguely expressed fear that the "better" keys won't happen
if the "not better" keys are allowed to survive. If the "better" keys
can't survive that modest hurdle then maybe they really aren't "better"
after all -- or maybe the entire argument is pointless and you should just
let sleeping dogs lie.
-- 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