Re: [hackathon] Formal Languages at the Hackathon

Carsten Bormann <> Wed, 06 November 2019 17:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B46D120875; Wed, 6 Nov 2019 09:12:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tU9mzR50_O8x; Wed, 6 Nov 2019 09:12:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 94E57120860; Wed, 6 Nov 2019 09:12:39 -0800 (PST)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 477Y4j4pvGzyWt; Wed, 6 Nov 2019 18:12:37 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Wed, 6 Nov 2019 18:12:37 +0100
Cc: Deborah Brungard <>, Alvaro Retana <>,,
X-Mao-Original-Outgoing-Id: 594753155.580314-500b73e88c3ba69976f774d2d4016f76
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: "" <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [hackathon] Formal Languages at the Hackathon
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion regarding past, present, and future IETF hackathons." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Nov 2019 17:12:42 -0000

On Nov 6, 2019, at 17:52, Antoni Przygienda <> wrote:
> enhance GRPC or thrift

There are several of these integrated modeling language + encoding scheme ecosystems we could latch ourselves up to.  Actually we did that already with ASN.1 a long time ago, and it is interesting what people who have used it for a few decades now think about it (*).

Obviously there are some requirements for data modeling (mostly around handling evolution) that are better served by using a mature FDT approach than by graphical representation of various encoding stages (the “box notation” we love from RFC79x etc.).  

When the encoding dominates your thinking, they get in the way (e.g., look at how HTTP/2 is encoded).  So being able to describe an arbitrary bespoke encoding with an FDT (like Quentin’s work or YOUPI do, within the limits of their expressibility) may be useful in those spaces.

When the complexity of the data being modeled dominates your thinking, you want a solid encoding scheme such as XML or JSON or CBOR (or you can do the latch-up alluded to above).
For standards that are expected to live for a while (“design for decades”), I prefer situations where the encoding scheme has a life of its own, independent of the FDT, so you can swap your FDT if the old one is broken (just as we moved from W3C XSD to Relax-NG for most XML work).  The integrated approaches may have their own advantages, especially in the time-to-market department, while usually wedding you to a specific toolchain (or tool ecosystem, as with ASN.1).

Grüße, Carsten

(*) Especially after you compensate for the inevitable occurrence of Stockholm syndrome.