Original text:
Defined structures may have variants based on some knowledge that is available within the environment.  The selector must be an enumerated <del> type that defines the possible variants the structure defines.  There must be a case arm for every element of the enumeration declared in the select.  Case arms have limited fall-through: if two case arms follow in immediate succession with no fields in between, then they both contain the same fields.  Thus, in the example below, "orange" and "banana" both contain V2.  Note that this piece of syntax was added in TLS 1.2 RFC5246.  Each case arm can have one or more fields. The body of the variant structure may be given a label for reference. </del>  The mechanism by which the variant is selected at runtime is not prescribed by the presentation language.

Reviewer comments:
To let's add semi-colons to EarlyDataIndication. To make the presentation language simpler, let's remove fall-through which is not used in other places.
LGTM
One more thing: This is not true anymore. For instance does not cover all handshake types. How can we improve this explanation?
Hi folks. Sorry it took me so long to weigh in, but I'm not really excited about this set of changes. As far as I can tell, the primary impetus for this is the need to specify an empty value for a case. The simplest thing to do here is just to define struct {} Empty; and then put Empty; in the relevant case arms. It's not new syntax, it's just a new type definition. As for fallthrough, IMO it makes things easier to read. I'm happy to remove the requirement to cover all types, because that also makes things easier to read.
I think I had managed to squint enough that I could convince myself that only all values of the enum being used as a selector that are valid in the current context need to be enumerated. So, when talking about, e.g., KeyShare, it's okay to only list case arms for clienthello, helloretryrequest, and serverhello, since other handshake messages would not contain a KeyShare. But, maybe that requires too much squinting.
yeah NAME is right, KeyShare does list all the possible options relevant to KeyShare. But yeah the quote is hard to read. NAME I think it's a matter of what you're most used to read, but I find the PR easier to understand while defining a new struct {} Empty or having the fall through would be cumbersome in my opinion.
NAME I pushed three more commits. I hope that you like these.
I have removed the tag and comment.
NAME I think this PR is ready to be merged.
The current syntax of is broken because case arms must be terminated by . If we respect to TLS 1.2's syntax, I would suggest to change this into:
I think this is more confusing than the . The presentation language is not a formally specified syntax so I don't think it matters. I remember tripping while reading this part of the specs because of the two cases following each other, I would rather replace them by this:
I don't like the comment, I'd rather have a syntactic token there and I don't care what it is.
What about just removing the cases for and ?
Don't care. :) Just don't want comments to be semantically meaningful.
Removing the cases is wrong, as then it leaves unspecified a structure that needs to be sent in a wire protocol message.
is actually used to express empty in RFC 5246. Let's just define its semantics in Section 3. But I recommend most is to define :
Any other opinions on this? Possibilities I see: an field could be defined in the presentation language → but it's more text to the presentation language for few usages the text in the presentation language about cases that must cover all the cases could be relaxed → but now that I think more about it, it's nicer for the implementer to see all the cases in this snippet this could be defined → I don't like it so much, I think a more casual is actually clearer. This makes me thing we should probably drop this issue. PS: or if anyone else was tripped by this double cases (I know it's defined in the presentation language, but it's weird to see it since there are no breaks) we could also use this:
How about this? P.S. Fall through is not used in other parts.
It looks good to me, also if fall through is not used anywhere else it could be removed from the presentation language section.
"Fall-through" was added in TLS 1.2. We can copy-and-pase Section 4.6.1 of RFC 4346 to remove fall-through. If this is consensus, I will make a PR.
I've sent PR .

Revised text:
Defined structures may have variants based on some knowledge that is available within the environment.  The selector must be an enumerated  <ins> type that defines the possible variants the structure defines.  The body of the variant structure may be given a label for reference. </ins> The mechanism by which the variant is selected at runtime is not prescribed by the presentation language.