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
<https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-06#section-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.