Subject: [MORG] Review: draft-ietf-morg-fuzzy-search-02

From: Cyrus Daboo <[email-masked]>
Date: Fri, 30 Jul 2010 10:44:54 +0200

Hi,
I have looked at this document. Some comments:

1) I would like to see an example of a mixed fuzzy/non-fuzzy search, just 
to emphasize that such a thing can happen. e.g.:

C: A01 SEARCH FUZZY SUBJECT "Mulberry" FROM [email-masked]

FROM - precise match, SUBJECT - fuzzy match

2) I would like it t be clear, that for a "plain" SEARCH response (i.e. no 
relevancy results) that the order of returned results is arbitrary (i.e. 
NOT ordered by relevancy) - I am assuming that that is the intent, but I 
would like it to be clear to client implementors.

3) Security: there should be some discussion about how relevancy rankings 
can be "poisoned" by smart attackers using certain keywords or hidden 
markup in their messages to boost the rankings.

4) Given RFC5255's comparator stuff, is the active comparator expected to 
have any influence on the fuzzy behavior? I am guess not, but it might be 
worth a mention.

5) How are rankings determined when more than one FUZZY is used? I assume 
the server has to use its own logic for aggregating the rankings.

6) Do clients need to care that the FUZZY search key is not distributive, 
e.g.:

FUZZY OR SUBJECT x SUBJECT y != OR FUZZY SUBJECT x FUZZY SUBJECT y

Otherwise OK.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 30 Jul 2010 11:14:42 +0200

Hi,
One more issue: how many results should a server return? We allow relevancy 
from 1 to 100, and in theory every message in a mailbox could have a 
ranking of 1 or more. Isn't the typical client use case that it wants just 
the top few rankings? If so, we need to specify how the PARTIAL search 
result code (defined in RFC5267) interacts with RELEVANCY. i.e.:

A02 SEARCH RETURN (RELEVANCY PARTIAL 1:10) FUZZY TEXT "Helo"

means return the top 10 relevant results. So the combination of RELEVANCY 
and PARTIAL would require the server to order the result set before 
applying the partial range matching.

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Fri, 30 Jul 2010 07:53:39 -0400

> have any influence on the fuzzy behavior? I am guess not, but it might be

I suppose it would be possible for ascii-numeric to have an effect.
< fuzzy header "special-field" "50" > would have different fuzz,
depending upon whether you used ascii-casemap or ascii-numeric.  On
the other hand, I imagine that any fuzzy string search would ignore
case, so specifying ascii-casemap would be unnecessary.

But we already say the server can do anything it wants, so do we
really need to mention this?  I suppose we could add something to that
paragraph, like "including ignoring the comparator".

> FUZZY OR SUBJECT x SUBJECT y != OR FUZZY SUBJECT x FUZZY SUBJECT y

I disagree with your example; I think they are the same, because fuzzy
applies to "OR", so I think it applies to the whole OR clause.

> Isn't the typical client use case that it wants just the top
> few rankings? If so, we need to specify how the PARTIAL search result code
> (defined in RFC5267) interacts with RELEVANCY. i.e.:
>
> and PARTIAL would require the server to order the result set before applying
> the partial range matching.

I'm not sure I like that requirement.  Maybe you have to use SORT if
you want that.  What happens in the general case of PARTIAL?  Might a
client that wants the *newest* 10 results be unhappy if it got the
OLDEST 10?

Barry

---

From: Timo Sirainen <[email-masked]>
Date: Sat, 31 Jul 2010 20:32:41 +0100

On 30.7.2010, at 9.44, Cyrus Daboo wrote:

> 1) I would like to see an example of a mixed fuzzy/non-fuzzy search, just to emphasize that such a thing can happen. e.g.:
> 

Added.

> 2) I would like it t be clear, that for a "plain" SEARCH response (i.e. no relevancy results) that the order of returned results is arbitrary (i.e. NOT ordered by relevancy) - I am assuming that that is the intent, but I would like it to be clear to client implementors.

Added the second sentence here:

"The RELEVANCY return option MUST NOT be used unless FUZZY search key is also given. Note that SEARCH results aren't sorted by relevancy, SORT is needed for that."

(Kind of ugly and bad place, but I just can't figure out anything better.)

> 3) Security: there should be some discussion about how relevancy rankings can be "poisoned" by smart attackers using certain keywords or hidden markup in their messages to boost the rankings.

I'll try to figure out some text about this later..

> 4) Given RFC5255's comparator stuff, is the active comparator expected to have any influence on the fuzzy behavior? I am guess not, but it might be worth a mention.

Added as suggested by Barry:

"FUZZY search key takes another search key as its argument. Server is allowed to perform all matching in an implementation-defined manner for this search key, including ignoring the active comparator as defined by [RFC5255]. Typically this would be used to search for strings, for example:"

> 5) How are rankings determined when more than one FUZZY is used? I assume the server has to use its own logic for aggregating the rankings.

Added: "When multiple search keys are matched fuzzily, it's server-dependent on how the relevancy score is calculated."

> 6) Do clients need to care that the FUZZY search key is not distributive, e.g.:
> 

I agree with Barry, those are the same. Added example:

FUZZY is applied to all search keys when parenthesis or OR is used. For example in this search query everything is matched fuzzily:

 C: A03 SEARCH FUZZY OR (SUBJECT work FROM [email-masked]) SUBJECT home
 S: * SEARCH 2 5
 S: A03 OK Search completed.

---

From: Timo Sirainen <[email-masked]>
Date: Sat, 31 Jul 2010 20:38:59 +0100

> client that wants the *newest* 10 results be unhappy if it got the

Yes, I think SORT (RELEVANCY) should be required for that.  RFC 5267 isn't super clear on if SORT supports PARTIAL, but I guess it should according to ABNF.