On Wed, 27 Feb 2008, Dan Karp wrote:
... 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.
I see no reason to remove/deprecate the FROM, TO, and CC sorts.
You have presented no reason other than your dislike of their definition.
The provision of FROM, TO, and CC sorts in no way blocks future extensions
that offer other forms of sorting these (and other fields).
I see abundant reason not to do so.
SORT is implemented by at least two clients and at least four servers.
All of these would have to change to support the proposed crippled SORT.
Worse, my client would require substantial new, special case code to
restore the functionality lost due to crippled SORT; and after this work
will have worse performance.
These facilities are harmless, easy to implement as part of SORT, and have
multiple interoperable implementations.
SORT=BASE, by subsetting SORT, violates section 1 which states that:
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.
A subsequent draft could define SORT=FROM, with [an
alternative] algorithm for FROM sorting.
I have no objection to adding new sort keys. That has been my consistent
position for many years.
I object strongly to removing existing sort keys.
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.
My client has well over a million users worldwide (we have the numbers)
and uses SORT and THREAD as defined by this specification.
I call that utility.
And, as you've already stated, "cc sorts are
extremely rare" and "In practice, To sorts are rare."
The email client world is dominated, overwhelmingly, by Outlook. I doubt
that you mean to say that Internet email specifications should be defined
by, and limited to, by what Outlook uses.
Notwithstanding how often To or cc sorts are used (and From sorts are
quite commonly used), this is a functionality which has been my client for
nearly 2 decades. The original impetus for IMAP SORT over 10 years ago
was to improve my client's performance by allowing large mailboxes to be
sorted without having to download ENVELOPEs for every message in the
mailbox.
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.
That is completely unacceptable.
Besides creating a situation which is *inferior* for my client, it muddies
the implementation waters to the point that it becomes less likely that
any implementation will implement, much less use, SORT in any form.
It is disingenuous to use the term "draft" to describe this specification.
This specification was approved as a Proposed Standard years ago, but was
held up in publication because (what is now viewed as a mistake) it was
felt that no Internet specification should deal with collation until an
i18n framework was first put in place.
-- 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