Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language

Gunnar Hellström <> Sat, 18 November 2017 22:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6ECA1126579 for <>; Sat, 18 Nov 2017 14:33:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d67nea0sqJJn for <>; Sat, 18 Nov 2017 14:33:27 -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 DCE051200F3 for <>; Sat, 18 Nov 2017 14:33:26 -0800 (PST)
X-Halon-ID: 72de605f-ccb0-11e7-96ac-005056917f90
Received: from [] (unknown []) by (Halon) with ESMTPSA id 72de605f-ccb0-11e7-96ac-005056917f90; Sat, 18 Nov 2017 23:33:07 +0100 (CET)
To: Bernard Aboba <>,
References: <>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <>
Message-ID: <>
Date: Sat, 18 Nov 2017 23:33:11 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------C4002CE67E9F13948F009B01"
Content-Language: en-US
Archived-At: <>
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Selection of Language for Internet Media <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 18 Nov 2017 22:33:29 -0000

Thanks Bernard for pushing for closing the last open issue.
Den 2017-11-18 kl. 19:46, skrev Bernard Aboba:
> At this point, only a single Issue (43) remains open on 
> draft-ietf-slim-negotiating-human-language::
> This relates to the modality of a language indication.
> Currently, Gunnar has suggested a modification to the text of Section 
> 5.4 in order to address the issue:
> Can WG participants review this suggested change, so that we can 
> determine how to move forward?
> Currently, Section 5.4 states that:
>     The problem of knowing which language tags are signed and which are
>     not is out of scope of this document.
I earlier thought that an application needed to look into the language 
subtag Description to find the word "sign" there in the text string. 
That is not a good solution. But when studying the topic again in RFC 
5646 I found that there is a consistent machine-implementable way to 
assess if a language subtag is for a sign language.
Therefore I included this text in the latest proposal for section 5.4 at 
the link that Bernard provided:


A specific sign language can be identified by its existence in the IANA
registry of language subtags according to BCP 47 [RFC5646] , and finding
that the language subtag is found at least in two entries in the
registry, once with the Type field "language" and once with the Type
field "extlang" combined with the Prefix field value "sgn".


So that should be the response on Dales request to easily decide if a 
language tag is for a sign language.

Worse is next topic in issue 43: to assess if a language tag is for a 
spoken modality or written modality of a language.
My wording proposal starts with the obvious cases: a non-signed languge 
tag in audio media is spoken, and a non-signed language tag in text 
media is written.  But for other cases, like in video or message or 
application or multiplexed media, other indications must be used to 
understand the intended modality. The proposed text mentions a few, and 
leaves to applications to decide which mechanisms to use for such cases. 
I wish we for the ambiguous cases could use the script subtag -zxxx to 
indicate spoken modality and a real script subtag even on language 
subtags where script subtags are suppressed, because that would satisfy 
issue 43 nicely and make section 5.4 much shorter and clearer. But we 
have had resistance against that solution.

The proposed text might be a bit long and detailed. I am prepared to 
agree on a shortened version if there are any proposals. I think though 
that contents of 5.4 in the direction of my proposal is what satisfies  
issue 43 and also the comments lately that section 5.4 is too restrictive.


> _______________________________________________
> SLIM mailing list

Gunnar Hellström
+46 708 204 288