Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)

Gunnar Hellström <> Mon, 13 February 2017 21:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E4ADA12958B for <>; Mon, 13 Feb 2017 13:23:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5R2-RwtdAai3 for <>; Mon, 13 Feb 2017 13:23:42 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 05947129957 for <>; Mon, 13 Feb 2017 13:23:41 -0800 (PST)
X-Halon-ID: aa1a1d32-f232-11e6-a131-005056917a89
Received: from [] (unknown []) by (Halon Mail Gateway) with ESMTPSA; Mon, 13 Feb 2017 22:23:29 +0100 (CET)
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
To: Bernard Aboba <>,,
References: <>
From: Gunnar Hellström <>
Message-ID: <>
Date: Mon, 13 Feb 2017 22:23:36 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------C46E57F1D025166BA2EA8432"
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Feb 2017 21:23:45 -0000


I just issued comments where I also included the "silly states" topic 
with similar views as yours.

Den 2017-02-13 kl. 20:06, skrev Bernard Aboba:
> 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.
See my recent comments for more views. I support the idea to be 
normative and specific when possible.
A complication is that there is no difference between language tags for 
written and spoken language.

So we have the following possible combinations and interpretations of 
"silly states"

1. Spoken/written tag in video media, can mean to see a speaking person, 
or to provide captions overlayed on video.
With some hesitation I suggest to let it mean to see a speaking person. 
The draft adds a requirement to have the same language in the audio 
stream in the same direction to have that interpretation. Should that 
mean that if there is another language in the audio stream, then the 
spoken/written tag in the video stream should mean captions in the 
specified language? That sounds useful for some cases, but complex to 
interpret and unfair to the users who would benefit from captions in the 
same language as in audio.
Summary: I think we had better to use the interpretation to see a 
speaking person regardless of what language is indicated for audio.

2. Signed language tag in audio media, can mean audio from a signing 
person. That could be anything between near silence and spoken words 
corresponding to the signed signs as far as feasible. This is usually 
seen as disturbing to sign language users but it exists, e.g. when one 
erson needs to communicate with both hearing and deaf persons 
simultaneously. There are also variants of signing, called sign 
supported language, with signs expressed with spoken language word order 
and grammar. That can more easily be combined with spoken language, but 
would more likely be indicated by spoken language tag in audio media.
Summary: I am inclined to let signed language tag in audio media mean 
audio from the signing person and possibly used for the rare cases when 
it has some relevance for language communication.

3. Sign language tag in text media. There are some ways to represent 
sign language in various kinds of symbol or text representation. Some 
are represented in Unicode. One is a system called Sign Writing. Some 
fingerspelling methods also have fonts corresponding to characters in 
code pages. There is also an informal way to write manuscripts for 
signing in words with capitals approximately corresponding to signs, 
often with some notation added for unique sign language ways of 
expression that has no direct correspondance to words. None of these 
systems above are common in real-time conversation, but I have seen 
examples of such use.
Summary: I think we can leave freedom here and just specify that a sign 
language tag in text media means some representation of sign language or 
a corresponding fingerspelling system in text media.

If these conclusions are accepted, we can formulate modified text. Note 
that the case with spoken/written language tag in video media is 
mentioned in two places in the draft.


> _______________________________________________
> SLIM mailing list

Gunnar Hellström
+46 708 204 288