Re: What ASN.1 got right

Tim Bray <> Tue, 02 March 2021 02:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 340373A0CF4 for <>; Mon, 1 Mar 2021 18:40:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PL6SBUEnrMEa for <>; Mon, 1 Mar 2021 18:40:50 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3FA833A0CF1 for <>; Mon, 1 Mar 2021 18:40:50 -0800 (PST)
Received: by with SMTP id 2so17501796ljr.5 for <>; Mon, 01 Mar 2021 18:40:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=itCjfjwkKa+UBC1KA/YeDbARu+lrUciXDCsbFONkJrU=; b=1d/dewUC0p62a1SRNpgmAgzYlPbeZW7HyjS2iE9rVZVBYyrDGp6pVH0mY9gLJASsay zUu6BRnpNQrY3woPkrCPS1ZaiAeOvIyetlO0WV+j3cAm74EbMKhaImUUaaMEqGqSIANW gtC0L4WrEuFZJDEu9iAJMOqDO5ktdm3htS89OIATs+j7HRSoVqnI1dQgQqiTCLb/UfM2 AOO0EZyn/k+EP64CkwY+hJwvinE/JvxiYtdPLCwHRt8cefvgKQydxOjGe5gaB5Lid8b5 WxyEXPG3w0DKRCH2qIS9InN5iVAGuXDHIfNTsX89Xr5+O4AUDyKE1glxwqSfysW6SMOS SjuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=itCjfjwkKa+UBC1KA/YeDbARu+lrUciXDCsbFONkJrU=; b=l/cu0Rv35ABBP0eB1TvRD0JXlVZdZg3jRnJF178rBe2P934HmY7xfPfQmrEtRJAKKW mpsmM2NPRZZfOD/m036A7D/58F4X4bBqLDWh8QKDL3Gx+w/qLxyVIGiFWP100GWNxkbi FwSRiIE96j8yj1i3ZNxRCjTlbikHsxWO2SEDspIKUMBwGyfbl/C/THxgwf1K3rD+dGQF KK7O1icyC4znCrFE79FNtfjQycVlWtsKzt/CgTnI/IHLKiYn6gtTp1kzADUajg9f9f5a nm+4vV8eA8NNkwxHP/B86mGpodx5qgWdfcAF/e3+exHHdxrnLQ4IoqVQ3Erl5vTv4YEF ulog==
X-Gm-Message-State: AOAM530FLnNmA7Wa/MbNuTEEpuAnnT6Vp8qKK4nOhZyFrpYux0saWyUE rvVFVUhCAzPoyRCW17n/mOmJLVIaubao+2k9KvZ6VA==
X-Google-Smtp-Source: ABdhPJzSCaSy0MV3qODB2TI6+Ovdbm7ovxTGcRsxvLY48cWtrV2GnxGTPFviAXKDfWQbcCgEUoDykmEIrWuxX72zcZ4=
X-Received: by 2002:a2e:6c06:: with SMTP id h6mr4447747ljc.154.1614652846617; Mon, 01 Mar 2021 18:40:46 -0800 (PST)
MIME-Version: 1.0
References: <20210302010731.GL30153@localhost> <04f601d70f04$404c5870$c0e50950$> <20210302021731.GM30153@localhost>
In-Reply-To: <20210302021731.GM30153@localhost>
From: Tim Bray <>
Date: Mon, 1 Mar 2021 18:40:35 -0800
Message-ID: <>
Subject: Re: What ASN.1 got right
To: Nico Williams <>
Cc: Larry Masinter <>, IETF-Discussion Discussion <>
Content-Type: multipart/alternative; boundary="0000000000005bc4ec05bc84a9b6"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Mar 2021 02:40:55 -0000

ASN.1 always had data types, and then XML came along, which had no data
types but  a pretty good system for associating names with chunks of data,
and successfully invaded most of ASN.1's space. At which point I concluded
that it's more important to know something's name than its data type.

On Mon, Mar 1, 2021 at 6:18 PM Nico Williams <> wrote:

> On Mon, Mar 01, 2021 at 05:34:55PM -0800, Larry Masinter wrote:
> > JSON-LD seems to fit modern needs from an extensibility / simplicity
> point
> > of view.
> I know nothing about JSON-LD.
> > All the bit-packing goodness of various encodings are dreadful from an
> > interoperability point of view.
> > Rich formalisms and separation of syntax and "encoding rules" seem
> > counter-productive.
> The nicest thing about XML is XSLT/XPath, and the nicest thing about
> JSON is jq.  Such languages are probably only feasible when you have
> loose typing, which XML and JSON do.  And loose typing does arguably
> mean dispensing with the formalisms that force static typing.
> That said, and as much as I love jq, for all the protocols I work on I
> would much rather have static typing and rich formalisms.  Especially in
> security protocols, I'd rather have rich formalisms.
> As always, one should use the right tool for the job.  (FWIW, I used to
> maintain jq and might again, and I maintain an ASN.1 implementation.)
> I don't see how separation of syntax and encoding can be counter-
> productive: alternative syntaxes are always possible, and transcoding is
> generally possible, and people often have to do these things for some
> reason.
> As to "bit-packing"...  have you noticed that every textual encoding
> eventually evolves a binary adaptation?  XML has FastInfoSet.  JSON has
> a multitude of binary encodings (at least three).  Parsing textual
> encodings isn't easy, and much less parsing them efficiently.  Parsing
> dynamically typed data requires more overhead than parsing statically
> typed data.
> Parsing JSON efficiently is really hard.  Parsing anything without a
> schema shifts a lot of burden onto the developer, unless the developer
> is using something like jq.  People have devoted a lot of effort to
> using SIMD to parse JSON more quickly than can be done on a traditional
> CPU, but IIUC there are no online JSON parsers that use SIMD -- no one
> would bother doing this for XDR because there is no need.
> XDR was always simpler to compile or hand-roll codecs for than TLV
> encodings, and definitely than textual encodings.  I've never heard a
> bad thing uttered about XDR.
> It turns out that once you've parsed the syntax into an AST it's pretty
> trivial to generate codecs (possibly bytecoded) regardless of the
> encoding rules' nature.
> XDR being so much simpler than TLV types because of the absence of tags
> and wasteful lengths, was always easy to handle, but what made it easy
> was not having any crutches and so having to have parsed the syntax
> defining the types one needed to encode.  There's a lot of hand-rolled
> XDR out there as well, including some I look after, because it's much
> easier to hand-roll XDR than TLV encodings, and certainly than textual
> ones.
> NDR's pointer dedup feature made it much harder to implement, but
> otherwise it's really similar to XDR.  OER and PER are not too
> dissimilar to XDR, so they're probably comparable to XDR in
> implementaiton complexity.
> Nico
> --