TLS Presentation Language is sometimes non-obvious

[mirjak]

Sec 6.6.3 of the transport draft says:
"An endpoint MUST ignore transport parameters that it does not support."

However, the length of the parameter value is implicitly defined by the parameter type. If the parameter type is unknown, the length if unknown is well. Without knowing the length one cannot jump to the next value. What do i miss?

To be honest I also don't find it very intuitively to use the TLS presentation language here as it just introduced a "dependency" on TLS. However, for TLS this is only an additional data blob that is does not need to understand. Therefore I would prefer to "just" use some TLV encoding here.

[MikeBishop]

What you missed is that the TLS presentation language makes length prefixes implicit. The generic definition for a TransportParameter is:

   struct {
      TransportParameterId parameter;
      opaque value<0..2^16-1>;
   } TransportParameter;

That means that value is a sequence of bytes with a two-byte length prefix. Everything else defines the content of value for particular values of parameter.

Separately, while I agree that there's a dependency on the TLS document for the definition of the presentation language, there's actually no dependency on TLS libraries for generating this sequence of bytes. It's a convenient notation for a binary structure, just as ABNF is a convenient notation for a text structure. I'm with you that I wish it were a separate informational RFC rather than being a section in a TLS draft, but that's not the province of this WG.

[mirjak]

Ah, right. Now I remember that I looked it up (and then forgot again). Maybe worth explicitly mentioning (instead of "just" point to the TLS RFC).

[martinthomson]

Based on the amount of time that has elapsed, I am going to say that this is cold. If a PR were to manifest, we could consider that, but I'm not inclined to generate that PR.