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.

