IETF Logo Mail Archive

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

Carsten Bormann <cabo@tzi.org> Fri, 27 October 2023 16:09 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 B4DF9C14CEFE; Fri, 27 Oct 2023 09:09:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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 wTaAgp8Ejsjm; Fri, 27 Oct 2023 09:09:43 -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 RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C334EC151527; Fri, 27 Oct 2023 09:09:40 -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 4SH70L4HVmzDCd4; Fri, 27 Oct 2023 18:09:38 +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: <d52d730c-664d-420c-804e-ea344ac1c89d@petit-huguenin.org>
Date: Fri, 27 Oct 2023 18:09:38 +0200
Cc: Kyle Rose <krose@krose.org>, RFC Interest <rfc-interest@rfc-editor.org>, RSWG <rswg@rfc-editor.org>, "Independent Submissions Editor (Eliot Lear)" <rfc-ise@rfc-editor.org>
X-Mao-Original-Outgoing-Id: 720115778.161081-ca69e45e49dc6ebdd549841da382a67e
Content-Transfer-Encoding: quoted-printable
Message-Id: <49DEB942-283B-4ECA-8CE2-ABE1929F9B3D@tzi.org>
References: <05dff7e7-9744-4ce8-9cc2-98699f7a0c7b@rfc-editor.org> <14700.1698412872@localhost> <CAJU8_nVJvAzjxtPNQpBSdGgDdEsEk_8DjABnGUff+fdL8Crs_A@mail.gmail.com> <23B3F709-8EEE-405C-9101-0228DBB4A969@tzi.org> <d52d730c-664d-420c-804e-ea344ac1c89d@petit-huguenin.org>
To: Marc Petit-Huguenin <marc@petit-huguenin.org>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-interest/hsaZ9toyLJkILZXT11BCEMk5Ysc>
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:09:47 -0000


> On 2023-10-27, at 17:19, Marc Petit-Huguenin <marc@petit-huguenin.org> wrote:
> 
> Signed PGP part
> On 10/27/23 07:52, Carsten Bormann wrote:
>> On 2023-10-27, at 16:35, Kyle Rose <krose@krose.org> wrote:
>>> 
>>> Agree with Michael that this should be in the IETF stream if possible. Seems very cool.
>> 
>> It actually should be in the IRTF stream, under UFMRG.
>> 
> 
> I was preparing an email in support for draft-mcquistin-augmented-ascii-diagrams when I saw that comment.  What I was going to say in that email was that we do not have an RG or WG to work on formal languages, although we do have an RG for formal methods.  

A formal description technique (“formal language”) *is* a formal method.
At least https://www.irtf.org/ufmrg.html uses “formal method” in this way.

> Most formal methods use formal languages, but not all formal languages are used in support of a formal method ("Affirming the consequent" fallacy).  

Well, since they *are* a formal method, it is not clear they always have to support another formal method.
Of course there are other formal methods (the charter says “including formal verification and analysis”), and these may need an even greater push to be adequately used in IETF standards development.

> That's the case for ABNF and its variants, the language discussed in the aforementioned draft, and even RFCXML.  The scope of the charter of UFMRG could be extended, but I do not think that's a good idea as it would dilute the the efforts of that RG[1].

OK, please reread the charter and tell me where I’m wrong.

Grüße, Carsten

v2.23.0 | Report a Bug | By Email