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

From: Dan Karp <[email-masked]>
Date: Wed, 27 Feb 2008 14:19:07 -0800 (PST)

> > 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
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 28 Feb 2008 15:29:32 +0000

Mark Crispin wrote:

> On Wed, 27 Feb 2008, Dan Karp wrote:
>
>>    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. 

SORT is implemented by at least 6 servers, as far as I know: 
<http://www.melnikov.ca/mel/devel/ServerReference.html> + Sun.

> 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.

---

From: Mark Crispin <[email-masked]>
Date: Wed, 27 Feb 2008 22:54:55 -0800 (PST)

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).

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

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.

> 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

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.

> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf