Re: [imapext] CONDSTORE interaction with SORT/THREAD

[Jan Kundrát <[e-mail]>]

On Monday, 12 August 2013 13:56:17 CEST, Alexey Melnikov wrote:
> 1). Use ESEARCH response (RFC 4731) to return MODSEQ for all 
> matching messages and also extend it to return sorted results. 
> (This can be potentially be used for SEARCH with MODSEQ search 
> criterion as well). For example:
>
>   * ESEARCH (TAG "A001") SORTED 3,4,1,2 MODSEQ 175

I've just re-read the relevant bits of RFC 4551 again. I have to admit I do 
not understand the point of including the highest MODSEQ of the matching 
messages under the MODSEQ key -- what is the use case for that? Sure, it's 
in the RFC so we cannot change it now, but I'd like to understand the 
motivation behind this.

> Here SORTED is similar to ALL, but it preserves the SORT order 
> of matching messages.
> RFC 4731 already defines MODSEQ return item.

Unless I'm missing something, the example response invents a non-existant 
"SORTED" ESEARCH return value. RFC 5267 (CONTEXT=...) already defines the 
ESORT extension and the ESORT command and how it uses the ESEARCH response 
(some servers were broken and used to return an ESORT response, btw). The 
result is passed as if it was triggered via the ESEARCH command, only in a 
sorted form, so the correct return data are, IMHO:

* ESEARCH (TAG "A001") ALL 3,4,1,2 MODSEQ 175

I'm also confused because the command asked for MODSEQ >= 500, but the 
response claims that the highest MODSEQ of any matching messages is 175.

> 2). Extend SORT response in the same way CONDSTORE extended SEARCH 
response:
>
>   * SORT 5 3 4 1 2 (MODSEQ 175)

That would require a modification of the ABNF and as such it cannot be 
introduced retroacitvely, right?

> 3). Return 2 response: an ESEARCH with MODSEQ and a SORT:
>
>   * SORT 5 3 4 1 2
>   * ESEARCH (TAG "A001") MODSEQ 175

I realize this is about SORT, not SEARCH, but RFC 4466, section 2.6.1 
contains a SHOULD saying that there should only be a SEARCH *or* an ESEARCH 
response, not both.

> I personally have a slight preference for choices #3/#1, as I 
> don't want to prolifirate new variants of responses which are 
> not ESEARCH based.

Indeed, and for the reasons stated above, I prefer 1) after it's fixed to 
use ALL instead of SORTED.

> 1). Use ESEARCH response (RFC 4731) to return MODSEQ for all 
> matching messages and also extend it to return threaded results. 
> For example:
>
>   * ESEARCH (TAG "A002") THREAD ((2)(3 6 (4 23)(44 7 96))) MODSEQ 
909240921

I would love to have the THREAD return option for ESEARCH; in fact, I've 
tried to introduce it in draft-kundrat-incthread [1]. It will help Trojita 
understand the matching between commands and responses and therefore enable 
better pipelining.

With kind regards,
Jan

[1] http://tools.ietf.org/html/draft-kundrat-incthread-01#section-2.3.1