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

[Barry Leiba <[e-mail]>]

> 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.

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".

> 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

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.:
>
> 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.

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