Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)

[Randall Gellens <[e-mail]>]

At 10:05 AM -0800 2/14/17, Randy Presuhn wrote:

>  Hi -
>
>  On 2/14/2017 9:40 AM, Randall Gellens wrote:
>>  At 11:01 AM +0100 2/14/17, Gunnar Hellström wrote:
>>
>>>   My proposal for a reworded section 5.4 is:
>>>
>>>   5.4.  Unusual language indications
>>>
>>>   It is possible to specify an unusual indication where the language
>>>   specified may look unexpected for the media type.
>>>
>>>   For such cases the following guidance SHALL be applied for the
>>>  humintlang attributes used in these situations.
>>>
>>>   1.    A view of a speaking person in the video stream SHALL, when it
>>>  has relevance for speech perception, be indicated by a Language-Tag
>>>  for spoken/written language with the "Zxxx" script subtag to indicate
>>>  that the contents is not written.
>>>
>>>   2.    Text captions included in the video stream SHALL be indicated
>>>  by a Language-Tag for spoken/written language.
>>>
>>>   3.    Any approximate representation of sign language or
>>>  fingerspelling in the text media stream SHALL be indicated by a
>>>  Language-Tag for a sign language in text media.
>>>
>>>   4.    When sign language related audio from a person using sign
>>>  language is of importance for language communication, this SHALL be
>>>  indicated by a Language-Tag for a sign language in audio media.
>>
>>  [RG] As I said, I think we should avoid specifying this until we have
>>  deployment experience.
>  ...
>
>  From a process perspective, it's far easier to remove constraints
>  as a specification advances than it is to add them.

Which supports the text I proposed on Monday:

    Specifying a non-signed language tag for a video media stream, or a
    signed language tag for a non-video media stream, is not defined.  An
    offer with such a combination SHOULD NOT be created.  If such an
    offer is received, the receiver MAY ignore the language specified.

This proposed text has a mild constraint to not 
include such combinations.  By using "SHOULD NOT" 
and "MAY" we allow cooperating implementations to 
use it without imposing semantic implications now 
that might not be what we need in the future. 
After we have some experience, we can either use 
the existing attributes and language tags to 
impose meanings as Gunnar suggests, or we might 
find we need a different mechanism that has more 
functionality.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The solution to a problem changes the nature of the problem.