77 lines
2.8 KiB
Plaintext
77 lines
2.8 KiB
Plaintext
MBOX-Line: From MRC at Washington.EDU Thu Feb 21 13:56:21 2008
|
|
To: imap-protocol@u.washington.edu
|
|
From: Mark Crispin <MRC@Washington.EDU>
|
|
Date: Fri Jun 8 12:34:41 2018
|
|
Subject: [Imap-protocol] SEARCH SUBJECT
|
|
In-Reply-To: <47BDE0F2.4070704@watson.ibm.com>
|
|
References: <1203623023.4901.242.camel@hurina>
|
|
<47BDE0F2.4070704@watson.ibm.com>
|
|
Message-ID: <alpine.WNT.1.00.0802211344070.4860@Tomobiki-Cho.CAC.Washignton.EDU>
|
|
|
|
I agree. I feel that a server is allowed to implement fuzzy string
|
|
searching, with case-independence being the only absolute requirement.
|
|
|
|
More specifically, I never intended to forbid fuzzy matching, and
|
|
deliberately left it open-ended to allow implementations to experiment
|
|
with what worked best. [Google considered it good news when I told them
|
|
this was something in their server that I thought did NOT need fixing!]
|
|
|
|
This means that SEARCH compliance testing can only test for false
|
|
negatives; that is, for failure to match cases that both a rigid and a
|
|
fuzzy server would catch.
|
|
|
|
Clearly, if a message has
|
|
Subject: Hello<tab>world
|
|
then
|
|
tag SEARCH SUBJECT "Hello<tab>world"
|
|
and
|
|
tag SEARCH HEADER "SUBJECT" "Hello<tab>world"
|
|
and
|
|
tag SEARCH SUBJECT "HELLO<tab>WORLD"
|
|
and
|
|
tag SEARCH HEADER "SUBJECT" "hello<tab>WoRlD"
|
|
|
|
should all match, but it is server-dependent if
|
|
|
|
tag SEARCH SUBJECT "Hello world"
|
|
and
|
|
tag SEARCH HEADER "SUBJECT" "Hello, world"
|
|
and
|
|
tag SEARCH SUBJECT "hi, planet!"
|
|
and
|
|
tag SEARCH HEADER "SUBJECT" "konnichi ha, seikai"
|
|
match. [The last two being extreme examples that I wouldn't expect to
|
|
work.]
|
|
|
|
On Thu, 21 Feb 2008, Barry Leiba wrote:
|
|
> My opinion is that most searches are user-originated. A few, like flag
|
|
> searches, are used in server processes (to discover all the unseen messages,
|
|
> for instance, or to limit retrieval to a certain date threshold), but most
|
|
> are user-originated. Because of that, the point is more to do what's likely
|
|
> to make users happy, to give them what they expect... than it is to exactly
|
|
> match some picky spec.
|
|
>
|
|
> Therefore, I'd say that any server that normalized white space in a text
|
|
> search would be doing everyone a favour, whether or not it's to-the-letter
|
|
> "compliant" to anything. The same for a search that spanned "lines" (CRLF
|
|
> boundaries), treated email addresses intelligently, or normalized parts of
|
|
> speech or conjugations (treating "swim", "swims", and "swam" as the same
|
|
> word, say).
|
|
>
|
|
> None of that sort of thing is likely to have any interoperability effect.
|
|
> It's just likely to help users find what they're looking for.
|
|
>
|
|
> Barry
|
|
> _______________________________________________
|
|
> Imap-protocol mailing list
|
|
> Imap-protocol@u.washington.edu
|
|
> https://mailman1.u.washington.edu/mailman/listinfo/imap-protocol
|
|
>
|
|
|
|
-- Mark --
|
|
|
|
http://staff.washington.edu/mrc
|
|
Science does not emerge from voting, party politics, or public debate.
|
|
Si vis pacem, para bellum.
|
|
|