On Thu, 10 Jan 2003, Timo Sirainen wrote:
> Another thing I saw with UW, it
> didn't group these messages together:
> Subject: =?iso-8859-1?Q?foo?=
> Subject: =?iso-8859-1?Q?RE=3A_foo?=
Question for the list: should it?
It turns out that UW imapd does something different from the base subject
extraction algorithm described in draft-ietf-imapext-sort-11.txt. I'm not
sure if this is a bug in imapd or in draft-ietf-imapext-sort-11.txt, and I
am soliciting opinions on whether UW imapd should be changed to comply
with draft-ietf-imapext-sort-11, or if a revision of the draft should be
changed to comply with UW imapd.
UW imapd's algorithm is:
(1) Convert all continuations to spaces.
(2) Remove all leading WSP or subj-refwd.
(3) If the resulting text starts with a subj-blob, examine the text after
the subj-blob. Disregard any subj-trailer encountered. If there is
any text other than subj-trailer, remove the subj-blob and repeat (2)
and (3) until no matches remain.
(4) Convert all MIME encoded-words to UTF-8.
(5) Remove all subj-trailer.
(6) same as in draft-ietf-imapext-sort-11.txt
(7) same as in draft-ietf-imapext-sort-11.txt
The significant difference between UW imapd and the draft is that in UW
imapd leading subj-leader is *not* considered if it is encapsulated in a
MIME encoded word.
It looks like the original draft agreed with UW imapd, and it got changed
in draft -03 or -04 to do the encoded-word conversion at the very start.
I forget why. Does anyone remember?
If UW imapd is in the wrong, it will be a while before this gets fixed.
We just released Pine 4.52 and imap-2002b.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
