Re: [Slim] Sign language in the text stream is a valid combination for real-time communication

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Thu, 29 June 2017 05:49 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED485127867 for <slim@ietfa.amsl.com>; Wed, 28 Jun 2017 22:49:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hO4gwSMgB4Q for <slim@ietfa.amsl.com>; Wed, 28 Jun 2017 22:49:29 -0700 (PDT)
Received: from bin-vsp-out-02.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70C9D1275C5 for <slim@ietf.org>; Wed, 28 Jun 2017 22:49:29 -0700 (PDT)
X-Halon-ID: b446fcc8-5c8e-11e7-ba8e-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.36.99]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id b446fcc8-5c8e-11e7-ba8e-005056917f90; Thu, 29 Jun 2017 07:49:24 +0200 (CEST)
To: Randall Gellens <rg+ietf@randy.pensive.org>, "slim@ietf.org" <slim@ietf.org>, Steve Slevinski <slevinski@signwriting.org>
References: <01926268-3210-d48e-66a0-fd34b81edb30@omnitor.se> <p06240610d57a134f029b@[99.111.97.136]>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@omnitor.se>
Message-ID: <cd0df5af-34c3-01c5-816d-870d72ce7350@omnitor.se>
Date: Thu, 29 Jun 2017 07:49:22 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <p06240610d57a134f029b@[99.111.97.136]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/ppql0tolo3SCphsitXa98Ppmc7w>
Subject: Re: [Slim] Sign language in the text stream is a valid combination for real-time communication
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Selection of Language for Internet Media <slim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/slim>, <mailto:slim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/slim/>
List-Post: <mailto:slim@ietf.org>
List-Help: <mailto:slim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/slim>, <mailto:slim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Jun 2017 05:49:32 -0000

Den 2017-06-29 kl. 04:18, skrev Randall Gellens:
> At 9:05 PM +0200 6/28/17, Gunnar Hellström wrote:
>
>>  I just got aware of work with specifying sign language in text media.
>>
>>  It was by recent announcement of a new draft about Signwriting.
>>
>>
>> <https://datatracker.ietf.org/doc/draft-slevinski-formal-signwriting/>https://datatracker.ietf.org/doc/draft-slevinski-formal-signwriting/ 
>>
>>
>>  I suggest that we let this cause a slight change in 
>> draft-ietf-slim-negotiating-human-language
>>
>>  I am copying to the author, Steve Slevinski.
>>
>>  We discussed earlier the unusual combinations of language and media. 
>> I told about Signwriting and other script systems for sign language 
>> in the text stream.
>>  Signwriting in text can be explicitly indicated by combining a 
>> language subtag for the intended sign language with the script subtag 
>> for Signwriting -sgnw ( thus for example ase-sgnw for American sign 
>> language written in text with the Signwriting script). In certain use 
>> the -sgnw may also be assumed and therefore omitted.
>>
>>  It is not at all common to use Signwriting in real-time 
>> conversational mode, but I think it is not good that we exclude it by 
>> a statement in section 5.4
>>
>>  In section 5.4, we say that sign language in written mode is 
>> undefined. With background from what I just found, I suggest that we 
>> at least allow it to be defined. We may also explain how sign 
>> language can be used in the text stream.
>>
>>  Therefore, I suggest this minimal change:
>>  ---------------------------old text 1 in 
>> 5.4-------------------------------------
>>  the behavior when specifying a spoken/written language tag for a 
>> video media stream, or a signed language tag for an audio or text 
>> media stream, is not defined.
>>  --------------------------new text---------------------------------
>>
>>  the behavior when specifying a spoken/written language tag for a 
>> video media stream, or a signed language tag for an audio media 
>> stream, is not defined.
>>  --------------------------end of change 
>> 1------------------------------------
>>
>>  --------------------possible change 2 in 
>> 5.2----------------------------
>>  --------------new paragraph three from end of 
>> 5.2--------------------------------
>>  Sign language in the text stream may occur, e.g. by use of an IANA 
>> registered script for notation of sign language.
>>  Example: ase-sgnw for American Sign Language written with 
>> Signwriting script.
>>  ---------------end of new paragraph in 
>> 5.2------------------------------------
>
> The draft currently says it is undefined.  This is not the same as 
> prohibited.
I see "undefined" as a very strong warning to not use it, and as a 
message to implementers that they do not need to cater for the undefined 
case.
> A future draft can extend this one by specifying how it is used. 
OK, I can accept to not add the explanation in change 2.
> I think it's better to keep this draft as simple as possible, so if we 
> don't expect this to be used, let's not add text about it.
OK, that means that you accept change 1, to delete "text" from the 
sentence in 5.4. Good.
> If it does seem useful in the future, it can be added with minimal fuss.
It is not as easy as you claim to add things in the future. When I 
finally tried to move my request for an indication of modality 
preference from the current draft to an extension, it immediately 
created risks for interop problems between implementations made before 
the extension and the ones using the extension. So, I needed to create a 
totally self-sustained solution. (draft-hellstrom-modality-grouping). We 
also discussed to make the syntax extensible, but found that we just 
added complexity without being sure that we would cover any future 
requests for extensions.

Gunnar

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288