> here are a few sample serializations (if I haven't screwed up)
>
> 5 => 02 (fixed integer) 01 (length) 05 (value)
> -32767 => 02 (fixed integer) 02 (length) 80 00 (value)
> Some exact hugenum => 02 (fixed integer) 82 (meta-length of 2) 01 00
> (length of 256) xx xx xx ... (256 bytes of big-endian value)
>
> 1.22 => DB (IEEE float) 08 (length) 3F F3 85 1E B8 51 EB 85 (big-endian
> float64)
>
> "abcäöü" => 0C (UTF-8) 09 (length) 61 62 63 C3 A4 C3 B6 C3 BC (UTF-8
> representation)
>
> xyz => DD (symbol) 03 (length) 78 79 7A (value)
>
> (5 1.22 "abcäöü" xyz) => E0 (list) 1D (length of 29) 02 01 05 DB 08  3F F3
> 85 1E B8 51 EB 85 0C 09 61 62 63 C3 A4 C3 B6 C3 Bc DD 03 78 79 7A
>
> #(5 1.22 "abcäöü" xyz) => same, except type code is 30, which is X.690
> standard as opposed to E0 which is in the set of type codes for private
> standards.
>
> Note that a deserializer that doesn't understand symbols (code DD, also a
> private standard code) can safely skip over the 3 bytes of the symbol
> without losing registration with what might come next.

Thanks for taking the time to produce detailed examples. These seem
entirely reasonable to me. In fact, almost identical to the
varint+typetag stuff. The only significant difference is that ASN.1 has
some fixed-length numbers (though prefixed by a byte count).

There's a bit of a chicken-and-egg problem here; I'd have to see a spec
of a simple subset to evaluate it as a whole, but you have no incentive
to produce a spec if you're not sure I'll like it.

> Read this email and tell me what you think.  It's not quite as simple as
> your idea, but it does play nicely with other people, up to the limit of
> their understanding, and they always know what they do not understand (see
> below) and can't be confused by it, not only at the level of objects, but
> at the level of parts of objects.

That is a nice property to have. I'll have to think about it some more.

>> Crucially, those binary S-expressions are also easy to use from C (well,
>> as easy as any hierarchical dynamically-typed structure can be).
>
> I think these are too

The above examples definitely are easy enough.

> Not core at all.  OIDs are a way of assigning vectors of numbers to things
> or concepts in such a way that when lexicographically sorted they are
> grouped administratively, which is useful for the purposes ASN.1 is
> normally used for, but they are just another datatype.
>
> (You can get your very own official OID by going to <
> https://oidplus.viathinksoft.com/oidplus/?goto=oid%3A1.3.6.1.4.1.37476.9000>
> and asking for one at no charge

Nice. Is there any way to use DNS names as identifiers within ASN.1?

> The maximum safe value to use as an OID component is 2^32-1, so plain
> vectors or s16vectors would be the Right Thing.

You mean s32vectors?

> As shown above, all types are prefixed with their length in bytes
> (excluding the type and length itself), and for those types with
> components, each component is prefixed with its length in bytes.  There are
> plenty of codes we can register and plenty of purely private-use codes, as
> noted in one of my other postings.

This is all good stuff.