Re: [Slim] Issue 41: Allow sign languages in the text stream for text notations of sign language

[Gunnar Hellström <[e-mail]>]

Den 2017-10-14 kl. 07:42, skrev Randall Gellens:
> At 1:22 PM -0700 10/13/17, Bernard Aboba wrote:
>
>>  Issue 41 (see: 
>> <https://trac.ietf.org/trac/slim/ticket/41>https://trac.ietf.org/trac/slim/ticket/41 
>> ) relates to the potential future use of sign language within a text 
>> stream, such as Formal Signwriting, described here:
>>
>> <https://tools.ietf.org/html/draft-slevinski-formal-signwriting>https://tools.ietf.org/html/draft-slevinski-formal-signwriting 
>>
>>
>>  In the Issue, the following change is suggested:
>>
>>  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---------------------------
>>
>>  Since draft-slevinski has not been widely implemented, it probably 
>> cannot be assumed that negotiation of a signed language tag for a 
>> text media stream implies use of this (or any other) sign language 
>> textual encoding mechanism.  So it would not be correct to imply that 
>> use of a signed language tag for an text media stream has a well 
>> defined meaning.
>>
>>  One way to resolve this would be to keep the existing text but add a 
>> sentence, such as:
>>
>>  "Note that mechanisms for encoding signed language in a text media 
>> stream have been proposed
>>  [draft-slevinski] but are not yet well developed enough for 
>> incorporation within the negotiation mechanism described in this 
>> document."
>>
>>  Would such a resolution make sense?
>
> How about simply changing "is not defined" to "is not defined in this 
> document"?
<GH>Yes, "is not defined in this document" as already introduced in 
draft -15 is good and can be accepted. However, see another proposal I 
just made for issue #43, for replacement of the whole section 5.4  that 
is real guidance for implementations. That also solves this issue #41, 
since it allows new specifications to add usage.

/Gunnar



-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[e-mail]
[phone]