At 12:09 AM +0100 2/14/17, Gunnar Hellström wrote:
I prefer that you wait for conclusion on the topic of "silly states".
And I agree with Bernard that we should (and
can) be normative and explicit in how to
interpret all the unusual combinations.
I think we're better off not saying what the
meaning is since we do not have a deployed base
of experience. The replacement text allows
cooperating implementations to send such states
if they wish. If consensus emerges later as to
what such states mean, a revised draft or an
extension draft can be published that spells it
out.
Den 2017-02-13 kl. 23:26, skrev Randall Gellens:
At 11:06 AM -0800 2/13/17, Bernard Aboba wrote:
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.
<https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-06#section-5.4>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.
I will change the section title to "Undefined
Combinations" and replace the text with:
Specifying a non-signed language tag for a video media stream, or a
signed language tag for a non-video media stream, is not defined. An
offer with such a combination SHOULD NOT be created. If such an
offer is received, the receiver MAY ignore the language specified.
I think this retains the intent of the old
section while avoiding wading into the unclear
issue of intent of such combinations.
--
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar(_dot_)hellstrom(_at_)omnitor(_dot_)se
+46 708 204 288
_______________________________________________
SLIM mailing list
SLIM(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/slim
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly selected tag: ---------------
Please take note:
Do not read this fortune under penalty of law.
Violators will be prosecuted.
(Penal Code sec. 2.3.2 (II.a.))