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

From: Gunnar Hellström <[email-masked]>
Date: Fri, 2 Jun 2017 21:28:53 +0200

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
[email-masked]
+46 708 204 288

---

From: Randall Gellens <[email-masked]>
Date: Fri, 2 Jun 2017 19:41:33 -0700

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.

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----
>
>  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.
>
>  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.
>
>
>
>
>  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*
>
>  In the session, the caller will receive both 
> spoken English and written English. The caller 
> will send English speech.
>
>  [rfc6497] RFC 6497 Davis, M. et.al. "BCP 47 
> Extension T - Transformed Content", RFC 6497, 
> February 2012.
>
>  <mailto:[email-masked]>[email-masked]
>  +46 708 204 288
>
>  _______________________________________________
>  SLIM mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/slim

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
We should never forget that everything Adolf Hitler did in Germany
was legal and everything the Hungarian freedom fighters did in
Hungary was illegal.               --Martin Luther King, Jr., 1963

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 3 Jun 2017 10:48:24 +0200

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

>>  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---
>>
>>  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].
>>
>>  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.
>>
>>  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.
>>
>>
>>
>>
>>  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*
>>
>>  In the session, the caller will receive both spoken English and 
>> written English. The caller will send English speech.
>>
>>  [rfc6497] RFC 6497 Davis, M. et.al. "BCP 47 Extension T - 
>> Transformed Content", RFC 6497, February 2012.
>>

---

From: Randall Gellens <[email-masked]>
Date: Sat, 3 Jun 2017 11:07:28 -0700

Hi Gunnar,

Thanks for your reply.  It seems to me that we 
should not add new functionality nor new 
complexity to the current draft.  As I've 
repeatedly said, I am happy to help write a 
separate draft.

At 10:48 AM +0200 6/3/17, Gunnar Hellström wrote:

>>  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 
>  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 
>  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
>
>
>>
>>>  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.
>>>
>>> added sign language interpretation of audio 
>>> in the video stream.
>>>
>>> user has value also of the original language 
>>> in the same direction.
>>>
>>> subtag on the extra provided language. 
>>> Defined in RFC 6497.
>>>
>>>  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.
>>>
>>> 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 
>>> 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.
>>>
>>> this condition should be indicated by using 
>>> the T extension to BCP47 as specified in RFC 
>>> language tag for the language that is 
>>> 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 )
>>>
>>> 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 
>>>  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.
>>>
>>>
>>>
>>>
>>> subtitling to be received by the caller in 
>>> the text stream created from a spoken English 
>>> spoken English and written English. The 
>>> caller will send English speech.
>>>
>>> <mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>[email-masked]
>>>  +46 708 204 288
>>>
>>>  <mailto:[email-masked]>[email-masked]
>>> 
>>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>>
>>
>>
>
>  --

-------------- Randomly selected tag: ---------------
Intelligence and war are games, perhaps the only meaningful games
left.  If any player becomes too proficient, the game is threatened
with termination.                           --William S. Burroughs