Re: [fdt] [Webtransport] Standards for protocol headers?

Carsten Bormann <cabo@tzi.org> Tue, 16 June 2020 15:03 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: fdt@ietfa.amsl.com
Delivered-To: fdt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4FD3A16BC for <fdt@ietfa.amsl.com>; Tue, 16 Jun 2020 08:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8B6eS4kHe12y for <fdt@ietfa.amsl.com>; Tue, 16 Jun 2020 08:03:29 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C753A1673 for <fdt@ietf.org>; Tue, 16 Jun 2020 08:03:29 -0700 (PDT)
Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 49mWfl6JSvzyX6; Tue, 16 Jun 2020 17:03:27 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <0b926794-5056-1dfc-645f-f5acde2498a0@acm.org>
Date: Tue, 16 Jun 2020 17:03:27 +0200
Cc: Scott Morgan <scott@adligo.com>, fdt@ietf.org
X-Mao-Original-Outgoing-Id: 614012607.406201-43b1a8a2a7a137cabb6229bc4924c665
Content-Transfer-Encoding: quoted-printable
Message-Id: <1DED87CE-741E-4B59-B144-0C1CA3AE26C9@tzi.org>
References: <CANEdHmhypZE01SHw--UgrpG1yuOU67cKXHv0Jbecyb7sJzYPZA@mail.gmail.com> <2804eb55-e79a-3383-9ebf-cd4f495b273a@petit-huguenin.org> <CANEdHmhPWwO-pO7D_biTQ1_b5oh3xCsdXEi7Urf8sXJQcvVVGw@mail.gmail.com> <ecabce9e-d09f-6ce1-cd17-dea1e793a4cf@acm.org> <CANEdHmiZVdx93Sj1xf6wKPhoBxWGTB9q_WbesJx5FJ26Q0Jzjg@mail.gmail.com> <9796F6C9-ABB9-4AD4-ADA0-A6E275DAE3EE@glasgow.ac.uk> <CAOdDvNoUphx62=a_SOsEfMpxn+Lf7u0yhd0-+s2XBBLwRyVnyA@mail.gmail.com> <CANEdHmgXFUB4B3Taf1hig8kuhxG1vS=SvweDho9mxvQVyvEZyQ@mail.gmail.com> <0b926794-5056-1dfc-645f-f5acde2498a0@acm.org>
To: Marc Petit-Huguenin <petithug@acm.org>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/fdt/itUwNiG-CvCG0zegPUSvVHYsNSw>
Subject: Re: [fdt] [Webtransport] Standards for protocol headers?
X-BeenThere: fdt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mailing list for the discussion of the use of formal description techniques in IETF documents <fdt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/fdt>, <mailto:fdt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/fdt/>
List-Post: <mailto:fdt@ietf.org>
List-Help: <mailto:fdt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fdt>, <mailto:fdt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jun 2020 15:03:33 -0000

On 2020-06-16, at 13:46, Marc Petit-Huguenin <petithug@acm.org> wrote:
> 
> The next logical step in the evolution (or is it devolution?) of XML then JSON is SExp.

Hi Marc,

This is actually a quite profound observation.

We used S-Expressions in the work that led up to RFC 3259, and everything went downhill since then.

The important part of an S-Expression design is, of course, what kind of data goes in there; the nice thing about S-Expressions is that, to a certain extent, you get to design that in a bespoke way for each case, but that also is its downfall as it cannot be standardized.

JSON (or, preferably, CBOR) actually makes nice S-Expressions if you just don’t use those maps (“JSON Objects”); see https://www.ietf.org/id/draft-bormann-cbor-cddl-freezer-04.html#name-alternative-representations for a current example (yes, that is the entirety of CDDL in that figure).  Not being able to separate strings and symbols does hurt, but can be worked around.

Grüße, Carsten