[Extra] IMAP4rev2 , \recent and search new

Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> Mon, 28 October 2019 12:45 UTC

Return-Path: <arnt@gulbrandsen.priv.no>
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 C627912004C for <extra@ietfa.amsl.com>; Mon, 28 Oct 2019 05:45:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 GvkB24w9MxwT for <extra@ietfa.amsl.com>; Mon, 28 Oct 2019 05:45:28 -0700 (PDT)
Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [144.76.73.169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 954CD12000F for <extra@ietf.org>; Mon, 28 Oct 2019 05:45:28 -0700 (PDT)
Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 65EF5C0214; Mon, 28 Oct 2019 12:49:06 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1572266946; bh=bChgZnVHSNf9gfxKnHN/CvcCpE8brD08EVJzw+DPRrc=; h=From:To:Subject:Date:From; b=gCqjVgNnnKqLFqov69exIgBFctRxbFOld0eoYBYcJc5yEvHms2fpiJmA0eZWdO/RW F9IAbJbTNLAqdPn3OzORjtA4EZuBGiKYuontWIKDSiUYoWIWfPniDXa4UnMrdWP74T vuiamRPPh05yNBM7ktBq4YQL5sXkhYh5x4emuqTg=
Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1572266945-27258-27256/9/65; Mon, 28 Oct 2019 12:49:05 +0000
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: extra@ietf.org
Date: Mon, 28 Oct 2019 13:45:24 +0100
Mime-Version: 1.0
Message-Id: <aff50ed2-722b-4dc3-9d23-101db4538220@gulbrandsen.priv.no>
User-Agent: Trojita/0.7; Qt/5.7.1; xcb; Linux; Devuan GNU/Linux 2.0 (ascii)
Content-Type: text/plain; charset=utf-8; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/XNexsUqQRPFPyXCpsjSU5189Wg8>
Subject: [Extra] IMAP4rev2 , \recent and search new
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: Mon, 28 Oct 2019 12:45:31 -0000

I had a look at the draft recently and will be sending a number of 
messages, each pointing out a single issue, mostly simple. I'll space them 
out and send one every few days. First up: search new and \recent.

I suggest that deprecating \recent be given a rationale. I suggest the 
following additional paragraph in 2.3.2:

"Many modern IMAP clients automatically reconnect. For example, mobile 
email clients may dis- and reconnect whenever they enter or leave an area 
with WLAN coverage. Because of this, messages can lose their \recent status 
apparently at random, and using \recent (e.g. via the NEW search key) has 
become unreliable. For this reason (among others), \recent is now 
deprecated."

The NEW search key needs to be changed, either to deprecate it or to make 
it an alias for UNSEEN. I think the best course of action is the one that 
permits the smallest client diff. Suggested wording for section 6.4.4:

"Since \recent is now deprecated, the NEW search key may now be an alias 
for the UNSEEN. Servers that also advertise IMAP4rev1 may implement NEW 
either as an alias for UNSEEN or as specified in IMAP4rev1. Clients that 
implement IMAP4rev2 should not rely on either NEW being equal to UNSEEN or 
NEW returning a subset of UNSEEN."

Section 6.3.2 contains an example that doesn't include RECENT. I suggest an 
additional paragraph:

"Note that IMAP4rev1 compliant servers also send e.g. "* 0 RECENT", which 
IMAP4rev2 clients are advised to ignore."

Arnt