Re: [hackathon] Formal Languages at the Hackathon

"Timothy B. Terriberry" <> Wed, 06 November 2019 20:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF1B41200FE for <>; Wed, 6 Nov 2019 12:46:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9KynyYN3xNw1 for <>; Wed, 6 Nov 2019 12:46:49 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 32041120072 for <>; Wed, 6 Nov 2019 12:46:49 -0800 (PST)
Received: by with SMTP id q26so19802303pfn.11 for <>; Wed, 06 Nov 2019 12:46:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:reply-to:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=9vgebxJlvxDk0ASj7X2uMTXf8DhqIV2kmCh7y3DRJig=; b=bTU2+r+pgeWkRz+PKaUh6ZRWY7arYyXHhzcnG4tJMKxHyP2C70uB7MvOsY25Dsme3r mVUCePDWJgSIAhPb0yO48JxpSkoKuDhIQW0vEj/9jX3ssXFVAh1afDbuNTXTMycpM3rJ kfHWwLcp5jdIv0TRJbBd5NRYj5mS5FSPtG1Lo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:reply-to:subject:to:cc:references :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=9vgebxJlvxDk0ASj7X2uMTXf8DhqIV2kmCh7y3DRJig=; b=cTFAOAWKIM1a4wyfRIAGmPU2/Rm4vQLgV7JinV5LQfXYxE+rKH7i48FJ95W+JskU+w WMOKzLv+tjuhPWbEethsUPZUqbvvU9aeiMbVlipODS2scW7aoTXwiPzTAfl4q8ljWHpp bjGnZFucYVsm7rypCXOjT1Eeq5h6ivajwwgE5CLvwXwC1y/Zt3h9c+K8+pQ7BvceK+Ky NvNovkar+9wGEUgBle6Xl+j/n/3AGcvfjRfUL5MDVvacLSlXnH0jjbE+plaQ3oo7ngxX lWaZLkwr0/qVUVVib34OtiFIJwAwMWppNWD4wTnruwsR32Q8ytwm3Hy43EbGbYOxc5kJ En/g==
X-Gm-Message-State: APjAAAX3e8qOxDt2c9EKbJlXwNmtV80jYYg8mWHPui5FM5mlomNXGWU7 tv+LOvmAb0Z9ZMUIwr7MN9+URpNwCiU=
X-Google-Smtp-Source: APXvYqw9njj9VxnzEj3teu3BykrHhD+qPPo9E99hqaTGto1sXDRns3pbn2xJCcFApY6fylP+boHTaQ==
X-Received: by 2002:a62:ab17:: with SMTP id p23mr5781863pff.116.1573073208651; Wed, 06 Nov 2019 12:46:48 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id x125sm29117400pfb.93.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Nov 2019 12:46:47 -0800 (PST)
From: "Timothy B. Terriberry" <>
X-Google-Original-From: "Timothy B. Terriberry" <>
To: Stephen McQuistin <>,
Cc: Marc Petit-Huguenin <>, Colin Perkins <>
References: <>
Message-ID: <>
Date: Wed, 6 Nov 2019 12:46:45 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 SeaMonkey/
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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 20:46:52 -0000

Stephen McQuistin wrote:
> 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 haven't reviewed the full draft, but one thing that stands out is the 
limitation, "A packet can contain only one unspecified length field, to 
ensure there is no ambiguity" in Section 4.1.

As a counter-example, I offer "code 1 packets" from RFC 6716 Section 

These packets have two fields where the length is determined by the 
total size of the packet, under the restriction that they must be equal.

I didn't see a lot of detail on _how_ "the size of a field is ... 
derived from the value of some previous field", and if there are any 
restrictions on this derivation, but in general for Opus this can be 
somewhat involved, so I am certainly curious about structured text that 
allows for the parsing process to be fully specified.