Re: [Extra] Barry Leiba's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT)

Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> Sun, 02 June 2019 19:23 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 0C61612008F for <extra@ietfa.amsl.com>; Sun, 2 Jun 2019 12:23:45 -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 01I2RP-Eo2Zo for <extra@ietfa.amsl.com>; Sun, 2 Jun 2019 12:23:43 -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 16A7B120074 for <extra@ietf.org>; Sun, 2 Jun 2019 12:23:42 -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 0C2FCC0546; Sun, 2 Jun 2019 20:26:15 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1559503575; bh=tKS2gdRMiilBeH36069g7MSJHATkUFBXihukVaBm5pA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=qgwfZ8WAlHBDbzCKMway1wkzdpY62mMbeMTckj2knt8nXmcHtm5VH3Aw/iEJn2aNE 8jrfyCEmBxnP8+ePMBzZ0iT12gx4vLPNRc2f6hJ1lEaw2TvJz8sAfoNrh/98ZvGV6b jAvAbVcaXUCnboIA65xGEIGPvwKP/yzE1dMTOuEQ=
Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1559503574-19664-2661/9/5; Sun, 2 Jun 2019 19:26:14 +0000
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: extra@ietf.org
Date: Sun, 02 Jun 2019 21:23:40 +0200
Mime-Version: 1.0
Message-Id: <91fde3a6-1f27-4848-924d-49d36d9413be@gulbrandsen.priv.no>
In-Reply-To: <CALaySJK+vvD-piU53RDRhrzG6Ei0+nZnm6b_=KpqK=DBOA59YA@mail.gmail.com>
References: <155469393077.18315.15660535375707491655.idtracker@ietfa.amsl.com> <1478535427.18024.1554953503900@appsuite.open-xchange.com> <CALaySJKJxBTw6ptgDNvDjaXKDA4_ZFrb5b2gcUbSqsv1zwZSJw@mail.gmail.com> <1755746109.39421.1559403977713@appsuite-gw1.open-xchange.com> <CALaySJK+vvD-piU53RDRhrzG6Ei0+nZnm6b_=KpqK=DBOA59YA@mail.gmail.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/3SYPzuACADcrpCpIpB5aewOm4nM>
Subject: Re: [Extra] Barry Leiba's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT)
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: Sun, 02 Jun 2019 19:23:45 -0000

On Sunday 2 June 2019 19:33:17 CEST, Barry Leiba wrote:
> I think we're still in significant disagreement here; I'd like others
> from the working group to comment, and see if that can move us in one
> direction or the other.

My two cents, then: Michael is right.

The correct wording, from my point of view, should specify the desired 
results in one or a few typical cases, suggest that implementations should 
do much the same in less common cases. Ideally it also contains an appendix 
might with some common/uncommon test messages _without_ specific results.

My reason for this is that  exact rules along the lines of e.g. 
THREAD=REFERENCES haven't been fortunate, while RFCs like FUZZY with more 
goal and less mechanism haven't led to complaints or calls for revision.

Some servers have the knowledge to thread better (e.g. because they had 
language-specific ways to compute BASESUBJECT, or could thread based on 
information from Exch^Wnon-822 mail systems) but T=R banned that. On the 
other hand, FUZZY has let implementers use their platform's abilities, and 
I haven't noticed interop problems caused by that.

Michael mentioned all-image HTML as an example. One of the platforms I know 
comes with OCR support, the others don't AFAICT. Now, this platform isn't 
typically a server platform... but I don't see a weighty reason to forbid 
using OCR for PREVIEW if the software has that available.

Arnt