[Cbor] Fwd: [hackathon] Formal Languages at the Hackathon

Carsten Bormann <cabo@tzi.org> Wed, 06 November 2019 17:16 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 304BA120072 for <cbor@ietfa.amsl.com>; Wed, 6 Nov 2019 09:16:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id EEbL79jCJktm for <cbor@ietfa.amsl.com>; Wed, 6 Nov 2019 09:16:24 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61776120071 for <cbor@ietf.org>; Wed, 6 Nov 2019 09:16:24 -0800 (PST)
Received: from [] (p548DC893.dip0.t-ipconnect.de []) (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 477Y9275DSzymQ; Wed, 6 Nov 2019 18:16:22 +0100 (CET)
From: Carsten Bormann <cabo@tzi.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EC89DECC-B784-4A4B-8D8C-C5626E9A46A3"
X-Mao-Original-Outgoing-Id: 594753380.4711601-3d13068ba28b8658cd77faa116286851
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Wed, 6 Nov 2019 18:16:22 +0100
Message-Id: <8C96C2EF-31B5-4ACD-BDFE-11E671BEE06F@tzi.org>
References: <C464EE6D-3DF8-4101-AA26-BD38A61F8E7B@tzi.org>
To: cbor@ietf.org, t2trg@irtf.org
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/ZBKFAbo6wpY1g8C4L1yEDx1st44>
Subject: [Cbor] Fwd: [hackathon] Formal Languages at the Hackathon
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: Wed, 06 Nov 2019 17:16:27 -0000

Interesting discussion at the hackathon mailing list…

BTW, we are thinking about getting together in a corner of the hackathon room with all the people that work on a hackathon project that employs CBOR, so we can have some chatting about cross-pollination and coordination of that side as well.

Grüße, Carsten

> Begin forwarded message:
> From: Carsten Bormann <cabo@tzi.org>;
> Subject: Re: [hackathon] Formal Languages at the Hackathon
> Date: November 6, 2019 at 16:40:11 GMT+1
> To: hackathon@ietf.org
> Cc: Carsten Bormann <cabo@tzi.org>;
> Archived-At: <https://mailarchive.ietf.org/arch/msg/hackathon/Bu-WHQtU-8gZeiX5O16IZ1bFkOw>
> I’m sharing the below with t2trg as it appears to be highly related to some of our current work.
> I’d also like to point out that formal description techniques (FDT) have been used a lot at the IETF and the IRTF:
> * we know very well how to use ABNF (RFC 5234) for our text-based protocols.  We don’t really have a good way to work with multiple layers of ABNF, though; see the difference between RFC 5988 and RFC 8288 for some recent improvements (but the link between the layers is not formal).  ABNF tools exist for both checking ABNF specs and for automatically generating instances (examples).
> * specific areas have had their FDTs, e.g. RFC 4997 for ROHC, YANG for management, etc.  Specifically YANG is increasingly used not only for its original purpose, describing management information bases, but also for data on the wire (yang-data).  YOUPI [1] is an interesting YANG extension for describing arbitrary binary data.
> [1]: https://tools.ietf.org/html/draft-petrov-t2trg-youpi
> * some RFCs were to a large extent machine-generated text (e.g., RFC 7400) or machine-verified (e.g., RFC 8428), based on models in various FDTs.  Some of these are very domain-specific, but we could still be better on sharing tools (and long-term preserving the sources that generated those RFCs).
> * there is a lively discussion about adding (structural) data modeling (a.k.a. “schemas”) to JSON over at the mailing list of the closed JSON WG (e.g., [2]).  While that discussion is ongoing, we already have CDDL (RFC 8610) for structurally modeling CBOR and JSON data.  Maybe one size does not fit all here.  Similar to ABNF, CDDL tools can check specs, verify instances against a spec, extract/generate code snippets from specs, and generate instances/examples from specs.  One next step here is adding links to application semantics.
> [2]: https://tools.ietf.org/html/draft-ucarion-jddf
> * the WISHI activity in T2TRG looks at modeling data shapes, interaction modeling, and potentially adding protocol bindings towards the wire and application semantics towards the application.  Several SDOs are providing interesting study subjects, e.g., W3C WoT with their Thing Description (TD) [3] and the still somewhat stealthy OneDM group with the Simple Definition Format (SDF) [4].  We’ll discuss this on the Friday before the IETF [5] and work on tools for it at the Hackathon (look for “WISHI”).
> [3]: https://www.w3.org/TR/wot-thing-description/
> [4]: https://github.com/one-data-model/language/blob/master/sdf.md
> [5]: https://github.com/t2trg/2019-11-singapore
> (Yes, you can still register.)
> I understand that the “Formal Languages” activity mostly addresses their use in IETF specifications, and I like that angle — there are other uses of formal description techniques that possible have a different set of requirements, which sometimes cause the requirements of spec writers to be forgotten [6].
> [6]: https://www.iab.org/wp-content/IAB-uploads/2016/03/Noise-in-specifications-hurts.pdf
> So I’m really looking forward to the discussions on Friday, November 15th [5] and at the Hackathon.  Getting something going on cross-pollinating and coordinating the various FDT activities at IETF and IRTF might be a good medium term goal.
> Grüße, Carsten
>> On Nov 6, 2019, at 11:09, Stephen McQuistin <sm@smcquistin.uk>; wrote:
>> Hi all,
>> Marc Petit-Huguenin and I are championing formal languages projects at the hackathon in Singapore. Broadly, these
>> projects seek to improve the quality of standards by using formal and structured languages in specification documents.
>> These documents can then be parsed by tooling that can, for example, generate parser code or verify properties for the
>> protocol being specified.
>> There will be two formal languages projects being worked on: Augmented Packet Header Diagrams and Computerate
>> Specifying. Details for both projects are available on the Wiki at https://trac.ietf.org/trac/ietf/meeting/wiki/106hackathon/formal-languages,
>> but I'll give a brief outline of the Augmented Packet Header Diagrams project here. I'll let Marc describe his
>> Computerate Specifying project separately.
>> The Augmented Packet Header Diagram format (draft-mcquistin-augmented-ascii-diagrams) is a consistent packet header
>> diagram format and accompanying structured text constructs that allow for the parsing process of protocol headers to be
>> fully specified. This provides support for the automatic generation of parser code, and for other benefits that follow
>> from being able to use tooling to process packet header diagrams.
>> Our goal at the hackathon is to improve both the Augmented Packet Header Diagram format itself, by attempting to rewrite
>> existing I-Ds and RFCs using its syntax, and to improve the tooling, and in particular, its Rust parser generator.
>> Please join us: we are particularly interested in examples of packet header diagrams that might be challenging to write
>> in the format our draft describes, and in how our tooling might fit into existing workflows.
>> I-D: https://datatracker.ietf.org/doc/draft-mcquistin-augmented-ascii-diagrams
>> Getting started information: https://trac.ietf.org/trac/ietf/meeting/wiki/106hackathon/formal-languages
>> Thanks,
>> Stephen
>> _______________________________________________
>> hackathon mailing list
>> hackathon@ietf.org
>> https://www.ietf.org/mailman/listinfo/hackathon
> _______________________________________________
> hackathon mailing list
> hackathon@ietf.org
> https://www.ietf.org/mailman/listinfo/hackathon