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

[Randall Gellens <[e-mail]>]

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:

>  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:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>[e-mail]
>>>  [phone]
>>>
>>>  _______________________________________________
>>>  SLIM mailing list
>>>  <mailto:[e-mail]>[e-mail]
>>> 
>>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>>
>>
>>
>
>  --
>  -----------------------------------------
>  Gunnar Hellström
>  Omnitor
>  <mailto:[e-mail]>[e-mail]
>  [phone]


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- 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