[Cbor] Re: [Tools-discuss] [abnf-discuss] Re: [art] Re: Exploring ABNF extracts from RFCs

Carsten Bormann <cabo@tzi.org> Mon, 29 July 2024 15:51 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 33CAFC169429; Mon, 29 Jul 2024 08:51:28 -0700 (PDT)
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_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_TEMPERROR=0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsYGxDrdQvTA; Mon, 29 Jul 2024 08:51:22 -0700 (PDT)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97234C169416; Mon, 29 Jul 2024 08:51:21 -0700 (PDT)
Received: from [192.168.217.145] (p5dc5d6c5.dip0.t-ipconnect.de [93.197.214.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4WXjWg22wGzDCbG; Mon, 29 Jul 2024 17:51:11 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <d8097d37-e24c-442f-8cb3-e230eb6b9eb5@alum.mit.edu>
Date: Mon, 29 Jul 2024 17:51:10 +0200
X-Mao-Original-Outgoing-Id: 743961070.8558429-30175dcec43964f3461b58e11c772d20
Content-Transfer-Encoding: quoted-printable
Message-Id: <369AD8A1-83FC-4264-B7C5-A57F00AB4977@tzi.org>
References: <89a4a566-8ffe-413e-9196-3f08bebe8d20@w3.org> <99E8B992-AF60-4CD6-9786-2EC180E95E4D@tzi.org> <2867abac-8c62-41b2-a20c-cb9fe8d3736d@alum.mit.edu> <ff29ebe0-efbc-4bfc-8c79-f09ccbe3ffe3@w3.org> <b864092b-477b-4866-a2b1-481313545917@alum.mit.edu> <da4c5ded-24dc-46c8-b011-cea627107f19@gmail.com> <99B795A8-DC51-409A-8395-A0CD5E5C24BF@tzi.org> <5f0ada79-2520-4460-a558-919b40943cdc@gmail.com> <d8097d37-e24c-442f-8cb3-e230eb6b9eb5@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Message-ID-Hash: PJE5PR4EQKLWEWBW5PVDFTH52C366MJE
X-Message-ID-Hash: PJE5PR4EQKLWEWBW5PVDFTH52C366MJE
X-MailFrom: cabo@tzi.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-cbor.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Dave Crocker <dcrocker@gmail.com>, Dominique Hazael-Massieux <dom@w3.org>, art@ietf.org, tools-discuss <tools-discuss@ietf.org>, CBOR <cbor@ietf.org>, abnf-discuss@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Cbor] Re: [Tools-discuss] [abnf-discuss] Re: [art] Re: Exploring ABNF extracts from RFCs
List-Id: "Concise Binary Object Representation (CBOR)" <cbor.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/Fq55yWZ60OuO1PtSCcmh0p9hsFU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Owner: <mailto:cbor-owner@ietf.org>
List-Post: <mailto:cbor@ietf.org>
List-Subscribe: <mailto:cbor-join@ietf.org>
List-Unsubscribe: <mailto:cbor-leave@ietf.org>

On 2024-07-29, at 17:26, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> 
> It would be *nice* if we could find an approach that works for at least the languages most commonly embedded in RFCs.

If you are talking about the approach working when adapted for a number of languages, I’m with you.  But some of the details will need to differ, as we have already seen from the differences in name syntax.

> That seems challenging given the variety of language syntax/semantics. Embedding some parts in comments is interesting, but of course the comment syntax varies.

Right.

The approach described in [1] was designed to be adaptable to ABNF, with some attention to detail — the details will *not* be the same.
ABNF also has more of a dusty deck problem; in the end we’ll probably need to invest some effort to make a reasonable part of the ABNF in RFCs accessible, certainly for weird ABNF such as that used in RFC 2045 or RFC 1421, but also for documents that have more complex extraction than possible with post-8650 RFCs.

Trying to do this in a more general way, e.g., including YANG (which has its own rather elaborate way of handling module references and imports), or ASN.1, won’t make a lot of sense.

Grüße, Carsten

[1]: https://www.ietf.org/archive/id/draft-ietf-cbor-cddl-modules-02.html