Lyndon Nerenberg (lyndon@atg.aciworldwide.com)
Thu, 13 Dec 2001 14:36:53 -0700
> C: A283 SORT (Message-Context SUBJECT) UTF-8 SINCE 1-Feb-1994
>
> B) Since th list of well-known-header changes rapidly, specify in the RFC a
> list of headers that must be supported.
This doesn't scale, because ...
> Of course I think that
> Message-Context should be one of them.
and the next person or RFC will want their header added. This will
require a re-specification of SORT, since existing implementations
will not interoperate with the new requests. This would result in the
SORT, SORT2, SORT3, SORT4, ..., SORTn extensions.
Clients that want to sort on arbitrary headers can already do so using
existing protocol mechanisms. Since this is an unbounded problem,
it's also the only sane way to do it. And for clients that implement
private header extensions, it's the only way they *can* do it.
Personally, I don't see much utility in SORT. I think that >99% of its
actual use will be as a poor substitute for what THREAD does.
Everything else SORT does can be done on the client side using the
results from FETCH ENVELOPE. (More accurately, I don't think SORT
can justify itself in the presence of THREAD.)
--lyndon
This archive was generated by hypermail 2.0b3 on Thu Dec 13 2001 - 23:37:08 IST