86 lines
3.8 KiB
Plaintext
86 lines
3.8 KiB
Plaintext
MBOX-Line: From mrc at CAC.Washington.EDU Mon Apr 9 11:19:29 2007
|
|
To: imap-protocol@u.washington.edu
|
|
From: Mark Crispin <mrc@CAC.Washington.EDU>
|
|
Date: Fri Jun 8 12:34:39 2018
|
|
Subject: [Imap-protocol] thread computation algorithms and Exchange
|
|
In-Reply-To: <07Apr9.104129pdt."57996"@synergy1.parc.xerox.com>
|
|
References: <07Apr9.093358pdt."57996"@synergy1.parc.xerox.com>
|
|
<alpine.OSX.0.98.0704090939120.11423@pangtzu.panda.com>
|
|
<07Apr9.101403pdt."57996"@synergy1.parc.xerox.com>
|
|
<alpine.OSX.0.98.0704091015270.11423@pangtzu.panda.com>
|
|
<07Apr9.104129pdt."57996"@synergy1.parc.xerox.com>
|
|
Message-ID: <alpine.OSX.0.98.0704091048010.11423@pangtzu.panda.com>
|
|
|
|
On Mon, 9 Apr 2007, Bill Janssen wrote:
|
|
> Yeah, but... The (expired?) document at
|
|
> http://tools.ietf.org/html/draft-ietf-imapext-sort-19
|
|
|
|
That document is NOT expired, HAS been approved for publication, and is
|
|
blocked for publication pending the IMAP internationalization document
|
|
which is in its final stages.
|
|
|
|
> is attempting to
|
|
> standardize two hacks
|
|
|
|
I take offense at that comment.
|
|
|
|
> that let possessors of a quantity of mail
|
|
> organize it into threads that a human may recognize. While both of
|
|
> these hacks are reasonable given the kinds of information usually
|
|
> found in email headers in non-corporate environments, they are also
|
|
> unreasonably fragile to the extent they are based on comparison of
|
|
> "Subject" header strings, which are typically presented in an MUA in
|
|
> an edit window for the responder to mung at will.
|
|
|
|
Within the IMAP context, only the sender of a message may alter the
|
|
Subject. They typically do this for a reason; a reason that is generally
|
|
not capricious, and with full knowledge of the impact of the change upon
|
|
the receipient's MUA. Subjects are used as primary mechanisms only by
|
|
those sorting and threading algorithms that are named to use Subject.
|
|
|
|
The THREAD=REFERENCES mechanism uses Subjects only as a backup, to join
|
|
threads that are likely (albeit not certainly) to be related but had their
|
|
linkages broken.
|
|
|
|
What you are suggesting is that this is to be abandoned in favor of some
|
|
arbitrary set of headers defined by Microsoft, but neither documented nor
|
|
submitted to the open standards community for consideration.
|
|
|
|
I'll leave aside your comment about "non-corporate environments"; but
|
|
please take the time to research the history and traditions of the IETF
|
|
before making such comments in the future.
|
|
|
|
> However, in many email messages, there is additional machine-injected
|
|
> information, not exposed to the whim of the human user, which may aid
|
|
> in the determination of threads which actually make sense to the human
|
|
> user.
|
|
|
|
As the children say, "well, duh!"
|
|
|
|
There is such a mechanism. It was defined in the days when Bill Gates was
|
|
an undergraduate at Harvard illicitly hacking on his BASIC interpreter on
|
|
their PDP-10. The THREAD=REFERENCES algorithm uses this mechanism.
|
|
|
|
> In particular, it may be possible to exploit this information
|
|
> in order to correct for some of the fragility introduced by comparing
|
|
> the "Subject" header. It doesn't seem out of the question for someone
|
|
> to try to standardize a third or fourth or fifth hack based on this
|
|
> information to add to the THREAD extension. Given that vast amounts
|
|
> of corporate email may include these headers, might be worth looking
|
|
> into.
|
|
|
|
Non-standard proprietary headers do not belong in standards documents.
|
|
If there is data in such headers that can not be found in the equivalent
|
|
standard headers, the fix for the problem is to induce the vendor to use
|
|
the standard headers.
|
|
|
|
The fix is NOT to "reverse engineer" Microsoft's, or any other other
|
|
vendor's, undocumented proprietary headers. That is asking for trouble.
|
|
|
|
-- 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.
|
|
|