Re: [Slim] Issue 43: How to know the modality of a language indication?

Bernard Aboba <bernard.aboba@gmail.com> Sun, 15 October 2017 17:49 UTC

Return-Path: <bernard.aboba@gmail.com>
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 9EFD413292A for <slim@ietfa.amsl.com>; Sun, 15 Oct 2017 10:49:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 S8wCV7EBtOkP for <slim@ietfa.amsl.com>; Sun, 15 Oct 2017 10:49:36 -0700 (PDT)
Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56B6F126B71 for <slim@ietf.org>; Sun, 15 Oct 2017 10:49:36 -0700 (PDT)
Received: by mail-ua0-x236.google.com with SMTP id v27so8291833uav.7 for <slim@ietf.org>; Sun, 15 Oct 2017 10:49:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XEAdyRq7wcoynvKg9jUhcIy/5D5295AQ3uCzn7flRkM=; b=ZbvAxK3DMeRcDHQndWww6UUHS56ClbxefChi7pyKNBlbeeyuuoYaVFQc2EOQRl7HEy IoF2CrkUVnQG8p4DprJU/MjgBQ6KLJOvJ+Ta/ZCVDnlpRHqhs+PpE3F2c+ajwnQ3jsi0 e7UGbXMd9ILcpW57v/DGgctjAPD8SJ/+QD79+zoKATMpGD608YW+Q1uBD0GJcTs03OX2 7jipitGH9B0aZODSNjBFOIhZCzqOkdBQUkPMwO/Y5J1Q8dvwPT5+2WnBS9ITuMsVrYko GGHC7D1UHu5HQUdrHRZWt+rhJYQRhY9hFXqN48ave/tHRMknMIqKZB2NtbVYn97iXR21 v2sA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XEAdyRq7wcoynvKg9jUhcIy/5D5295AQ3uCzn7flRkM=; b=QU0npdOjxu+g5PHSFkNg8I8FmqAS2ulqwSsMQ0S4wdSyji0x8E6Yb/8bERqsewAprh y9xPw8hT+ajDiyTiY+Ts3yhGGwb04vPcpcueGNXeYd1okNTSyrHfKxeZx66dxCmelwr5 /um1XM4UWM1WU6vq7rkBPtjcyEFSyB0p9TcsOAFH9LvWNC5tOAQmIGTqjfagvBpHoLIT YytyrtMqIuMIfOqxeJ3OPAtCwIvysT+GRS+BtOMRdo93OpSNdgRx855wVzvinikyuQz4 P51dqUyq+7h4HvIluXhs1BA8ZFoqWqCiUUIXCqyiBOdbIKiw+2Ad+TgUkvw7k3pBrsp8 2cbg==
X-Gm-Message-State: AMCzsaWIRorb3Sqhhx+GOj/yTk+5LsK/09ZAX9ch9VLU24+o6i7M4eSL RlQwqugex5s3VYlLTm37NfZx0FQ1bHb98f5nwqc=
X-Google-Smtp-Source: AOwi7QBQBPh7XL9WYqN5vpnKhlr/9ibNR+MluMbN+DiM22C9qQVsMxlec42QsBxmKV2JZASVSr0fSD8BJ83KquyoDH4=
X-Received: by 10.176.73.72 with SMTP id a8mr5980076uad.65.1508089775129; Sun, 15 Oct 2017 10:49:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.32.76 with HTTP; Sun, 15 Oct 2017 10:49:14 -0700 (PDT)
In-Reply-To: <1b0380ef-b57d-3cc7-c649-5351dc61f878@alum.mit.edu>
References: <CAOW+2dtSOgp3JeiSVAttP+t0ZZ-k3oJK++TS71Xn7sCOzMZNVQ@mail.gmail.com> <p06240606d607257c9584@172.20.60.54> <fb9e6b79-7bdd-9933-e72e-a47bc8c93b58@omnitor.se> <CAOW+2dtteOadptCT=yvfmk01z-+USfE4a7JO1+u_fkTp72ygNA@mail.gmail.com> <da5cfaea-75f8-3fe1-7483-d77042bd9708@alum.mit.edu> <b2611e82-2133-0e77-b72b-ef709b1bba3c@omnitor.se> <1b0380ef-b57d-3cc7-c649-5351dc61f878@alum.mit.edu>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Sun, 15 Oct 2017 10:49:14 -0700
Message-ID: <CAOW+2dtVE5BDmD2qy_g-asXvxntif4fVC8LYO4j7QLQ5Kq2E+g@mail.gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Cc: Gunnar Hellström <gunnar.hellstrom@omnitor.se>, slim@ietf.org
Content-Type: multipart/alternative; boundary="001a11453754560d29055b99832e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/wulQfKTEIthfmmMxC2Anx2vlV-E>
Subject: Re: [Slim] Issue 43: How to know the modality of a language indication?
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: Sun, 15 Oct 2017 17:49:40 -0000

Paul said:

"For the software to know must mean that it will behave differently for a
tag that represents a sign language than for one that represents a spoken
or written language. What is it that it will do differently?"

[BA] In terms of behavior based on the signed/non-signed distinction, in
-17 the only reference appears to be in Section 5.4, stating that certain
combinations are not defined in the document (but that definition of those
combinations was out of scope):

5.4 <https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-17#section-5.4>.
Undefined Combinations

   The behavior when specifying a non-signed language tag for a video
   media stream, or a signed language tag for an audio or text media
   stream, is not defined in this document.

   The problem of knowing which language tags are signed and which are
   not is out of scope of this document.



On Sun, Oct 15, 2017 at 10:13 AM, Paul Kyzivat <pkyzivat@alum.mit.edu>
wrote:

> On 10/15/17 2:24 AM, Gunnar Hellström wrote:
>
>> Paul,
>> Den 2017-10-15 kl. 01:19, skrev Paul Kyzivat:
>>
>>> On 10/14/17 2:03 PM, Bernard Aboba wrote:
>>>
>>>> Gunnar said:
>>>>
>>>> "Applications not implementing such specific notations may use the
>>>> following simple deductions.
>>>>
>>>> - A language tag in audio media is supposed to indicate spoken modality.
>>>>
>>>> [BA] Even a tag with "Sign Language" in the description??
>>>>
>>>> - A language tag in text media is supposed to indicate  written
>>>> modality.
>>>>
>>>> [BA] If the tag has "Sign Language" in the description, can this
>>>> document really say that?
>>>>
>>>> - A language tag in video media is supposed to indicate visual sign
>>>> language modality except for the case when it is supposed to indicate a
>>>> view of a speaking person mentioned in section 5.2 characterized by the
>>>> exact same language tag also appearing in an audio media specification.
>>>>
>>>> [BA] It seems like an over-reach to say that a spoken language tag in
>>>> video media should instead be interpreted as a request for Sign Language.
>>>> If this were done, would it always be clear which Sign Language was
>>>> intended?  And could we really assume that both sides, if negotiating a
>>>> spoken language tag in video media, were really indicating the desire to
>>>> sign?  It seems like this could easily result interoperability failure.
>>>>
>>>
>>> IMO the right way to indicate that two (or more) media streams are
>>> conveying alternative representations of the same language content is by
>>> grouping them with a new grouping attribute. That can tie together an audio
>>> with a video and/or text. A language tag for sign language on the video
>>> stream then clarifies to the recipient that it is sign language. The
>>> grouping attribute by itself can indicate that these streams are conveying
>>> language.
>>>
>> <GH>Yes, and that is proposed in draft-hellstrom-slim-modality-grouping
>> with two kinds of grouping: One kind of grouping to tell that two or more
>> languages in different streams are alternatives with the same content and a
>> priority order is assigned to them to guide the selection of which one to
>> use during the call. The other kind of grouping telling that two or more
>> languages in different streams are desired together with the same language
>> content but different modalities ( such as the use for captioned telephony
>> with the same content provided in both speech and text, or sign language
>> interpretation where you see the interpreter,  or possibly spoken language
>> interpretation with the languages provided in different audio streams ). I
>> hope that that draft can be progressed. I see it as a needed complement to
>> the pure language indications per media.
>>
>
> Oh, sorry. I did read that draft but forgot about it.
>
> The discussion in this thread is more about how an application would
>> easily know that e.g. "ase" is a sign language and "en" is a spoken (or
>> written) language, and also a discussion about what kinds of languages are
>> allowed and indicated by default in each media type. It was not at all
>> about falsely using language tags in the wrong media type as Bernard
>> understood my wording. It was rather a limitation to what modalities are
>> used in each media type and how to know the modality with cases that are
>> not evident, e.g. "application" and "message" media types.
>>
>
> What do you mean by "know"? Is it for the *UA* software to know, or for
> the human user of the UA to know? Presumably a human user that cares will
> understand this if presented with the information in some way. But
> typically this isn't presented to the user.
>
> For the software to know must mean that it will behave differently for a
> tag that represents a sign language than for one that represents a spoken
> or written language. What is it that it will do differently?
>
>         Thanks,
>         Paul
>
>
> Right now we have returned to a very simple rule: we define only use of
>> spoken language in audio media, written language in text media and sign
>> language in video media.
>> We have discussed other use, such as a view of a speaking person in
>> video, text overlay on video, a sign language notation in text media,
>> written language in message media, written language in WebRTC data
>> channels, sign written and spoken in bucket media maybe declared as
>> application media. We do not define these cases. They are just not defined,
>> not forbidden. They may be defined in the future.
>>
>> My proposed wording in section 5.4 got too many misunderstandings so I
>> gave up with it. I think we can live with 5.4 as it is in version -16.
>>
>> Thanks,
>> Gunnar
>>
>>
>>
>>> (IIRC I suggested something along these lines a long time ago.)
>>>
>>>     Thanks,
>>>     Paul
>>>
>>> _______________________________________________
>>> SLIM mailing list
>>> SLIM@ietf.org
>>> https://www.ietf.org/mailman/listinfo/slim
>>>
>>
>>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>