Re: [Extra] SEARCHRES / IMAP4rev2 clarifications

[Timo Sirainen <[e-mail]>]

On 16. Mar 2020, at 13.52, Timo Sirainen <[e-mail]> wrote:
> 
> On 13. Mar 2020, at 15.43, Alexey Melnikov <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>>> 4) Interaction of FUZZY and SEARCHRES: SEARCH RETURN (SAVE MIN RELEVANCY)
>>> 
>>> Well, this is probably clear enough that RELEVANCY shouldn't affect $ results? But the FUZZY RFC doesn't specify very clearly how RELEVANCY should interact with MIN, MAX or COUNT options. Maybe it could use errata to clarify? I suppose with MIN/MAX only the one relevancy should be returned, and with COUNT all the relevancies?
>> 
>> We probably need to do an update at some point, but submitting errata is sensible in this case.
> 
> This is actually getting a bit confusing as well. The simple cases:
> 
> RETURN (ALL RELEVANCY) : return ALL relevancies
> RETURN (MIN RELEVANCY) : return only the MIN's relevancy
> RETURN (MAX RELEVANCY) : return only the MAX's relevancy
> RETURN (PARTIAL n:m RELEVANCY) : return only the PARTIAL result's relevancies
> 
> The more confusing ones:
> 
> RETURN (MIN MAX RELEVANCY) : return MIN and MAX relevancies. But what if MIN=MAX, i.e. only one result? Is there 1 or 2 relevancies returned?
> RETURN (MIN MAX PARTIAL n:m RELEVANCY) : Similar to above - what if MIN/MAX overlaps the PARTIAL results?
> RETURN (RELEVANCY) : Maybe this should be an error?
> RETURN (COUNT RELEVANCY) : Does this even make sense either?
> RETURN (MIN MAX PARTIAL n:m COUNT RELEVANCY) : Should COUNT change anything?
> 
> Maybe MIN and MAX should always prepend and append the min/max relevancies, regardless of whether they overlap each others or PARTIAL. And in COUNT case I'd make it a no-op regarding RELEVANCY.

This got a bit stuck a year ago. Thinking about this again, maybe RELEVANCY doesn't make sense when using MIN, MAX or COUNT? So add an errata to section 4:

The RELEVANCY return option MUST NOT be used unless ALL or PARTIAL return option is also used.

Also I remember thinking that the relevancy scores would be specific to the search query, so that it might not make sense to try to compare relevancy scores between two different search results. That's not explicitly said in the RFC though.