[Extra] SEARCHRES / IMAP4rev2 clarifications

Timo Sirainen <timo@sirainen.com> Fri, 13 March 2020 10:22 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 752DF3A0911 for <extra@ietfa.amsl.com>; Fri, 13 Mar 2020 03:22:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 W000OZJrGaMt for <extra@ietfa.amsl.com>; Fri, 13 Mar 2020 03:22:56 -0700 (PDT)
Received: from sirainen.com (mail.sirainen.com [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id AD6083A07FA for <extra@ietf.org>; Fri, 13 Mar 2020 03:22:56 -0700 (PDT)
Received: from [192.168.10.104] (unknown [91.155.205.240]) by sirainen.com (Postfix) with ESMTPSA id 22DF22B3C8B for <extra@ietf.org>; Fri, 13 Mar 2020 10:22:55 +0000 (UTC)
From: Timo Sirainen <timo@sirainen.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Message-Id: <741FE532-1213-49E9-901F-46EECB7A223C@sirainen.com>
Date: Fri, 13 Mar 2020 12:22:54 +0200
To: extra@ietf.org
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/eTCheI0hLGD4-_sbvzouQVkTbos>
Subject: [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 10:23:00 -0000

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.

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.

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.

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"

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?