Code change:
Terminology specific to tree computations is described in ratchet- tree-terminology. <ins> 2.1. </ins> We use the TLS presentation language RFC8446 to describe the <del> structure of protocol messages. </del> <ins> structure of protocol messages.  In addition to the base syntax, we add two additional features, the ability for fields to be optional and the ability for vectors to have variable-size length headers. 2.1.1. An optional value is encoded with a presence-signaling octet, followed by the value itself if present.  When decoding, a presence octet with a value other than 0 or 1 MUST be rejected as malformed. 2.1.2. In the TLS presentation language, vectors are encoded as a sequence of encoded elements prefixed with a length.  The length field has a fixed size set by specifying the minimum and maximum lengths of the encoded sequence of elements. In MLS, there are several vectors whose sizes vary over significant ranges.  So instead of using a fixed-size length field, we use a variable-size length using a variable-length integer encoding based on the one in Section 16 of RFC9000.  (They differ only in that the one here requires a minimum-size encoding.)  Instead of presenting min and max values, the vector description simply includes a "V". For example: Such a vector can represent values with length from 0 bytes to 2^62 bytes.  The variable-length integer encoding reserves the two most significant bits of the first byte to encode the base 2 logarithm of the integer encoding length in bytes.  The integer value is encoded on the remaining bits, in network byte order.  The encoded value MUST use the smallest number of bits required to represent the value. When decoding, values using more bits than necessary MUST be treated as malformed. This means that integers are encoded on 1, 2, 4, or 8 bytes and can encode 6-, 14-, 30-, or 62-bit values respectively. For example, the eight-byte sequence c2 19 7c 5e ff 14 e8 8c (in hexadecimal) decodes to the decimal value 151288809941952652; the four byte sequence 9d 7f 3e 7d decodes to 494878333; the two byte sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37 (as does the two byte sequence 40 25). The following figure adapts the pseudocode provided in RFC9000 to add a check for minimum-length encoding: The use of variable-size integers for vector lengths allows vectors to grow very large, up to 2^62 bytes.  Implementations should take care not to allow vectors to overflow available storage.  To facilitate debugging of potential interoperatbility problems, implementations should provide a clear error when such an overflow condition occurs. </ins> 3.

Related discussion:
text: There are two changes in this PR: Pull the extension to the TLS syntax up into the Terminology section Add an extension that lets vectors have variable-length headers, allowing them to be efficient at small sizes while also accommodating large sizes All vectors are converted to the variable-length header representation. It seems like this should simplify implementation, since the encoder will no longer have to be told how many bytes of header to use for a given vector. This has been the source of several annoying interop bugs.
Looks great! I only have a small objection: there is now several valid ways to serialize a length, as the example shows, both and are valid ways to encode 37. This means that if you parse a structure, and later want to re-serialize it to check a signature for example, you need to remember how many bits were used to store the length. In short, we loose the property that . The fix is easy: can we add that "the length MUST be stored using the smallest amount of bits possible"?
Good point, updated!
I wasn't clear under which circumstances you would use a longer length with a number that would fit in a smaller range. If never, then the table should be:
DIscussion on virtual interim Some concern about being able to send gigantic stuff In adversarial cases, the 4-byte headers used for a lot of stuff might already be a problem Could also have length constraints decoupled from the syntax SIP experience shows that imposing arbitrary length limits isn't a good idea ... but applications should have a way to signal that things are too big TODO(NAME Advisory text "Beware, things can get big; consider imposing limits and clear failure cases for this" Consider streaming implementations, where you might not know that the whole message fits in memory Modulo the above TODO, clear to merge