Re: [Cbor] eliding CBOR diagnostic notation binary contents
Carsten Bormann <cabo@tzi.org> Mon, 14 March 2022 10:27 UTC
Return-Path: <cabo@tzi.org>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 716723A09FB
for <cbor@ietfa.amsl.com>; Mon, 14 Mar 2022 03:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01,
URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 vH4c58GNsA0R for <cbor@ietfa.amsl.com>;
Mon, 14 Mar 2022 03:27:21 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de
[IPv6:2001:638:708:32::15])
(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 1695E3A0780
for <cbor@ietf.org>; Mon, 14 Mar 2022 03:27:18 -0700 (PDT)
Received: from [192.168.217.118] (p5089ad4f.dip0.t-ipconnect.de
[80.137.173.79])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4KHCQV2xY1zDCbj;
Mon, 14 Mar 2022 11:27:14 +0100 (CET)
Content-Type: multipart/signed;
boundary="Apple-Mail=_778B9CB3-43A4-436F-998D-EA1E5DC09159";
protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <26078.1647206969@localhost>
Date: Mon, 14 Mar 2022 11:27:14 +0100
Cc: =?utf-8?Q?Christian_Ams=C3=BCss?= <christian@amsuess.com>,
cbor@ietf.org
X-Mao-Original-Outgoing-Id: 668946433.3678221-4c0fb2d5e0f1fe113d24b7a04b89a3b6
Content-Transfer-Encoding: quoted-printable
Message-Id: <980C5C89-A934-4AA5-B234-037057C004C9@tzi.org>
References: <289545.1643998363@dooku>
<982B35D9-8541-4AB6-88DE-55018DB5BB6B@tzi.org> <27168.1644006597@localhost>
<D6BA4596-C08F-4CDF-AEB4-20C264D3BB34@tzi.org>
<YgO2eOiH5gMdwSGd@hephaistos.amsuess.com>
<13A46D26-E131-42C8-B325-C57857246699@tzi.org>
<YhY8jT6/APLawwBF@hephaistos.amsuess.com> <9709.1645661896@localhost>
<83575A66-894D-4013-9E89-AA3E0DB4641B@tzi.org> <30798.1645665697@localhost>
<5FA0EAE5-2E02-4968-847D-8F516C2FCC65@tzi.org> <26078.1647206969@localhost>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/ipjUiN8NoA6wo6SiCvMEw2FHT_I>
Subject: Re: [Cbor] eliding CBOR diagnostic notation binary contents
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>,
<mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>,
<mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Mar 2022 10:27:27 -0000
> On 2022-03-13, at 22:29, Michael Richardson <mcr+ietf@sandelman.ca> wrote: > > Signed PGP part > > Carsten Bormann <cabo@tzi.org> wrote: >>>> Actually processing elisions should be a special flag. That should >>>> address your concern. >>> >>> Yes, that works for me. > >> In cbor-diagnostic, this flag is now “-ah”. > > Cool. > >> $ gem install cbor-elision > >> $ echo "h'...4711...'" | diag2pretty.rb -ah > > The direction I really want to automate is cbor2pretty, when generating examples. Are you sure about cbor2pretty (annotated hexdump) vs. cbor2diag? A hexdump is much harder to have elisions that you can read in again: The length information implicitly conveyed by the syntactic structure of diagnostic mode is missing. So you don’t know how many bytes the elision is supposed to cover. (Unless you start parsing the annotations…) > There are some ways in which I can see doing this: > 1) some option which just elides any bstr longer than X. > 2) some option which elides based upon some other (content-relevant) tag. > 3) some option which takes some kind of CBOR-PATH to specify what to elide. > > I think that "CBOR-PATH" is not yet a thing, but I think I've heard you talk > about how we can essentially use JSONPATH to do this? Also, it might be useful to mix in a CDDL spec and build a path based on the parse tree. CBOR-Path should be able to handle all of these, but it still needs to be invented (after JSONPath is done, presumably). Grüße, Carsten
- [Cbor] eliding CBOR diagnostic notation binary co… Michael Richardson
- Re: [Cbor] eliding CBOR diagnostic notation binar… Carsten Bormann
- Re: [Cbor] eliding CBOR diagnostic notation binar… Michael Richardson
- Re: [Cbor] eliding CBOR diagnostic notation binar… Carsten Bormann
- Re: [Cbor] eliding CBOR diagnostic notation binar… Christian Amsüss
- Re: [Cbor] eliding CBOR diagnostic notation binar… Carsten Bormann
- Re: [Cbor] eliding CBOR diagnostic notation binar… Christian Amsüss
- Re: [Cbor] eliding CBOR diagnostic notation binar… Michael Richardson
- Re: [Cbor] eliding CBOR diagnostic notation binar… Carsten Bormann
- Re: [Cbor] eliding CBOR diagnostic notation binar… Michael Richardson
- Re: [Cbor] eliding CBOR diagnostic notation binar… Carsten Bormann
- Re: [Cbor] eliding CBOR diagnostic notation binar… Michael Richardson
- Re: [Cbor] eliding CBOR diagnostic notation binar… Carsten Bormann
- Re: [Cbor] eliding CBOR diagnostic notation binar… Michael Richardson