ietf
[Top] [All Lists]

Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard

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

<Prev in Thread] Current Thread [Next in Thread>