IETF Logo Mail Archive

Re: [Extra] IMAP4rev2 , \recent and search new

Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> Tue, 29 October 2019 12:14 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 D5E0D120154 for <extra@ietfa.amsl.com>; Tue, 29 Oct 2019 05:14:48 -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 eg4iLlUoX5Lk for <extra@ietfa.amsl.com>; Tue, 29 Oct 2019 05:14:47 -0700 (PDT)
Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 554A8120106 for <extra@ietf.org>; Tue, 29 Oct 2019 05:14:47 -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 55975C0074; Tue, 29 Oct 2019 12:18:25 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1572351505; bh=vbFh1cYg07JLwnZY/WiDH5VHT0mqvwrDBTFcfe2ucnc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=lkzsEJPl6lCAUOis8k0HMV2f8r085IUjihUTPixXXriz7HglAh+QvUm3vtSHPZkgz qpCRO3M52EwppZ4PMXBbvDooFcueJkdOG/ShgEL3KFMvrZ6M6Xm8tNk1JOrueu0MEG SpWL3G2t4AIcB47FW4xm99NG9L2AwRIbw5BH+qgg=
Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1572351504-27259-27256/9/38; Tue, 29 Oct 2019 12:18:24 +0000
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: extra@ietf.org
Date: Tue, 29 Oct 2019 13:14:42 +0100
Mime-Version: 1.0
Message-Id: <6f213c47-03d0-4cea-8cbf-f81156130bcb@gulbrandsen.priv.no>
In-Reply-To: <25e64401-0b91-4387-ba35-1f353aff1bbe@www.fastmail.com>
References: <aff50ed2-722b-4dc3-9d23-101db4538220@gulbrandsen.priv.no> <CABa8R6uDkyD=PO1vAuuuzeELupMwRmvAeT-3OeOtqUW0S6wQ3Q@mail.gmail.com> <d8a1ab07-13cd-4bd3-904b-c456125d0bcb@gulbrandsen.priv.no> <978c88aa-f211-8e74-ae49-6fd6543cbd0d@isode.com> <25e64401-0b91-4387-ba35-1f353aff1bbe@www.fastmail.com>
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/RLK9XrT64lJo6PeyEZGzYm-7Z5U>
Subject: Re: [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: Tue, 29 Oct 2019 12:14:49 -0000

On Tuesday 29 October 2019 12:13:50 CET, Bron Gondwana wrote:
> I think deprecate NEW and allow it to always return empty is 
> right (with the text of course).

Since gmail has done that for a while I think it's a perfectly acceptable 
course of action... and NEW/\recent isn't worth much heartache, so anything 
good is better than a search for best.

Suggested text: "Since \recent is now deprecated, the NEW search key is 
also deprecated. IMAP4rev2-capable servers MAY match no messages (ie. make 
NEW an alias for NONE), servers that also implement IMAP4rev1 MAY 
alternatively choose to implement NEW as specified in RFC3501, and clients 
that implement IMAP4rev2 MUST NOT rely on any particular behaviour."

Arnt

v2.23.0 | Report a Bug | By Email