I'll voice a friendly disagreement. TLV is a useful disambiguating measure. If your V is of a fixed size and you have (length L array of TV) then it likewise works out that you never need an L inside the array.<p>Another way to look at it is that there are several ways of counting lengths. Some use byte size, some use structure size, some use entry count, and some use delimiting marks. If you unambiguously pick one to rule them all, limitations in document processing start to appear that necessitate translation to one of the other methods.<p>So in practice documents that humans make for themselves tend to add redundancies: we separate sentences with both a period and a space, we describe pages both spatially and with a count. We have separate symbols for the numbers 0 through 9, but we concatenate them to describe larger numbers.<p>Often the difficulty faced with a binary protocol specifically is that you're trying to optimize to more than one task. And you can frame what you're doing when you deserialize either in terms of "prepare a structure of this size, then fill it in with these values", or "execute this series of commands to build a structure". Either one could be contextually more efficient for a certain task: sparsity of data tends to favor the more imperative approach, while densely packed data is likely to benefit from an upfront declaration.
I would say "it depends". There may be cases where depending on the type, the length is 1, 2, or more bytes.<p>"A foolish consistency is the hobgoblin of little minds..." --Ralph Waldo Emerson<p>Which is to say don't decide on 'the one true way' without context, then apply it in all contexts.
When I’ve written TLVs, I’ve never need more than 256 types. So a byte has always been sufficient.<p>I suspect TLV implementations elsewhere have the same or similar design.