Looking over Section 5.4, it seems to me that the title "Silly States" may not be appropriate, because it mixes discussion of combinations of media and language that have an "undefined" meaning with combinations for which normative guidance can be provided So rather than having a single "Silly States" section, perhaps we can have a section on "Undefined States" (for those combinations which have an undefined meaning) provide normative guidance on defined combinations elsewhere.
5.4. Silly States
It is possible to specify a "silly state" where the language
specified does not make sense for the media type, such as specifying
a signed language for an audio media stream.An offer MUST NOT be created where the language does not make sense for the media type. If such an offer is received, the receiver MAY reject the media, ignore the language specified, or attempt to interpret the intent (e.g., if American Sign Language is specified for an audio media stream, this might be interpreted as a desire to use spoken English). A spoken language tag for a video stream in conjunction with an audio stream with the same language might indicate a request for supplemental video to see the speaker.
[BA] Rather than using terms like "might" for combinations that could have a
defined meaning, I would like to see the specification provide normative
language on these use cases. In particular, I would like the specification to describe:
a. What it means when a spoken language tag is included for a video stream.
Is this to be interpreted as a request for captioning?
b. What it means when a signed language tag is included for an audio stream.
Is the meaning of this "undefined" and if so, should it be ignored?
c. What it means when a signed language tag is included for a text stream.
If some of these scenarios are not defined, the specification can say
"this combination does not have a defined meaning" or something like that.