Re: [Extra] SEARCHRES / IMAP4rev2 clarifications

Timo Sirainen <timo@sirainen.com> Fri, 13 March 2020 14:09 UTC

Return-Path: <timo@sirainen.com>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148493A07CE for <extra@ietfa.amsl.com>; Fri, 13 Mar 2020 07:09:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3q9oOqXOMy4 for <extra@ietfa.amsl.com>; Fri, 13 Mar 2020 07:09:50 -0700 (PDT)
Received: from sirainen.com (mail.sirainen.com [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFC73A07CC for <extra@ietf.org>; Fri, 13 Mar 2020 07:09:50 -0700 (PDT)
Received: from [192.168.10.104] (unknown [91.155.205.240]) by sirainen.com (Postfix) with ESMTPSA id 610BC2B3C8B; Fri, 13 Mar 2020 14:09:48 +0000 (UTC)
From: Timo Sirainen <timo@sirainen.com>
Message-Id: <4F653ABF-8CBB-421B-AE09-DC2904C5DD56@sirainen.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0B2B463A-14D0-4C86-BE5C-E780FD2545B3"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Fri, 13 Mar 2020 16:09:47 +0200
In-Reply-To: <6805c44c-83ce-49f7-2f24-e5b9a97479b4@isode.com>
Cc: extra@ietf.org
To: Alexey Melnikov <alexey.melnikov@isode.com>
References: <741FE532-1213-49E9-901F-46EECB7A223C@sirainen.com> <6805c44c-83ce-49f7-2f24-e5b9a97479b4@isode.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/CdHoOApEuAC8Ij9BZ_mDyciyjSg>
Subject: Re: [Extra] SEARCHRES / IMAP4rev2 clarifications
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:extra-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Mar 2020 14:09:52 -0000

On 13. Mar 2020, at 15.43, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
> 
>> 3) Interaction of CONTEXT and SEARCHRES:
>> 
>> SEARCH RETURN (SAVE MIN PARTIAL 2:10) 1:100
>> 
>> Is the $ value going to be 1 (MIN), 2:10 (PARTIAL), 1:10 (MIN+PARTIAL) or 1:100 (ALL)? I'm thinking 1:100 is the right answer here.
> 
> I think you found a real issue here. You are right that none of RFCs say anything about this case.
> 
> I think my implementation is doing 2:10 (PARTIAL), but I need to double check. The intent of is for SAVE to use what is returned or what would have been returned. One can argue that "1:10 (MIN+PARTIAL)" is also a valid choice here.
> 
> I don't think setting $ to 1:100 (ALL) is right here, because this client only wants to know PARTIAL and MIN data. Data about ALL messages might not even be available in the server, depending on how PARTIAL is constructed.

I guess this same question also applies to what happens even if MIN isn't used. My current code is saving 1:100, but that's mainly because of how the implementation happens to work right now (PARTIAL isn't very optimized).

I had also been thinking that maybe a client could work like:

a SEARCH RETURN (SAVE PARTIAL 1:10) TEXT stuff
..
b SEARCH RETURN (PARTIAL 11:20) $
..
c SEARCH RETURN (PARTIAL 21:30) $

But I suppose that's not really something clients would do.

Then again, if you do:

a SEARCH RETURN (SAVE COUNT PARTIAL 1:10) 1:100

COUNT would override PARTIAL here in any case, so $ would have to be 1:100.

I wonder if we should just disallow SAVE+PARTIAL combination?