Re: [Extra] SEARCHRES / IMAP4rev2 clarifications

Alexey Melnikov <alexey.melnikov@isode.com> Fri, 13 March 2020 13:44 UTC

Return-Path: <alexey.melnikov@isode.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 AED3E3A07BF for <extra@ietfa.amsl.com>; Fri, 13 Mar 2020 06:44:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
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 chlHICrqdzJ4 for <extra@ietfa.amsl.com>; Fri, 13 Mar 2020 06:44:26 -0700 (PDT)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 60D013A07D3 for <extra@ietf.org>; Fri, 13 Mar 2020 06:44:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1584107060; d=isode.com; s=june2016; i=@isode.com; bh=iG4Ao3U7KoNtGysZCmboNf07cS3210CXnTEviErc3wE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=afXeZem8igOEragR6w1m/dBAjKvN/sXdjYd95Ng4mhUAqK6SL41z1Bz9A2+8M4qK/IHJAK KmRQFlCmLKxPXeJZ1ekMuEs2JT33zEt7pPNLMJvzX17W4s3NkH6S27vMPlT1Bj/PkjxUWT LAyNUGolmYVefOw7E5FQklNyKMXNUu4=;
Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <XmuONABtNTNj@waldorf.isode.com>; Fri, 13 Mar 2020 13:44:20 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
To: Timo Sirainen <timo@sirainen.com>, extra@ietf.org
References: <741FE532-1213-49E9-901F-46EECB7A223C@sirainen.com>
Message-ID: <6805c44c-83ce-49f7-2f24-e5b9a97479b4@isode.com>
Date: Fri, 13 Mar 2020 13:43:51 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1
In-Reply-To: <741FE532-1213-49E9-901F-46EECB7A223C@sirainen.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/9v0a58wUTOsbjOPiK5Z7MxbEDeM>
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 13:44:34 -0000

Hi Timo,

On 13/03/2020 10:22, Timo Sirainen wrote:
> I was just fixing various bugs in my SEARCHRES implementation and realized that there's a few issues that aren't too clear:
>
> 1) SEARCH RETURN (SAVE) $
>
> It's possible to use $ in the same search query that updates it, so the above search should preserve $. My code cleared $ before running the search, so the result was that $ was cleared.
Right. So "SEARCH RETURN (SAVE) $ " does nothing to the $ value.
> 2) The RFC text says:
>
>     Upon successful completion of a SELECT or an EXAMINE command (after
>     the tagged OK response), the current search result variable is reset
>     to the empty sequence.
>
> So I was going to test that $ is preserved if SEARCH/EXAMINE fails. Except selecting nonexistent mailbox closes the current mailbox. So then I thought testing with invalid SELECT options, like SELECT INBOX (blah) which returns BAD. But my current code still closes the current mailbox, and I don't see anything in RFCs whether this should or shouldn't happen. I suppose it's safer that the mailbox is still closed? So that means it's a bit strange/unnecessary to specify "tagged OK response" in the RFC text.
Let me think about this, need more coffee :-).
> 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.

> SEARCH RETURN (SAVE MIN UPDATE) 1:100
>
> I suppose UPDATE should be ignored here and $ is 1. RFC 5267 does say pretty clearly "There is no interaction between UPDATE and any other return options"
Agreed.
> 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.

Best Regards,

Alexey