Re: [rfc-i] [Rswg] draft-mcquistin-augmented-ascii-diagrams

Carsten Bormann <cabo@tzi.org> Fri, 27 October 2023 16:18 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: rfc-interest@ietfa.amsl.com
Delivered-To: rfc-interest@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A09C151097 for <rfc-interest@ietfa.amsl.com>; Fri, 27 Oct 2023 09:18:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.206
X-Spam-Level:
X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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 eNSRu5iIGgbe for <rfc-interest@ietfa.amsl.com>; Fri, 27 Oct 2023 09:18:55 -0700 (PDT)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [134.102.50.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 564D8C15108F for <rfc-interest@rfc-editor.org>; Fri, 27 Oct 2023 09:18:53 -0700 (PDT)
Received: from eduroam-pool10-182.wlan.uni-bremen.de (eduroam-pool10-182.wlan.uni-bremen.de [134.102.90.181]) (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 4SH7Bz5NYSzDCcJ; Fri, 27 Oct 2023 18:18:51 +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: <75148176-ccf4-4176-5b91-4d1397f619bc@alum.mit.edu>
Date: Fri, 27 Oct 2023 18:18:51 +0200
Cc: rfc-interest@rfc-editor.org
X-Mao-Original-Outgoing-Id: 720116331.326651-9447c1b36da4ee89c0eb4f89b58906a1
Content-Transfer-Encoding: quoted-printable
Message-Id: <1D87F8EF-EC2C-4AF7-89BA-9CD19338A160@tzi.org>
References: <05dff7e7-9744-4ce8-9cc2-98699f7a0c7b@rfc-editor.org> <14700.1698412872@localhost> <75148176-ccf4-4176-5b91-4d1397f619bc@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-interest/8SpBHum6tyfa33MCyRH_pxNmcHQ>
Subject: Re: [rfc-i] [Rswg] draft-mcquistin-augmented-ascii-diagrams
X-BeenThere: rfc-interest@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <rfc-interest.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfc-interest/>
List-Post: <mailto:rfc-interest@rfc-editor.org>
List-Help: <mailto:rfc-interest-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Oct 2023 16:18:57 -0000

On 2023-10-27, at 17:39, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> 
> +1
> This subject needs the broader discussion that comes from a WG.

If we were on the cusp of adopting this method for our future RFCs, I’d agree.  But really, this is research (and rather interesting research, if I may say so).

> Of special note, the principles in section 4 need debate.

Absolutely.  But not in an engineering sense (like a WG would).

> Personally I find the "structured English" problematic. That is part of the needed discussion.

Exactly.

(I myself am mostly interested in a formal definition of the information that is being extracted by the tool behind this. 
I’d probably enter that information in a formal language and have the English generated for people who like it that way — I neither care to write nor to read lengthy English text.
I almost wrote an English language generator for RFC 7071, which has a different formalism written up in English [1] (which now has been replaced in newer specifications by CDDL [2]).)

Grüße, Carsten

[1]: https://www.rfc-editor.org/rfc/rfc7071#section-6.2.2
[2]: https://www.rfc-editor.org/rfc/rfc8610.html#appendix-H