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.

