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

From: Gunnar Hellström <[email-masked]>
Date: Wed, 28 Jun 2017 21:05:16 +0200

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/

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------------------------------------

Regards
Gunnar

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Randall Gellens <[email-masked]>
Date: Wed, 28 Jun 2017 19:18:55 -0700

At 9:05 PM +0200 6/28/17, Gunnar Hellström wrote:

> <https://datatracker.ietf.org/doc/draft-slevinski-formal-signwriting/>https://datatracker.ietf.org/doc/draft-slevinski-formal-signwriting/
>
>  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.
>
>  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.
>  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------------------------------------
>
>  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.

The draft currently says it is undefined.  This 
is not the same as prohibited.  A future draft 
can extend this one by specifying how it is used. 
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.  If it does 
seem useful in the future, it can be added with 
minimal fuss.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Never doubt that a small group of thoughtful, committed citizens can
change the world.  Indeed, it's the only thing that ever has.
                                                     --Margaret Meed

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 29 Jun 2017 07:49:22 +0200

Den 2017-06-29 kl. 04:18, skrev Randall Gellens:
>>  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 
>>  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.
>>
>>  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.
>>  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.
> 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

---

From: Randall Gellens <[email-masked]>
Date: Thu, 29 Jun 2017 07:23:23 -0700

At 7:49 AM +0200 6/29/17, Gunnar Hellström wrote:

>>>   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
>>>
>>> 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.
>>>
>>>   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.
>>>   the behavior when specifying a 
>>> spoken/written language tag for a video media 
>>> stream, or a signed language tag for an audio 
>>>   --------------new paragraph three from end 
>>> of 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.
>>  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.

I'm suggesting we leave this as "undefined" in the current draft.

>  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.

It depends on the situation.  In the case of 
signed languages in text or audio, leaving this 
as "undefined" in the current draft should make 
it easy to add in the future, since to an old 
implementation, such use is not prohibited, and 
also does not have semantics.  If it is needed in 
the future (which seems unlikely), a new draft 
can specify semantics for it.

-------------- Randomly selected tag: ---------------
I never fail to convince an audience that the best thing they could do
was to go away.