99 lines
4.4 KiB
Plaintext
99 lines
4.4 KiB
Plaintext
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
|
|
|