Re: [Slim] Issues #27 and #32 - simultaneous languages

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Sat, 03 June 2017 08:48 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
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 E11B4120724 for <slim@ietfa.amsl.com>; Sat, 3 Jun 2017 01:48:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 RwjQMZ5OVTgI for <slim@ietfa.amsl.com>; Sat, 3 Jun 2017 01:48:32 -0700 (PDT)
Received: from bin-vsp-out-02.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA995120227 for <slim@ietf.org>; Sat, 3 Jun 2017 01:48:31 -0700 (PDT)
X-Halon-ID: 686a5d7e-4839-11e7-bcc7-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Sat, 3 Jun 2017 10:48:25 +0200 (CEST)
To: Randall Gellens <rg+ietf@randy.pensive.org>, "slim@ietf.org" <slim@ietf.org>
References: <60996923-fa37-9926-d1f7-a330020de8db@omnitor.se> <p0624060bd557d18e73b1@[99.111.97.136]>
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
Message-ID: <a7942fd0-bfe4-f456-6863-454affe1d7d8@omnitor.se>
Date: Sat, 03 Jun 2017 10:48:24 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <p0624060bd557d18e73b1@[99.111.97.136]>
Content-Type: multipart/alternative; boundary="------------7EB6C5D93B5F1F4088B790EC"
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/UHDxH6yBBqL6K_Ufdf5NJq7ySKo>
Subject: Re: [Slim] Issues #27 and #32 - simultaneous languages
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: Sat, 03 Jun 2017 08:48:36 -0000

Den 2017-06-03 kl. 04:41, skrev Randall Gellens:
> Hi Gunnar,
>
> You propose an interesting mechanism that I think should be pursued, 
> just not in the current draft. We've repeatedly discussed means of 
> requesting various services, including real-time captioning; these are 
> useful and an automated way of requesting that seems useful, but the 
> group has repeatedly decided to keep the current draft simple.  As 
> with your suggestion for relative preference and priority, I've 
> offered to help write a separate draft, and Brian has offered to 
> review it.  I think this is the way to proceed.
Hi Randall,
Thanks for positive comments.
I suggest that we meet in the middle.
We propose to the WG and our management that:

 1. We make the proposal in the mail below, for simultaneous languages
    as a separate extension draft and by that move the remaining parts
    of tickets #27 and #32 about subtitling etc to that separate extension.

 2. We include in the current draft the functionality for expressing
    preferred modality, as a solution on ticket #26 as expressed in mail
    with subject "New wording for the use of the asterisk in
    draft-ietf-slim-negotiating-human-language"

 3. You may if you want add further wording weakening the requirement to
    obey the indications for preferred modality in the same style as you
    already have for the call denial.

 4. You may if you want call the indication "most suitable modality" or
    "main modality" instead of the "preferred modality" if you feel that
    that has less linkage to the more complex indications and media
    negotiations we have discussed earlier.

In this way, we can rapidly close out all remaining discussions and 
tickets and move on to publication.

We get a way to solve the remaining part of Ticket #26 that required a 
good motivation for placement of the asterisk. The current placement 
rule "in any media" is too fuzzy, while the new wording for use of the 
asterisk adds good motivations for explicit placement. We rather reduce 
complexity than increase complexity. It would also be hard to go from 
placement "in any media" to placement in a specific media by an 
extension. That would cause interop issues. Better to solve it now.

We also satisfy the external expectations we have on our outcome from 
ETSI, 3GPP and a number of NG emergency service projects.

We can reject Ticket #34 about the Accept-Language syntax and go for the 
current one-line syntax.

And we can be satisfied that we do respect the policy rules, e.g. from 
the UN Convention for Rights of Persons with Disabilities( UN CRPD),  
that we cannot say that the current draft does.  I assume that ISOC / 
IETF require us to respect the CRPD as ITU-T and ETSI does in their work.

Agreed?


Gunnar


>
> At 9:28 PM +0200 6/2/17, Gunnar Hellström wrote:
>
>>  For the case that result of decision on Ticket #34 is that we stay 
>> on the current one-line syntax, I want to show how the solution on 
>> tickets #27 and #32 can be expressed regarding how to indicate need 
>> for simultaneous media.
>>
>>  The application is e.g. rapidly added subtitling of audio in the 
>> text stream, or added sign language interpretation of audio in the 
>> video stream.
>>
>>  This would be for simultaneous use, when the user has value also of 
>> the original language in the same direction.
>>
>>  My simple proposal is to use the t language subtag on the extra 
>> provided language. Defined in RFC 6497.
>>
>>  If this addition would go into the current draft, it could be done 
>> with the following modifications.
>>
>>  ---Change 1. ---
>>
>>  In 5.2
>>
>>  ---old text---
>>
>>  Note that [RFC5646] Section 4.1 advises to "tag content wisely" and 
>> not include unnecessary subtags.
>>
>>  ---new text----
>>
>>
>>  Note that [RFC5646] Section 4.1 advises to "tag content wisely" and 
>> not include unnecessary subtags.
>>
>>  An indication of a transformed version of a language provided 
>> simultaneously with the original but in another media, should be 
>> indicated by inserting a 't' extension after the language expected to 
>> be in transformed form. It is therefore of special importance to 
>> consider this possible use of the  't' extension during language 
>> matching. The use of this indication is for provision of rapid 
>> subtitling of speech and interpretation between sign language and 
>> spoken language when there is an interest to also provide the 
>> original. The 't' extension of BCP47 is specified in RFC 6497[RFC6497].
>>
>>  See section 5.x for further information and discussion on the 
>> indication of simultaneous languages.
>>  ---end of change 1----
>>
>>  ---Change 2, new text 5.x--------------
>>
>>  5.x Transformed simultaneous language
>>
>>  In certain applications it is of interest to indicate a transformed 
>> version of the contents of a media stream in another media, while 
>> still also providing the original.
>>
>>  This may for example be for rapid subtitling of speech either 
>> manually or automatically. It may also be sign language 
>> interpretation of speech, or spoken interpretation of sign language.
>>
>>  When the transformed language is provided or requested 
>> simultaneously with the original, this condition should be indicated 
>> by using the T extension to BCP47 as specified in RFC 6497[RFC6497], 
>> by attaching a t subtag on the language tag for the language that is 
>> expected to be provided in a transformed modality.
>>
>>  Briefly, the 't' extension consists of the string "-t" followed by 
>> the source language subtag.
>>
>>  Example: "en-t-en"   is an English transform of an English source 
>> (in another modality).
>>
>>  On reception of an indication including a language with the 't' 
>> extension for the receive direction, the answering party should 
>> interpret this as a request to send both the original and the 
>> transformed content provided that both are included in the 
>> indications. (e.g. both spoken and written )
>>
>>  On reception of an indication including an offer of a language with 
>> the 't' extension for the send direction, the answering party should 
>> interpret this as a request to arrange for reception of both the 
>> original and the transformed content simultaneously.
>>
>>  The media that the 't' extension is attached to should only be 
>> interpreted as an expectation for how the transformation will be 
>> made. Conditions in the established session MAY cause the original 
>> and transformation to swap roles from what the subtags indicated.
>>
>>
>>
>>
>>  ---add new text last in current section 5.5 - examples----------
>>
>>  Example: A request for a written English subtitling to be received 
>> by the caller in the text stream created from a spoken English source 
>> in the audio stream. The caller also indicates a preference to speak 
>> English:
>>
>>        m=audio 49250 RTP/AVP 20
>>        a=hlang-recv:en
>>        a=hlang-send:en*
>>
>>        m=text 45020 RTP/AVP 103 104
>>        a=hlang-recv:en-t-en*
>>
>>   An acknowledgement of the request:
>>
>>        m=audio 49250 RTP/AVP 20
>>        a=hlang-send:en
>>        a=hlang-recv:en
>>
>>        m=text 45020 RTP/AVP 103 104
>>        a=hlang-send:en-t-en
>>
>>  In the session, the caller will receive both spoken English and 
>> written English. The caller will send English speech.
>>
>>  ----end of new text -------------------------
>>   ------add to references----
>>
>>  [rfc6497] RFC 6497 Davis, M. et.al. "BCP 47 Extension T - 
>> Transformed Content", RFC 6497, February 2012.
>>
>>  -----end of changes ------------
>>
>>
>>
>>  --
>>  -----------------------------------------
>>  Gunnar Hellström
>>  Omnitor
>>  <mailto:gunnar.hellstrom@omnitor.se>gunnar.hellstrom@omnitor.se
>>  +46 708 204 288
>>
>>  _______________________________________________
>>  SLIM mailing list
>>  SLIM@ietf.org
>>  https://www.ietf.org/mailman/listinfo/slim
>
>

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288