Re: [Cbor] cddl 0.8.17: Add .abnf (draft-ietf-cbor-cddl-control)

Carsten Bormann <cabo@tzi.org> Sat, 27 February 2021 13:36 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 BC21F3A18A4 for <cbor@ietfa.amsl.com>; Sat, 27 Feb 2021 05:36:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 XTy6nbZcYUB2 for <cbor@ietfa.amsl.com>; Sat, 27 Feb 2021 05:36:57 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA3283A18A3 for <cbor@ietf.org>; Sat, 27 Feb 2021 05:36:55 -0800 (PST)
Received: from [192.168.217.123] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Dnncj1SWwz105b; Sat, 27 Feb 2021 14:36:53 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <8B7422CF-6DE1-4ACB-B6A8-BE0B466BB072@tzi.org>
Date: Sat, 27 Feb 2021 14:36:52 +0100
Cc: cbor@ietf.org
X-Mao-Original-Outgoing-Id: 636125810.735979-00c672efc6d2f2d7c03eb6e1cf18ebb2
Content-Transfer-Encoding: quoted-printable
Message-Id: <DDB153F6-B2AA-4D12-BB1C-9C2D90AD6DA3@tzi.org>
References: <AC771EE9-9672-4B2D-B66A-2C815D102687@tzi.org> <358dd1e3-74a5-c32e-235a-c0a6c308ae6f@alum.mit.edu> <CD82E5A7-4D46-412F-B45F-B4970C2FF8E8@tzi.org> <3a80f922-cfc9-2831-c4f0-7c918e211d74@alum.mit.edu> <8B7422CF-6DE1-4ACB-B6A8-BE0B466BB072@tzi.org>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/e3Llf6Fm8JsctR-u7oDkW5d4YbA>
Subject: Re: [Cbor] cddl 0.8.17: Add .abnf (draft-ietf-cbor-cddl-control)
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: Sat, 27 Feb 2021 13:37:00 -0000

So RFC 5234 has this indentation problem:

oid = bytes .abnfb ("oid" .cat cbor-tags-oid)

cbor-tags-oid = '
  oid = 1*arc
  roid = *arc
  arc = [nlsb] %x00-7f
  nlsb = %x81-ff *%x80-ff
'

…does not work, as the ABNF is indented, which is not allowed by RFC 5234.
Outdenting the ABNF works, but reduces readability (it also is too easy to confuse  ABNF with CDDL rules!).

So how do we make something like the above work?

(1) We could fix ABNF.  This is an Internet Standard, so I’d expect this to be a slow process; we want to be done with the new controls earlier than that.
(2) We could make CDDL work with ABNF as is, but still allow something like the above.

Now how can we do (2):

(2a) We define .abnf/.abnfb to ignore leading whitespace.  This requires some elaborate rules like the ones bap uses (see previous mail).  The main problem with this is that if the ABNF is concatenated together from different sources, these must agree on the amount of leading whitespace for this to work.  And this is rather likely as 5234 and other places define “libraries” that need to combined with ABNF from protocol spec RFCs.

(2b) We leave .abnf/.abnfb as is, and define an outdenting version of .cat.
Let’s call that .bat for the moment.

Fix the above example:
oid = bytes .abnfb ("oid" .bat cbor-tags-oid)
Done.

More precisely, .bat takes its controller (right hand side argument), computes the indent (leading whitespace of least-indented non-blank line), and reduces the amount of leading whitespace on each line by the indent.

This is only done on the right hand side as it fits the most common use cases.  It also allows keeping some leading whitespace for the target (left hand side argument).  If really both sides need to be outdented, use something like

ant<v1, v2> = ("" .bat v1) .bat v2

As the outdenting is done before concatenation, .bat has no problems dealing with pieces that are indented by different amounts.

I have little problem with introducing this control operator, as there are features in other languages that have similar outdenting semantics, e.g., <<~ in Ruby.

CDDL tool 0.8.20 has .bat, if you want to play with that.

The retronym generation process for .bat is now officially started (or maybe you have a different name for this that also is short and to the point; .cat-with-undenting-of-right-hand-side is not it).

Grüße, Carsten