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 13:12:13 -0800 (PST)

> > If there's a problem with the draft -- for instance, that the FROM
> > sort is useless from a client standpoint or that the CC sort will
> > never be used by a real-world client -- then it should be fixed
> > before reaching RFC status.  If the resulting RFC is not protocol-
> > or algorithm-equivalent to revision 19 of the SORT draft, then this
> > would not be the first time that an extension's CAPABILITY string
> > would have to change at the time of publication.  > > I don't see a
> > point in breaking a lot of client and server > implementations that
> > implement the draft in its current form. The > draft has stayed
> > almost the same for at least 5 years (I implemented > it then the
> > first time).

If you change the CAPABILITY string, nothing should break.

In fact, I'd have no objections to completely 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 a significantly less broken algorithm for FROM sorting.

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 think these changes should have been discussed long before reaching
> last call. The draft is over 10 years old already!

Apologies for not commenting sooner.  For my server, implementing
sorting is sufficiently difficult that I'd decided to permanently skip
the SORT draft.  But I was just informed that SORT has been made a
prerequisite for Lemonade, and so I did my first thorough read-through
of the draft last weekend.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Mark Crispin <[email-masked]>
Date: Wed, 27 Feb 2008 13:41:14 -0800 (Pacific Standard Time)

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

Furthermore, they disregard multiple interoperable client and server 
implementations that have used the current definitions for over a 
decade.

> of the draft last weekend.

Nothing requires that any client implements SORT.  If you want to define 
and implement an extended SORT, by all means start an effort to get that 
going.

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.

There might be some merit if there was some notable technical difficulty 
in implementing the specification on a server.  But there is not.  The 
ability to generate the IMAP ENVELOPE is required in the base 
specification and consequently all the data needed to implement FROM/TO/CC 
sorting are present.  This isn't a matter of "can not do", it is a matter 
of "not wanting to do."

Any one of us can easily come up with a long list of facilities in 
Internet specifications that we, as individuals, consider "useless" and 
thus should be removed.  However, one person's "useless" feature may be 
another's vitally-important feature.  The time to axe "useless" features 
is when they are first proposed, not when there is over a decade of use 
and deployment (in IMAP; nearly two decades in Pine).

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf