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

[Randall Gellens <[e-mail]>]

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

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

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

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

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.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I never fail to convince an audience that the best thing they could do
was to go away.