> In that case, I can put the ASN.1 format in three sentences:
>
> 1. First comes the type code of 1 or more bytes.  You have to look at each
> byte to see if there is another byte.
>
> 2. Second comes the length of 1 or more bytes.  You have to look at each
> byte to see if there is another byte.
>
> 3. Next comes the number of bytes specified by the length.

Is the length always the number of bytes? I was under the impression
it's the number of elements in case the value is a list/vector.

> While all that is indisputably true, it's hardly sufficient to do anything
> useful.

The type code in part 1 comes from an enumeration which affects the
format of the bytes in part 3. If part 2 is always the length in bytes,
then you could argue the contents of part 3 are a sub-format, and I
would be sympathetic to that interpretation. In my binary .ini example,
UTF-8 character encoding is a sub-format of the main format.

I like your interpretation of "format". I think it matches what I meant.
Precise terminology helps think clearly. Articulating the meaning of
"format" explained vague feelings of unease around specifications that
I've had for years but haven't been able to pin down why until now.