MBOX-Line: From janssen at parc.com  Mon Apr  9 12:39:51 2007
To: imap-protocol@u.washington.edu
From: Bill Janssen <janssen@parc.com>
Date: Fri Jun  8 12:34:39 2018
Subject: [Imap-protocol] thread computation algorithms and Exchange 
In-Reply-To: <alpine.OSX.0.98.0704091048010.11423@pangtzu.panda.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>
	<alpine.OSX.0.98.0704091048010.11423@pangtzu.panda.com>
Message-ID: <07Apr9.123954pdt."57996"@synergy1.parc.xerox.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.

Excellent, thanks.  I found that hard to determine from the WG page.

> > is attempting to standardize two hacks
> 
> I take offense at that comment.

I'm sorry to hear that, as I meant no offense.  The two algorithms
described in the document are in fact effective ad-hoc ways of
grouping collections of email messages into threads, designed based on
observation of typical collections and knowledge of various email
clients, standards, and delivery mechanisms.  Nothing wrong with that,
given that an email "thread" is not a particularly well-defined
concept (though most users think they know what it means).  The very
names associated with the algorithms ("poor man's threading" and "used
in 'Netscape Mail and News' versions 2.0 through 3.0") seem (perhaps
only to me) to identify them as a particular class of algorithm.

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

I think you must be working with a different set of users than I'm
working with.  I find seemingly arbitrary and capricious changes to
the "Subject" header over and over again in my data sets.  Usually
with a small edit distance from the original subject, but with odd
patterns -- usually capitalization or punctuation changes.  That's why
I'm looking for a backup to the "Subject"-based backup.

I guess I should also go back and review my code that calculates the
"base subject".  Perhaps I've fat-fingered something.

> ...and with full knowledge of the impact of the change upon 
> the receipient's MUA.

Hmmmm.  I doubt that most users of email have an accurate model of the
effect of various changes on the recipient's MUA, particularly the
effect on something as loosey-goosey as message threading.  I'd be
happy to be pointed to the results of user studies that show I'm
wrong, though.

> 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 wasn't suggesting it be abandoned.  I was suggesting that it be
augmented by introducing additional "backup" techniques that could
further, and perhaps more accurately, discover threads that have had
their linkages broken.

> Non-standard proprietary headers do not belong in standards documents. 

I have a great deal of sympathy for this viewpoint (though I'm not
sure about the proprietary part; there seem to be various IANA
registries that keep track of proprietary mechanisms).

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

I think that's a fine theoretical solution; I'm less sure anyone knows how
to "induce" this particular vendor to do that.

> The fix is NOT to "reverse engineer" Microsoft's, or any other other 
> vendor's, undocumented proprietary headers.  That is asking for trouble.

Sure, OK.  I'm just trying to make my IMAP server provide threading
that users will perceive as being "as good" as that provided by the
Exchange server.  I guess the right thing to do would be to figure out
the algorithm and submit it to the threading algorithms registry.

Bill

