Re: [imapext] CONDSTORE interaction with SORT/THREAD

[Alexey Melnikov <[e-mail]>]

On 12/08/2013 14:32, Jan Kundrát wrote:
> 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.
This can be used to do partial mailbox resynchronization using 
SEARCH/SORT. So it is like HIGHESTMODSEQ, just for the matching messages.
>> 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

Ok, I forgot about this :-).

> 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.
Yeah, I didn't pay attention to what I was typing. Assume it was 
something like 1175.
>
>> 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?
Yes, this would require an ABNF change. We can do that, as long as the 
new syntax is enabled when a compliant client signals a server by using 
an extension element.
>> 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 don't think the prohibition intended to apply in this case. One 
advantage of #3 is that it shouldn't break older clients, as long as 
they ignore unrecognized response (which they should).
>> 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.
Right.

Are you Ok with #2 after seeing Timo's response?
>> 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.
Ok. I think your suggested syntax need some tweaks to comply with RFC 
4466, but otherwise this looks sensible. I will have a more detailed 
look later.
>
> With kind regards,
> Jan
>
> [1] http://tools.ietf.org/html/draft-kundrat-incthread-01#section-2.3.1