From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <kyle@kyleam.com>
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-Status: No, score=-3.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS
	shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2
Received: from out2.migadu.com (out2.migadu.com [IPv6:2001:41d0:2:aacc::])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by dcvr.yhbt.net (Postfix) with ESMTPS id 5BA131F9FE
	for <meta@public-inbox.org>; Sat,  6 Mar 2021 18:26:25 +0000 (UTC)
X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kyleam.com; s=key1;
	t=1615055181;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=qW8TghOL4KyqUQpYjj5QEuf8+CQt6ayN8+PZ/NI3+rY=;
	b=FUl5uzXOpXGZw72w22KzsLtph3Gap3pgjBXUrbOwPkj1GE6dDhUZ/MICtj8Eh+UKMHZv2V
	3GDuvhGmQIjnzhEU2EV8yhQzBSF7hV93ComKSMRohnJsot4h49G5EfjMIPLp4HeG4iVqj3
	ki2OcNlD2Noh+5cvBFXv1uPKApjHs1YUzOVG5Bbj8FYmdvNtF46cD5U2hy1ueRXN5HxIiB
	Jjh0El5KeIxwU7aE6od0PV3/OPSLrh7AbwR8kELot0zz4Cww85AdyCanaG595pufeBooBq
	EAbTnD0vWzi1tk3ip6ldkD+8wYkjXjesjIUhDNWk1MktQQzWCAd3dJvFro4dCA==
From: Kyle Meyer <kyle@kyleam.com>
To: Eric Wong <e@80x24.org>
Cc: meta@public-inbox.org
Subject: Re: angle brackets in "m:" and "refs:" in "lei q" JSON
In-Reply-To: <20210304184348.GA19350@dcvr>
References: <20210304184348.GA19350@dcvr>
Date: Sat, 06 Mar 2021 13:26:14 -0500
Message-ID: <87mtvg9m0p.fsf@kyleam.com>
MIME-Version: 1.0
Content-Type: text/plain
X-Migadu-Flow: FLOW_OUT
X-Migadu-Auth-User: kyle@kyleam.com
List-Id: <meta.public-inbox.org>

Eric Wong writes:

> I'm thinking these shouldn't include angle brackets:
>
>   "m": "<20210228122528.18552-2-e@80x24.org>",
>   "refs": ["<20210228122528.18552-1-e@80x24.org>"],
>
> Using angle brackets on the command-line requires quoting to
> disambiguate against redirects, so it's a pain.  Leaving the
> brackets in still works because of how Xapian's query parser
> works, not because of anything we do on our end.

I think it'd be nice to drop the brackets from a noise perspective too.

Also, does m: work with brackets?  Trying it out with a recent message
ID:

  $ lei q -q -I https://public-inbox.org/meta/ -f ldjson \
    '20210304203352.pd5mcg5pw4u2epzl@pengutronix.de'
  {"blob":"87304c8a8cae8ce400443b56309427aeee601505",...}

  $ lei q -q -I https://public-inbox.org/meta/ -f ldjson \
    m:'20210304203352.pd5mcg5pw4u2epzl@pengutronix.de'
  {"blob":"87304c8a8cae8ce400443b56309427aeee601505",...}

  $ lei q -q -I https://public-inbox.org/meta/ -f ldjson \
    '<20210304203352.pd5mcg5pw4u2epzl@pengutronix.de>'
  {"blob":"87304c8a8cae8ce400443b56309427aeee601505",...}

  $ lei q -q -I https://public-inbox.org/meta/ -f ldjson \
    m:'<20210304203352.pd5mcg5pw4u2epzl@pengutronix.de>'
  # no results

> Since the actual headers are "Message-ID" and "References", (and
> not "m" or "refs"), I think it's clear that we don't have to
> match the raw mail contents exactly.  We RFC 2047 decode
> "f|t|c|s" fields anyways instead of showing the raw values,
> so more precedence for leaving out <>.

Fwiw I don't think leaving out the brackets would be a source of
confusion.