Subject: Re: [Slim] script subtag as text medium indicator

From: Gunnar Hellström <[email-masked]>
Date: Sat, 26 Sep 2015 13:45:00 +0200

Gunnar Hellström
[email-masked]
+46 708 204 288

-------- Originalmeddelande --------
Från: Paul Kyzivat <[email-masked]> 
Datum:25-09-2015  16:17  (GMT+01:00) 
Till: [email-masked] 
Rubrik: Re: [Slim] script subtag as text medium indicator 

Inline...

On 9/25/15 2:24 AM, Gunnar Hellström wrote:
> In a real-time conversational call, spoken language can be said to be
> the default.
>
> And it is also the only possible if you have only audio enabled. But if
> you have text or video media enabled as well, then you get more choices.
>
> The simple other cases are that you want your real-time calls in written
> language in a two-way text stream, or in sign language in a two-way
> video stream.
>
> Just enabling text or video medium in a call is not at all sufficient
> for indicating what you want to use for language communication.
>
> I was thinking of if we could define how to handle the most simple
> real-time cases with a pre-SLIM method.
>
> We then could use the SIP media tags and language tags, or SDP language
> tags.
> SIP media tags are only on session level. SDP media tags can be used
> both on common session level and on media level.
>
> If we use SDP language tags on media level, then we do not need any
> discrimination between spoken and written language tags,
> but if we want to use a session level indication, we need to be able to
> specify in what modality the language is.

That may a good argument for using media level.

> Therefore a session level indication from a person who need to use
> written English would be en-Latn,
> while a person who want to speak English would specify en or nothing.
>
> A call from a person specifying en-Latn to one specifying en or nothing
> could pull in a relay service to support with modality translation
> between text an voice both ways.

For this to work, there must be a text medium between the caller to the 
relay. So then it could specify en on the media level, or en at the 
session level together with text media could imply written english.
<GH>Having text media does not at all indicate a desire to use it as the main conversational medium. Often the main conversation is in spoken language in audio, and text is then a handy complement.

Only if text was the only medium supported in the session, it could be concluded that the user wants to use it as the main modality.

So the conclusion is that we have no good indication on session level to differentiate between spoken and written language, but we have for signed language.

Next topic is then how far can we use pre-SLIM indications on media level.

> A call center with capability to handle both spoken and written modality
> would also get an indication on how to answer a call. If there is an
> en-Latn indication, then it is appropriate to respond with a written
> phrase in English. That avoids initial confusion.

Again, can only respond in text if there is a textual medium. And if 
there is, it makes sense to use it.
<GH>Right. it would be a good habit to have a greeting phrase to send in all supported modalities. As Total Conversation answering machines usually do. 

Thanks,
Paul

> Without the en-Latn indication there would be no base for a decision to
> invoke a relay service or how to answer a call.
>
>
> But this reasoning has a couple of problems:
> 1. This would be against the SHOULD NOT for using the script tag
> indicated by the Suppress-Script field ( that is present on many common
> languages).
>
> 2. We would also need an application agreement that for this kind of
> application the language tag without script is not used for written
> language.
>
> Are these two obstacles enough for saying that we should not try to
> create this kind of session-level pre-SLIM method?
>
> Gunnar
>
> -----------------------------------------
> Gunnar Hellström
> Omnitor
> [email-masked]
> +46 708 204 288
>
> Den 2015-09-24 kl. 17:29, skrev Phillips, Addison:
>> The indication of written versus non-written was discussed when RFC
>> 4646 and its successor 5646 (the current BCP47) were being created.
>>
>> The script subtag was introduced for identifying language content for
>> languages that commonly use more than one script (or for minority
>> cases, such as a transcription of a language into a script not
>> normally associated with that language). It is not commonly used for
>> content in languages that are primarily written in a single script as
>> its presence can interfere with matching of language tags. The
>> Suppress-Script field in the registry was created to help users and
>> implementations avoid the use of the script subtag for these
>> languages. Introducing it to indicate written-ness would be artificial
>> and introduce the issues that Suppress-Script was designed to avoid.
>>
>> The other thing you have to think about is that written content is the
>> norm, not the exception. While there are ample examples of non-written
>> content (movie soundtracks, songs, etc.), presence of language tags in
>> a document is normally closely associated with text.
>>
>> HTH,
>>
>> Addison
>>
>> Addison Phillips
>> Principal SDE, I18N Architect (Amazon)
>> Chair (W3C I18N WG), Editor (BCP47)
>>
>> Internationalization is not a feature.
>> It is an architecture.
>>
>>
>>
>>> -----Original Message-----
>>> From: SLIM [mailto:[email-masked]] On Behalf Of Brian Rosen
>>> Sent: Thursday, September 24, 2015 7:30 AM
>>> To: Gunnar Hellström
>>> Cc: [email-masked]
>>> Subject: Re: [Slim] script subtag as text medium indicator
>>>
>>> What is the use case where it’s important to differentiate?
>>>
>>> I’m not very interested in solving a problem where one session has
>>> written
>>> spanish and spoken French.  I admit that it could happen, but it’s a
>>> corner
>>> case.
>>>
>>> Brian
>>>
>>>> On Sep 23, 2015, at 6:16 PM, Gunnar Hellström
>>> <[email-masked]> wrote:
>>>> I guess that we have the language tag experts with us in slim, so I
>>>> through out a question a bit related to our topics here:
>>>>
>>>> We have said that it is sad that the language tags do not distinguish
>>> between spoken and written language.  So that if we had a language
>>> tag on
>>> session level, we would not know if it indicated spoken or written
>>> language
>>> use.
>>>> Sign languages have separate language names, so they do not suffer from
>>> this problem.
>>>> But, it seems to me that we could use the script subtag as a written
>>> language indicator.
>>>> If we make the application rule that for a certain application,
>>>> language tag without script subtag means spoken language, and language
>>>> tag with script subtag means written language, then within that
>>>> application domain,  for example
>>>>
>>>> fr would mean spoken French
>>>> fr-Latn would mean written French
>>>>
>>>> RFC 5646, says about the script subtag in section 2.2.3 "
>>>>
>>>>     There MUST be at most one script subtag in a language tag, and
>>>>        the script subtag SHOULD be omitted when it adds no
>>>>        distinguishing value to the tag or when the primary or extended
>>>>        language subtag's record in the subtag registry includes a
>>>>        'Suppress-Script' field listing the applicable script subtag."
>>>>
>>>>
>>>> Since it adds distinguishing value for distinguishing written from
>>>> spoken, it
>>> is a valid use of the subtag.
>>>> However, I see in the IANA language subtag registry that many languages
>>> ( including fr ) have Suppress-Script  registered.
>>>> So it adds distinguishing value, but has Suppress-Script. Can this
>>>> be a usage
>>> case when it can be accepted to use the script subtag to distinguish
>>> that it is
>>> about written language?
>>>> /Gunnar
>>>>
>>>>
>>>> --
>>>> -----------------------------------------
>>>> Gunnar Hellström
>>>> Omnitor
>>>> [email-masked]
>>>> +46 708 204 288
>>>>
>>>> _______________________________________________
>>>> SLIM mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/slim
>>> _______________________________________________
>>> SLIM mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/slim
>
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

_______________________________________________
SLIM mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/slim

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 26 Sep 2015 11:36:30 -0400

On 9/26/15 7:45 AM, Gunnar Hellström wrote:

> <GH>Having text media does not at all indicate a desire to use it as the
> main conversational medium. Often the main conversation is in spoken
> language in audio, and text is then a handy complement.
>
> Only if text was the only medium supported in the session, it could be
> concluded that the user wants to use it as the main modality.
>
> So the conclusion is that we have no good indication on session level to
> differentiate between spoken and written language, but we have for
> signed language.

Are you saying that you want to use a language indication at the session 
level to indicate the "main conversation medium"?

The definition of the a=lang attribute says:

    As a session-level attribute, it specifies the default language for
    the session being described.  As a media-level attribute, it
    specifies the language for that media, overriding any session-level
    languages specified.

Similar semantics apply to many (but not all) attributes. IMO it is a 
stretch to interpret that as meaning the "main conversation medium".

I think if we want to indicate a "main conversation medium" then we 
ought to seek out an overt way to do so.

> <GH>Right. it would be a good habit to have a greeting phrase to send in
> all supported modalities. As Total Conversation answering machines
> usually do.

I agree. But it is mostly out of scope of SDP and SIP. (AFAIK we don't 
specify anything about what ought to be sent in media.) It might make 
sense in an informational or best practices document.

	Thanks,
	Paul

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 28 Sep 2015 22:49:51 +0200

Den 2015-09-26 kl. 17:36, skrev Paul Kyzivat:
> Are you saying that you want to use a language indication at the 
> session level to indicate the "main conversation medium"?
>
I am just exploring how far we can go with pre-slim indications. So, if 
we find that it is unpractical with session level indications, we can 
move to check only media level indications.
Having a language attribute on just one SDP medium would be an overt way 
to indicate a main conversation medium and language.
That would be sufficient for three types of basic users.

Sign language users.

Text users.

Speech users.

For each type, the two media not used for primary language may be used 
for other purposes. ( seeing the person, occasional text, ambient sounds 
etc. )

We would lack the following commonly needed possibilities:

     Users requiring text transmission and speech reception.

     Users requiring speech transmission and text reception

     Users requiring speech transmission and combined text and speech 
reception.

And then we would also lack indications for some less often appearing needs:

     Users requiring sign language transmission and text reception.

     Users requiring speech transmission being supported by clear speech 
repetition when needed, and speech reception.

It will be possible to specify a range of languages for one medium. I 
cannot see that the conclusion in 
draft-gellens-slim-negotiating-human-language-02  that all listed 
languages would be used in the session can be right. It should be 
possible for a user to select which language to use, and therefore also 
a response to only include one preferred language.

So, what real-time slim can add is directionality, preference for 
combinations of media and order of preference between alternative media.
( I am afraid that only directionality has yet got a coding proposal )

/Gunnar

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Sep 2015 10:38:01 -0400

> ( I am afraid that only directionality has yet got a coding proposal )

IMO it is fine to use the existing indications (attributes).
But only in ways consistent with their existing definition.

*Preferred modality*, across multiple m-lines, is a new concept not 
covered by the existing attributes.

I agree that it could be useful to indicate the preferred modality. To 
do so, we should first nail down exactly what that means. Your list 
above is a start at that. And then seek out a suitable way to indicate 
it. (That might be extensions to an existing attribute, or definition of 
a new attribute.)

	Thanks,
	Paul