[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
- [Extra] IMAP4rev2 , \recent and search new Arnt Gulbrandsen
- Re: [Extra] IMAP4rev2 , \recent and search new Brandon Long
- Re: [Extra] IMAP4rev2 , \recent and search new Arnt Gulbrandsen
- Re: [Extra] IMAP4rev2 , \recent and search new Bron Gondwana
- Re: [Extra] IMAP4rev2 , \recent and search new Alexey Melnikov
- Re: [Extra] IMAP4rev2 , \recent and search new Bron Gondwana
- Re: [Extra] IMAP4rev2 , \recent and search new Arnt Gulbrandsen
- Re: [Extra] IMAP4rev2 , \recent and search new Bron Gondwana