Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language

From: "Doug Ewell" <[email-masked]>
Date: Mon, 16 May 2016 08:39:58 -0700

Gunnar Hellström wrote:

>>> m=video ...
>>> a=humintlang-send:ase
>>> a=humintlang-recv:ase
>>>
>>> m=text ...
>>> a=humintlang-send:zxx
>>> a=humintlang-send:en
>>> a=humintlang-recv:zxx
>>> a=humintlang-recv:en
>>>
>>> Would mean that the user prefers to use American sign language but
>>> can with lower preference accept to type and read English.
>
> [ ... ]
>
> The thought was that the tags are ordered in preference order and
> since there was no preference on the highest level in the example to
> use language contents in text, therefore that preference level is
> marked with "No linguistic content". Not until coming to specifying
> lower preferences, there is a desire to use text for linguistic
> content.

I read this again, more slowly, and it sounds like what you are really
trying to do is implement a 2-dimensional matrix, with 'zxx' used as a
placeholder:

Direction   Priority   Video   Text
---------   --------   -----   ----
  Send         1        ase    zxx
  Send         2        ---     en
 Receive       1        ase    zxx
 Receive       2        ---     en

That still uses 'zxx' to mean something other than what it means. You're
not saying "text content that is not linguistic," you're saying "no text
content at all."

What you are trying to achieve is this:

Direction   Priority   Medium   Language
---------   --------   ------   --------
  Send         1       Video      ase
  Send         2        Text       en
 Receive       1       Video      ase
 Receive       2        Text       en

And that makes more sense (again, not weighing in on whether we actually
need this), because the data directly models the intended meaning.

If we are the ones inventing the syntax, and we need to represent
something that the syntax doesn't cover, the solution is to augment the
syntax so it does.

--
Doug Ewell | http://ewellic.org | Thornton, CO 🇺🇸

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 16 May 2016 22:25:21 +0200

> Direction   Priority   Video   Text
No, not really.  With humintlang we only negotiate the initial 
modality/language combination(s) to start using for the main dialogue. 
Conditions during the call may cause use of other media for occasional 
non linguistic content or other modalities/languages for shorter or 
longer periods of linguistic content.

But you are right anyway. We do not want to control in detail what the 
other media than the one(s) used for the main dialogue are used for.  So 
the proposal example just uses zxx as a placeholder to move english text 
to a lower preference than American Sign Language.

It should be possible to specify and agree on a notation for preference 
that meet our needs.

> Direction   Priority   Medium   Language
/Gunnar

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

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 16 May 2016 20:28:29 -0600

Gunnar Hellström wrote:

> other media than the one(s) used for the main dialogue are used for.
> So the proposal example just uses zxx as a placeholder to move english
> text to a lower preference than American Sign Language.

Which is not correct, you see. The protocol should not use a "no 
linguistic content" tag for text when there is no text content at all in 
the initial modality/language combination.

means "the user prefers to sign in American Sign Language while 
simultaneously typing non-linguistic text, such as gibberish." I don't 
think that is what is intended.

> It should be possible to specify and agree on a notation for
> preference that meet our needs.

Except that there is still disagreement on whether the mechanism is 
needed for SLIM 1.0.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 16 May 2016 20:25:53 -0700

>  Except that there is still disagreement on whether the mechanism is 

And we have a call for consensus by the chairs.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
By further reducing the number of legacy airlines and aligning the
economic incentives of those that remain, the merger of US Airways
and American would make it easier for the remaining airlines to
cooperate rather than compete on price on service.
        --US Justice Department, part of a lawsuit filed to stop
          the AA/US Air airline merger, 13 August 2013.

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 17 May 2016 08:01:03 +0200

Randall,

Can you accept that our goal is to select the most appropriate 
language(s) for the call?

This includes providing guidance to the answering part so that the 
answer can be made in the most appropriate language(s).

That is stated in the charter:

"While the two use cases are in different contexts (real time and
non-real-time), the fundamental goal is the same: to enable selection of
the best-fit language(s) for a specific situation."

It is not sufficient to use the indications to select which media shall 
be enabled, and then let the users sort out which language to use.

The user needs guidance if it is most appropriate to start the 
conversation in voice, sign language or text or a combination of these 
modalities. If not, the call will start with confusion about what is the 
most efficient means for them to communicate.

That is why the preference indication needs to have:

a) a common scope over all media, and

b) an indication if two modalities simultaneously are desired for reception.

Can we agree on that and move on to find a simple way of expressing 
these needs?

/Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 17 May 2016 08:15:42 +0200

Den 2016-05-17 kl. 04:28, skrev Doug Ewell:
> linguistic content" tag for text when there is no text content at all 
> in the initial modality/language combination.
>
No, it means my highest preference is to use video with american sign 
language and have text available for items such as phone numbers, dates, 
web urls, email-addresses etc that is more rapid and reliable to type 
than to sign ( or say ).

However, that difference is not essential for our discussion. The mere 
existence of the text media description in sdp is sufficient to express 
that I want to establish text media.
/Gunnar

---

From: Brian Rosen <[email-masked]>
Date: Tue, 17 May 2016 12:05:46 -0400

Like Randall, I want to stay away from a linkage between what languages you prefer and what media you are offering.

I want to stay with the long standing SDP negotiation that you offer media you want to use, and and or all of that media can be accepted.

I want our work to build on that, not change it, so that we can indicate, for the media accepted, what language is preferred.  

I further don’t want to link a preference of language on one media to the preference of language on another media.   I want them independent: if audio and text are offered and answered, then language on audio is specified, and language on text is specified, and those don’t interact.

I think living with those restrictions will make implementations easier, and won’t limit use much. 

Adding more complexity at this point is, I think, not worth it.

Brian

> On May 17, 2016, at 2:01 AM, Gunnar Hellström <[email-masked]> wrote:
> 
> Randall, 
> Can you accept that our goal is to select the most appropriate language(s) for the call?
> 
> This includes providing guidance to the answering part so that the answer can be made in the most appropriate language(s).
> 
> the best-fit language(s) for a specific situation. "
> 
> It is not sufficient to use the indications to select which media shall be enabled, and then let the users sort out which language to use. 
> 
> The user needs guidance if it is most appropriate to start the conversation in voice, sign language or text or a combination of these modalities. If not, the call will start with confusion about what is the most efficient means for them to communicate. 
> 
> Can we agree on that and move on to find a simple way of expressing these needs?
> 
> /Gunnar
> 
> 
> 
> 
> 
> 
>>>  Except that there is still disagreement on whether the mechanism is needed for SLIM 1.0. 
>> 
> [email-masked] <mailto:[email-masked]>
> +46 708 204 288
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

---

From: Randall Gellens <[email-masked]>
Date: Tue, 17 May 2016 14:17:53 -0700

Gunnar,

I think we can start with what we have now: the 
offerer offers all media/languages it wants, and 
the answerer accepts those it supports.  In many 
cases this will be exactly what's desired, while 
in some cases there will be extra media that are 
not used.

This gives us something simple that has the best 
chance of rapid and wide deployment.  We can then 
build on this if need be.

At 8:01 AM +0200 5/17/16, Gunnar Hellström wrote:

>  Randall,
>
>  Can you accept that our goal is to select the 
> most appropriate language(s) for the call?
>
>  This includes providing guidance to the 
> answering part so that the answer can be made 
> in the most appropriate language(s).
>
>  It is not sufficient to use the indications to 
> select which media shall be enabled, and then 
> let the users sort out which language to use.
>
>  The user needs guidance if it is most 
> appropriate to start the conversation in voice, 
> sign language or text or a combination of these 
> modalities. If not, the call will start with 
> confusion about what is the most efficient 
> means for them to communicate.
>
>>>  Except that there is still disagreement on 
>>> whether the mechanism is needed for SLIM 1.0.
>>>
>>
>  <mailto:[email-masked]>[email-masked]
>  +46 708 204 288
>

-------------- Randomly selected tag: ---------------
If people don't know what you're doing, they don't know what you're
doing wrong.         --Sir Arnold Robinson, _Yes,_Minister_

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 17 May 2016 23:56:07 +0200

Den 2016-05-17 kl. 23:17, skrev Randall Gellens:

> Gunnar,
>
> I think we can start with what we have now: the offerer offers all 
> media/languages it wants, and the answerer accepts those it supports.
Yes, but we need a bit more than we have today to express that. Language 
usage are logically linked.
> In many cases this will be exactly what's desired, while in some cases 
> there will be extra media that are not used.
I am not bothered about extra media. Offered media shall not be rejected 
just because they do not have agreed language contents.
>
> This gives us something simple that has the best chance of rapid and 
> wide deployment.  We can then build on this if need be.
We already have the need. 3GPP cannot use user profiles in emergency 
registration mode, so we need to be able to express user needs this way 
to the degree that they can be served well in emergency calls.
For that we need to
clarify language in some places in the draft so that we do not end up 
equally fuzzy as RFC 4566,
We need to delete our interpretation of RFC 4566,
we need to express preference with scope among all media.
and we need to express when languages are needed together and when they 
are to select from.

You have accepted some edit proposals that we have discussed and 
modified others to something that we have not  yet seen. I would like to 
see the draft as it is now so that we can see what more needs to be 
changed.

>>  It is not sufficient to use the indications to select which media 
>> shall be enabled, and then let the users sort out which language to use.
>>
>> conversation in voice, sign language or text or a combination of 
>> these modalities. If not, the call will start with confusion about 
>> what is the most efficient means for them to communicate.
>>

---

From: Natasha Rooney <[email-masked]>
Date: Wed, 18 May 2016 17:08:43 +0000

Randall - the last edit we see of the doc is from March, is this the most recent one? If not can you submit an edit soon?

All - In all our discussions I see two things that we want here: [1] we want a simple and easily implementable solution/s and [2] solution/s that cover all the use cases. I think we can agree that going ahead with a simple solutions which is extensible covers both of these needs. It allows us to get something out there which can be implemented, and it allows us to answer all the use cases with extensibility which we will work on next (I appreciate this isn’t immediate but it’s favourable to making a complex solution now which is too difficult to implement). All advice I have received on this has suggested this is the best route forward.

Given we’re well over the time that we should have agreed on this I suggest we call rough consensus for this here. I understand there may be some frustration, but really this method solves for both needs and so is sensible.

Bernard and Alexey - please check this and input if you see fit!

Natasha

Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | [email-masked]<mailto:[email-masked]> | +44 (0) 7730 219 765 | @thisNatasha | Skype: [email-masked]<mailto:[email-masked]>

On May 17, 2016, at 10:56 PM, Gunnar Hellström <[email-masked]<mailto:[email-masked]>> wrote:

Gunnar,

I think we can start with what we have now: the offerer offers all media/languages it wants, and the answerer accepts those it supports.
Yes, but we need a bit more than we have today to express that. Language usage are logically linked.
In many cases this will be exactly what's desired, while in some cases there will be extra media that are not used.
I am not bothered about extra media. Offered media shall not be rejected just because they do not have agreed language contents.

This gives us something simple that has the best chance of rapid and wide deployment.  We can then build on this if need be.
We already have the need. 3GPP cannot use user profiles in emergency registration mode, so we need to be able to express user needs this way to the degree that they can be served well in emergency calls.
For that we need to
clarify language in some places in the draft so that we do not end up equally fuzzy as RFC 4566,
We need to delete our interpretation of RFC 4566,
we need to express preference with scope among all media.
and we need to express when languages are needed together and when they are to select from.

You have accepted some edit proposals that we have discussed and modified others to something that we have not  yet seen. I would like to see the draft as it is now so that we can see what more needs to be changed.

 Randall,

 /Gunnar

 --
 -----------------------------------------
 Gunnar Hellström
 Omnitor
 <mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
 +46 708 204 288

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

--
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]<mailto:[email-masked]>
+46 708 204 288

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

This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error.

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 19 May 2016 00:23:29 +0200

Den 2016-05-18 kl. 19:08, skrev Natasha Rooney:
> Randall - the last edit we see of the doc is from March, is this the 
> most recent one? If not can you submit an edit soon?
We had e-mail list discussion around April 8-10 under the subject 
"[Slim] Wording about selection in 
draft-ietf-slim-negotiating-human-language-01"
that ended with some agreed changes and some in-principle agreed changes 
but no agreed wording. That is what I refer to when I say I want to see 
what the latest edits ended up in.

That mainly covered the ambition to be more exact than RFC 4566 lang 
specification.

So, when we get that, we can judge:
1. If it is clear when the indications reflect a selection possibility 
or a combination requirement.

There are a couple of other things we need to modify also before 
progressing to any kind of consensus.

2. In 5. Delete our interpretation of the lang attribute. It is 
sufficient to say that it is not enough detailed because it does not 
provide directionality.

3. In 5. insert specification on how lang and humintlang relates. The 
easiest way is to say that lang should not be used in sdp where 
humintlang is used. Is that too drastic?

4. Do we really need the * parameter for "do not fail call" introduced 
in 6.2 and explained in 6.3?  It will be most common to want to have 
that effect, thus requiring to add the * in most media specifications. 
Can we simplify the syntax by having "do not fail call" as the default 
and delete the description of the * ? I suggest that we delete it.
If not, the description of the syntax of how the * is included needs to 
be inserted in the syntax description in section 6.2 and an example added.

5. In this part of 6.2:
"In cases where the user
    wishes to use one media for sending and another for receiving (such
    as a speech-impaired user who wishes to send using text and receive
    using audio), one of the two MAY be unset.  In cases where a media is
    not primarily intended for language (for example, a video or audio
    stream intended for background only) both SHOULD be unset.  In other
    cases, both SHOULD have the same values in the same order.  The two
    SHOULD NOT be set to languages which are difficult to match together"

Clarify that "two" and "both" refers to the humintlang-send and 
humintlang-recv attributes for a medium.
( the attribute names are too far back so when searching for what "two" 
and "both" refers to you end up in confusion).

6. And, yet another proposal to insert a simple indication for 
preference betweeen media, and one for distinguishing selection versus 
combination.
The needs come from accessibility needs, and fulfilling accessibility 
needs has strong policy support, so it would be bad to say that that 
must wait for another version of the document when we already now have 
specified the need.

--------------------------------------------------In 6.2 
insert:----------------------------------------------------------------------
A single digit numeric value on a humintlang attribute represents a 
starting priority for the humintlang attributes of the same medium and 
direction, with one being the highest priority.  If no such value is 
indicated, the value 1 is assumed. The priority value is increased by a 
value 0.1 for each humintlang attribute for the same media and direction.
An asterisk on a humintlang attribute alone or together with a priority 
number indicates that a language specified in the actual media and 
direction is wanted in combination with another modality in the same 
direction, also marked with an asterisk.

Examples:
m=audio ...
humintlang-send:en
humintlang-recv:*
humintlang-recv:en
m=text ...
humintlang-recv:*
humintlang-recv:en

This means that the user want to send spoken English and receive a 
combination of both spoken and typed English simultaneously  back.

m=video ...
humintlang-send:ase
humintlang-recv:ase
m=text ...
humintlang-send:5
humintlang-send:en
humintlang-recv:5
humintlang-recv:en

This means that the user prefers to use American sign language both 
ways, but as a possible selection on lower preference level use text 
both ways.
---------------------------------------------------------end of 
insertion---------------------

The fact that the humintlang attribute now can have values that are not 
language tags needs to be reflected in a few other places in the draft.

>
> All - In all our discussions I see two things that we want here: [1] 
> we want a simple and easily implementable solution/s and [2] 
> solution/s that cover all the use cases. I think we can agree that 
> going ahead with a simple solutions which is extensible covers both of 
> these needs. It allows us to get something out there which can be 
> implemented, and it allows us to answer all the use cases with 
> extensibility which we will work on next (I appreciate this isn’t 
> immediate but it’s favourable to making a complex solution now which 
> is too difficult to implement). All advice I have received on this has 
> suggested this is the best route forward.
We can't wait with an extension for something we have a need for now.
The above addition no 6. is a simple notation for what we were missing.
>
> Given we’re well over the time that we should have agreed on this I 
> suggest we call rough consensus for this here. I understand there may 
> be some frustration, but really this method solves for both needs and 
> so is sensible.
>
/Gunnar
>
> Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | 
> [email-masked] <mailto:[email-masked]> | +44 (0) 7730 219 765 | 
> @thisNatasha | Skype: [email-masked] <mailto:[email-masked]>
>
>
>> On May 17, 2016, at 10:56 PM, Gunnar Hellström 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>> In many cases this will be exactly what's desired, while in some 
>>> cases there will be extra media that are not used.
>> I am not bothered about extra media. Offered media shall not be 
>> rejected just because they do not have agreed language contents.
>>>
>> registration mode, so we need to be able to express user needs this 
>> way to the degree that they can be served well in emergency calls.
>> For that we need to
>> modified others to something that we have not  yet seen. I would like 
>> to see the draft as it is now so that we can see what more needs to 
>> be changed.
>>
>>>
>>>
>> [email-masked] <mailto:[email-masked]>
> This email and its attachments are intended for the above named only 
> and may be confidential. If they have come to you in error you must 
> take no action based on them, nor must you copy or show them to 
> anyone; please reply to this email or call +44 207 356 0600 and 
> highlight the error.
>

---

From: Randall Gellens <[email-masked]>
Date: Wed, 18 May 2016 16:32:57 -0700

At 5:08 PM +0000 5/18/16, Natasha Rooney wrote:

>  Randall - the last edit we see of the doc is from March, is this 
> the most recent one? If not can you submit an edit soon?

This is the most recent version.

-------------- Randomly selected tag: ---------------
This is a nasty, rotten business.
    --Robert L. Crandall, CEO & President of American Airlines

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 20 May 2016 08:55:20 +0200

I have a compromise proposal. Let us test if we can get somewhere by 
introducing it.

Let us delete the use of the asterisk '*' for the 'do not drop' 
notation, and let 'do not drop' be the default.

Let us reuse the asterisk attached to the end of a language tag be used 
for both a priority indication with the whole sdp as scope, and an 
indication of grouping.

Initial change proposals ( there will be more follow-up changes, but 
these are the main ones )

---------------change in 6.2 
from---------------------------------------------------------------

  In an offer, each language tag value MAY have an asterisk appended as
    the last character (after the registry value).  The asterisk
    indicates a request by the caller to not fail the call if there is no
    language in common.  SeeSection 6.3 
<https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-01#section-6.3>  for more information and
    discussion.
-------------------to-------------------------------------
  In an offer, language tag values MAY have an asterisk appended as
    the last character (after the registry value).  The asterisk
    indicates a main preference for the indicated language.  SeeSection 6.3 
<https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-01#section-6.3>  
    for more information and discussion.
----------------------------end of change in 6.2---------------------

-------------------Replace 6.3 with this----------------------------------

6.3 Main preference

If a user has a strong preference for using a language over the other
indicated languages, this preference can be indicated by including an
asterisk '*' last in the value of the preferred language and direction
indication.

One such preference indication can be used per direction to indicate
main preference. This preference has scope across all media.

Two or more such preference indications can be used per direction to
indicate a strong preference or capability to use the indicated languages
in the indicated direction simultaneously together.

Examples:
Example 1;  a calling user, who strongly prefers to use spoken English
  supported by reception of rapidly added text captioning of the received
  speech can indicate this preference by the following abbreviated sdp.
  This indication can be used by the callee or by the involved services
  to make efforts to invoke a way of adding text to the speech answers.
  
    m=audio ...
     humintlang-send:en
     humintlang-recv:en*
    m=text ...
     humintlang-recv:en*
   
Example 2; a calling user, who prefers to use American sign language both
   ways, but want to indicate that text in English both ways is an accepted
   alternative on lower preference level can indicate this preference by the
   following abbreviated sdp:
   This indication can be used by the called party to make efforts to answer
   with sign language competent personnel, but if that is not available be
   assured that a text conversation will also be successful.
  
    m=video ...
     humintlang-send:ase*
     humintlang-recv:ase*
    m=text ...
     humintlang-send:en
     humintlang-recv:en

-------------------------------end of 
changes------------------------------------------------

Discussion: This compromise satisfies most use cases for which global 
preference and grouping are needed, but has some drawbacks compared to a 
system with finer graded preferences.

1. For the grouping example above with receiving spoken English and 
English text, it cannot be seen what is best if it is not possible to 
provide the combination. There is no clue if it would be reasonably 
possible to provide only text or only spoken English.

2. The notation is only usable for a single preference combination.
  It is not possible to indicate a number of sign languages, all 
preferred over typed English.
This drawback appears because the same notation is used for main 
preference as for grouping indication.

I want anyway to provide this compromise proposal, because it does not 
introduce any extra complexity and it solves the main so far unsolved 
use cases.

/Gunnar

Den 2016-05-19 kl. 00:23, skrev Gunnar Hellström:
> that ended with some agreed changes and some in-principle agreed 
> changes but no agreed wording. That is what I refer to when I say I 
> want to see what the latest edits ended up in.
>
> If not, the description of the syntax of how the * is included needs 
> to be inserted in the syntax description in section 6.2 and an example 
> added.
>
> 5. In this part of 6.2:
> "In cases where the user
> ( the attribute names are too far back so when searching for what 
> "two" and "both" refers to you end up in confusion).
>
> indicated, the value 1 is assumed. The priority value is increased by 
> a value 0.1 for each humintlang attribute for the same media and 
> direction.
> An asterisk on a humintlang attribute alone or together with a 
> priority number indicates that a language specified in the actual 
> media and direction is wanted in combination with another modality in 
> the same direction, also marked with an asterisk.
>
> Examples:
> m=audio ...
> humintlang-send:en
> humintlang-recv:*
> humintlang-recv:en
> m=text ...
> humintlang-recv:*
> humintlang-recv:en
>
> The fact that the humintlang attribute now can have values that are 
> not language tags needs to be reflected in a few other places in the 
> draft.
>
>
>
>
>
>
>
>>
>> going ahead with a simple solutions which is extensible covers both 
>> of these needs. It allows us to get something out there which can be 
>> is too difficult to implement). All advice I have received on this 
>> has suggested this is the best route forward.
>> @thisNatasha | Skype: [email-masked]
>>
>>
>>>> This gives us something simple that has the best chance of rapid 
>>>> and wide deployment.  We can then build on this if need be.
>>> modified others to something that we have not  yet seen. I would 
>>> like to see the draft as it is now so that we can see what more 
>>> needs to be changed.
>>>
>>>>
>>>>
>>>>>  This includes providing guidance to the answering part so that 
>>>>> the answer can be made in the most appropriate language(s).
>>>>>

---

From: Brian Rosen <[email-masked]>
Date: Fri, 20 May 2016 14:01:59 -0400

I personally don’t want to have anything like “main preference”  or grouping that confuses the per-media characteristic of SDP.

Brian

> On May 20, 2016, at 2:55 AM, Gunnar Hellström <[email-masked]> wrote:
> 
> I have a compromise proposal. Let us test if we can get somewhere by introducing it.
> 
> Let us delete the use of the asterisk '*' for the 'do not drop' notation, and let 'do not drop' be the default.
> 
> Let us reuse the asterisk attached to the end of a language tag be used for both a priority indication with the whole sdp as scope, and an indication of grouping.
> 
> Initial change proposals ( there will be more follow-up changes, but these are the main ones )
> ---------------change in 6.2 from---------------------------------------------------------------
> 
>    language in common.  See Section 6.3 <https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-01#section-6.3> for more information and
>    discussion.
>    indicates a main preference for the indicated language.  See Section 6.3 <https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-01#section-6.3> 
> -------------------------------end of changes------------------------------------------------
> 
> Discussion: This compromise satisfies most use cases for which global preference and grouping are needed, but has some drawbacks compared to a system with finer graded preferences.
> 
> 1. For the grouping example above with receiving spoken English and English text, it cannot be seen what is best if it is not possible to provide the combination. There is no clue if it would be reasonably possible to provide only text or only spoken English.
> 
>  It is not possible to indicate a number of sign languages, all preferred over typed English.
> This drawback appears because the same notation is used for main preference as for grouping indication.
> 
> I want anyway to provide this compromise proposal, because it does not introduce any extra complexity and it solves the main so far unsolved use cases.
> /Gunnar
> 
>> We had e-mail list discussion around April 8-10 under the subject "[Slim] Wording about selection in draft-ietf-slim-negotiating-human-language-01"
>> that ended with some agreed changes and some in-principle agreed changes but no agreed wording. That is what I refer to when I say I want to see what the latest edits ended up in.
>> 
>> That mainly covered the ambition to be more exact than RFC 4566 lang specification.
>> 
>> 1. If it is clear when the indications reflect a selection possibility or a combination requirement. 
>> 
>> There are a couple of other things we need to modify also before progressing to any kind of consensus. 
>> 
>> 2. In 5. Delete our interpretation of the lang attribute. It is sufficient to say that it is not enough detailed because it does not provide directionality.
>> 
>> 3. In 5. insert specification on how lang and humintlang relates. The easiest way is to say that lang should not be used in sdp where humintlang is used. Is that too drastic?
>> 
>> 4. Do we really need the * parameter for "do not fail call" introduced in 6.2 and explained in 6.3?  It will be most common to want to have that effect, thus requiring to add the * in most media specifications. Can we simplify the syntax by having "do not fail call" as the default and delete the description of the * ? I suggest that we delete it.
>> If not, the description of the syntax of how the * is included needs to be inserted in the syntax description in section 6.2 and an example added.
>> 
>> 5. In this part of 6.2: 
>> "In cases where the user
>> Clarify that "two" and "both" refers to the humintlang-send and humintlang-recv attributes for a medium. 
>> ( the attribute names are too far back so when searching for what "two" and "both" refers to you end up in confusion).
>> 
>> 6. And, yet another proposal to insert a simple indication for preference betweeen media, and one for distinguishing selection versus combination.
>> The needs come from accessibility needs, and fulfilling accessibility needs has strong policy support, so it would be bad to say that that must wait for another version of the document when we already now have specified the need. 
>> 
>> --------------------------------------------------In 6.2 insert:----------------------------------------------------------------------
>> A single digit numeric value on a humintlang attribute represents a starting priority for the humintlang attributes of the same medium and direction, with one being the highest priority.  If no such value is indicated, the value 1 is assumed. The priority value is increased by a value 0.1 for each humintlang attribute for the same media and direction. 
>> An asterisk on a humintlang attribute alone or together with a priority number indicates that a language specified in the actual media and direction is wanted in combination with another modality       in the same direction, also marked with an asterisk.
>> 
>> Examples:
>> m=audio ...
>> humintlang-send:en
>> humintlang-recv:*
>> humintlang-recv:en
>> m=text ...
>> humintlang-recv:*
>> humintlang-recv:en
>> 
>> This means that the user want to send spoken English and receive a combination of both spoken and typed English simultaneously  back.
>> 
>> m=video ...
>> humintlang-send:ase
>> humintlang-recv:ase
>> m=text ...
>> humintlang-send:5
>> humintlang-send:en
>> humintlang-recv:5
>> humintlang-recv:en
>> 
>> This means that the user prefers to use American sign language both ways, but as a possible selection on lower preference level use text both ways.
>> ---------------------------------------------------------end of insertion---------------------
>>   
>> The fact that the humintlang attribute now can have values that are not language tags needs to be reflected in a few other places in the draft.
>> 
>> 
>> 
>>  
>> 
>>  
>> 
>>> 
>>> Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | [email-masked] <mailto:[email-masked]> | +44 (0) 7730 219 765 | @thisNatasha | Skype:  <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>>> 
>>> 
>>>> On May 17, 2016, at 10:56 PM, Gunnar Hellström <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>>>>  <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>[email-masked] <mailto:[email-masked]> 
>>>>>>  +46 708 204 288 
>>>>>> 
>>>>>>  https://www.ietf.org/mailman/listinfo/slim <https://www.ietf.org/mailman/listinfo/slim> 
>>>>> 
>>>>> 
>>>> 
>>>> -- 
>>>> https://www.ietf.org/mailman/listinfo/slim <https://www.ietf.org/mailman/listinfo/slim>
>>> 
>> https://www.ietf.org/mailman/listinfo/slim <https://www.ietf.org/mailman/listinfo/slim>
> 
> --

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 20 May 2016 21:29:20 +0200

Den 2016-05-20 kl. 20:01, skrev Brian Rosen:

> I personally don’t want to have anything like “main preference”  or 
> grouping that confuses the per-media characteristic of SDP.
But looking at the needs of users and service providers, there are 
logical relations between media.
They do not need to influence the decision on which media to start, but 
to which terminal to route the call, and what info to provide to the 
answering party and possibly what extra service to link in on the call.  
All these are depending on relations between language in different 
media, so I cannot see how we can avoid at least the proposed minimal 
form of preference across media and minimal grouping.

Can you accept it even if you do not want it?

Was this compromise proposal better than the previous one with explicit 
preference value per list of humintlang attributes?

/Gunnar
>
> Brian
>
>
>> On May 20, 2016, at 2:55 AM, Gunnar Hellström 
>> Let us reuse the asterisk attached to the end of a language tag be 
>> used for both a priority indication with the whole sdp as scope, and 
>> an indication of grouping.
>>
>> preference and grouping are needed, but has some drawbacks compared 
>> to a system with finer graded preferences.
>>
>> I want anyway to provide this compromise proposal, because it does 
>> not introduce any extra complexity and it solves the main so far 
>> unsolved use cases.
>>
>> /Gunnar
>>
>>
>>> 1. If it is clear when the indications reflect a selection 
>>> possibility or a combination requirement.
>>>
>>> 3. In 5. insert specification on how lang and humintlang relates. 
>>> The easiest way is to say that lang should not be used in sdp where 
>>> 4. Do we really need the * parameter for "do not fail call" 
>>> introduced in 6.2 and explained in 6.3? It will be most common to 
>>> want to have that effect, thus requiring to add the * in most media 
>>> specifications. Can we simplify the syntax by having "do not fail 
>>> call" as the default and delete the description of the * ? I suggest 
>>> that we delete it.
>>> to be inserted in the syntax description in section 6.2 and an 
>>> example added.
>>>
>>> 5. In this part of 6.2:
>>> "In cases where the user
>>> preference betweeen media, and one for distinguishing selection 
>>> versus combination.
>>> The needs come from accessibility needs, and fulfilling 
>>> accessibility needs has strong policy support, so it would be bad to 
>>> say that that must wait for another version of the document when we 
>>> already now have specified the need.
>>>
>>> starting priority for the humintlang attributes of the same medium 
>>> and direction, with one being the highest priority.  If no such 
>>> value is indicated, the value 1 is assumed. The priority value is 
>>> increased by a value 0.1 for each humintlang attribute for the same 
>>> media and direction.
>>> media and direction is wanted in combination with another modality 
>>> in the same direction, also marked with an asterisk.
>>>
>>> Examples:
>>> m=audio ...
>>> humintlang-send:en
>>> humintlang-recv:*
>>> humintlang-recv:en
>>> m=text ...
>>> humintlang-recv:*
>>> humintlang-recv:en
>>>
>>>> All - In all our discussions I see two things that we want here: 
>>>> [1] we want a simple and easily implementable solution/s and [2] 
>>>> of these needs. It allows us to get something out there which can 
>>>> be implemented, and it allows us to answer all the use cases with 
>>>> immediate but it’s favourable to making a complex solution now 
>>>> which is too difficult to implement). All advice I have received on 
>>>> this has suggested this is the best route forward.
>>>> suggest we call rough consensus for this here. I understand there 
>>>> may be some frustration, but really this method solves for both 
>>>> needs and so is sensible.
>>>>
>>>> Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA 
>>>> | [email-masked] <mailto:[email-masked]> | +44 (0) 7730 219 765 
>>>> | @thisNatasha | Skype: [email-masked]
>>>>
>>>>
>>>>>> I think we can start with what we have now: the offerer offers 
>>>>>> all media/languages it wants, and the answerer accepts those it 
>>>>>> supports.
>>>>> We already have the need. 3GPP cannot use user profiles in 
>>>>> emergency registration mode, so we need to be able to express user 
>>>>> needs this way to the degree that they can be served well in 
>>>>> emergency calls.
>>>>> For that we need to
>>>>>>>  It is not sufficient to use the indications to select which 
>>>>>>> media shall be enabled, and then let the users sort out which 
>>>>>>> language to use.
>>>>>>>
>>>>>>> these modalities. If not, the call will start with confusion 
>>>>>>> about what is the most efficient means for them to communicate.
>>>>>>>
>>>> This email and its attachments are intended for the above named 
>>>> only and may be confidential. If they have come to you in error you 
>>>> must take no action based on them, nor must you copy or show them 
>>>> to anyone; please reply to this email or call +44 207 356 0600 and 
>>>> highlight the error.
>>>>
>>>
>>> --

---

From: Brian Rosen <[email-masked]>
Date: Fri, 20 May 2016 15:44:51 -0400

While I agree there are corner cases simpler mechanisms won’t cover, I think they are rare enough that the complexity introduced in every implementation to allow the corner case to work is not acceptable.

I am not in favor of adopting this proposal.

I don’t think either of these proposals is the right way to do grouping, and I don’t want to do grouping at this time, so arguing over which is better is pointless.  I’d probably use RFC5888 as a starting point and define groups of media and languages in the offer, which the answer can select from.

Brian

> On May 20, 2016, at 3:29 PM, Gunnar Hellström <[email-masked]> wrote:
> 
> But looking at the needs of users and service providers, there are logical relations between media. 
> They do not need to influence the decision on which media to start, but to which terminal to route the call, and what info to provide to the answering party and possibly what extra service to link in on the call.  All these are depending on relations between language in different media, so I cannot see how we can avoid at least the proposed minimal form of preference across media and minimal grouping.
> 
> Was this compromise proposal better than the previous one with explicit preference value per list of humintlang attributes?
> 
> /Gunnar
>> 
>> Brian
>> 
>> 
>>> On May 20, 2016, at 2:55 AM, Gunnar Hellström <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>>> Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA |  <mailto:[email-masked]>[email-masked] <mailto:[email-masked]> | +44 (0) 7730 219 765 | @thisNatasha | Skype: [email-masked] <mailto:[email-masked]>
>>>>> 
>>>>> 
>>>>>> On May 17, 2016, at 10:56 PM, Gunnar Hellström < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 21 May 2016 08:17:48 -0700

> The user needs guidance if it is most appropriate to start the conversation in voice, sign language or text or a combination of these modalities. If not, the call will start with confusion about wh…
[BA] In conferencing scenarios where participants can join late, how would preference work? In those scenarios participants might have different preferences and only negotiating the most preferred for each participant seems like it could result in a broken conference where media/languages with low preference might actually be needed but that could not be determined until later.

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 21 May 2016 08:29:59 -0700

On May 17, 2016, at 14:17, Randall Gellens <[email-masked]> wrote:
> 
> while in some cases there will be extra media that are not used.

[BA] There may be use cases where negotiating media/languages without preference works whereas preference does not.

For example, the "extra media" may not be determinable until after the call is in progress (e.g. conferences). You have a working camera and prefer signing and so do others so you started out the conference that way. I join late but I have no camera, so I can only send text. If text was possible for everyone but low preference so they did not negotiate it, now we have a problem, whereas without preference I can send text from the start.

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 21 May 2016 22:22:46 +0200

> For example, the "extra media" may not be determinable until after the call is in progress (e.g. conferences). You have a working camera and prefer signing and so do others so you started out the c…
We have said that the prime intention with the humintlang attributes are 
not to guide which media are connected. The intention is to guide what 
competence to allocate to the call and how to start communicating in the 
call.

So, when you arrive late, the other users likely have text enabled and 
you can start asking in text if they can be kind to involve you in the 
communication by text.

"there will be extra media that are not used" means that these extra 
media are connected, but not used for the main language contents. ( 
until you arrive )

I think it is also stated somewhere that the negotiation just helps with 
the initial conversation establishment, and the result does not limit 
the users from changing to other languages during the call. However, I 
don't find right now where that was specified. if we do not ave that 
statement anywhere, it should be introduced.

Gunnar

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 21 May 2016 15:31:47 -0700

On May 21, 2016, at 1:22 PM, Gunnar Hellström <[email-masked]> wrote:
> We have said that the prime intention with the humintlang attributes are not to guide which media are connected. The intention is to guide what competence to allocate to the call and how to start communicating in the call. 
> 
> So, when you arrive late, the other users likely have text enabled and you can start asking in text if they can be kind to involve you in the communication by text. 
> 
> "there will be extra media that are not used" means that these extra media are connected, but not used for the main language contents. ( until you arrive )

[BA] Agree that is how the current draft works. But if we were to group media and language together, would it continue to work that way? 

> I think it is also stated somewhere that the negotiation just helps with the initial conversation establishment, and the result does not limit the users from changing to other languages during the call. However, I don't find right now where that was specified. if we do not have that statement anywhere, it should be introduced. 

[BA] Is it correct to assume that the language change can occur without negotiation, assuming that the media/language to be used is within the negotiated envelope?

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 22 May 2016 08:36:23 +0200

> [BA] Agree that is how the current draft works. But if we were to group media and language together, would it continue to work that way?
[GH]Yes, the users in your example of sign language users, also prepared 
to conduct a text conversation would not request grouping of sign 
language and text. They would indicate text on a lower preference than 
sign language.
When they find that the sign language preference is met, they can 
conduct the main conversation in sign language and have the text stream 
for occasional items that fits better there.

When you jump into the call with only text, you need to ask them if they 
can accept to accommodate for you to participate as well, but that is 
not given.  They did not request grouping of sign language and text, 
they only marked relative priority. So they have no means to provide the 
whole content of the conference in both sign language and text. So it is 
up for discussion among them if they shall leave their preferred 
modality and accept to use text for your sake.

If they instead had requested to receive both sign language and text and 
grouped them, it would mean that they had very strong preference for 
being provided with both simultaneously. (e.g. by being deaf-blind with 
some residual vision that make received sign language of value but not 
sufficient.) That would require an interpreter to participate in the 
call.  Then you could likely easier jump in with your text-only capability.

> [BA] Is it correct to assume that the language change can occur without negotiation, assuming that the media/language to be used is within the negotiated envelope?
[GH] No. We cannot control the human users. Once they have got support 
to know how to start the conversation they are free to deviate as far as 
they wish, also using other media than they started with. They can say 
"Oh, have you also learnt Welsh! Me too, let us try how far we can use 
it." And they switch mid-call to something that was not at all indicated 
in the humintlang attributes. We cannot force them to renegotiate sdp 
for that switch.

In a formal conference announced to be held in spoken English, there 
might be a chairman stopping such changes, saying "sorry, you are 
leaving us behind, we announced this as a conference in English, so we 
should stick to that".

We have not discussed handling of formal announced conferences. It could 
use the humintlang mechanisms, and then, if it has a fixed set of 
interpreters, it would indicate sending of the corresponding languages 
with grouping. But I assume that CLUE or XCON goes deeper in such 
aspects and we can concentrate on the ad-hoc call.

The RFC 4566 lang specification starts with
"This can be a session-level attribute or a media-level attribute.

       As a session-level attribute, it specifies the default language
       for the session being described."

I suggest that we include something like that in our draft. E.g.
"The goal is to support negotiating the language(s) to use at least initially in the call."

/Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 22 May 2016 13:30:23 +0200

Den 2016-05-20 kl. 21:44, skrev Brian Rosen:

> While I agree there are corner cases simpler mechanisms won’t cover, I 
> think they are rare enough that the complexity introduced in every 
> implementation to allow the corner case to work is not acceptable.
>
> I don’t think either of these proposals is the right way to do 
> grouping, and I don’t want to do grouping at this time, so arguing 
> over which is better is pointless.  I’d probably use RFC5888 as a 
> starting point and define groups of media and languages in the offer, 
> which the answer can select from.
[GH]
When looking at this idea, I first got afraid that it would increase the 
length and complexity of an SDP near infinity, considering that we for 
each media description might have a number of lines for ICE candidates, 
a number of lines for rtcp-feedback announcements and sdpneg 
alternatives for AVP, AVPF, SAVP and SAVPF. Repeating them for 
alternative language groupings does not look attractive.

But getting inspiration from the lip synch grouping in RFC 5888 I see 
that it might be possible to define a notation that does not cost too 
much in SDP length increase to achieve what we want for the simple cases 
we have been discussing.

It would require us to define a new type of grouping in the RFC 5888 style.
Let us call it Language Preference grouping LP.
Something like this:
---------------------------------------------------------------------------------------------------------
x Language Priority (LP)

    An application that receives a session description that contains
    media descriptions that are marked using LP semantics SHOULD make
    efforts to provide language support according to the indicated priority.

    Two directions of Language Priority are defined:
	LPR specifies that the languages indicated for reception in the marked media descriptors are prioritized.
	LPS specifies that the languages indicated for sending in the marked media descriptors are prioritized.

    One or more media descriptions MAY be assigned Language Priority.
    When one media description is given Language Priority, it means that
    the languages indicated in that media description with the indicated direction is strongly preferred
    over languages in other media descriptions with the same direction.

    When more than one media description is given Language Priority, it means
    that there is a strong preference to use the languages in these media
    descriptions and direction simultaneously together.

X.1 Examples of LP
    
  supported by reception of text captioning of the received
  
a=group:LPR 1 2
    m=audio ...
    a=humintlang-send:en
    a=humintlang-recv:en
    a=mid:1
    m=text ...
    a=humintlang-recv:en
    a=mid:2

a=group:LPR 1
a=group:LPS 2
   m=video ...
   a=humintlang-send:ase
   a=humintlang-recv:ase
a=mid:1
a=mid:2
    m=text ...
    a=humintlang-send:en
    a=humintlang-recv:en
a=mid:3

    Note that although the third media stream is not present in the group
    line, it still has to contain a "mid" attribute (mid:3).

-----------------------------------------------------------------------------------------------------
  Would you like this better?

/Gunnar
>
> Brian
>
>> On May 20, 2016, at 3:29 PM, Gunnar Hellström 
>> They do not need to influence the decision on which media to start, 
>> but to which terminal to route the call, and what info to provide to 
>> the answering party and possibly what extra service to link in on the 
>> call.  All these are depending on relations between language in 
>> different media, so I cannot see how we can avoid at least the 
>> proposed minimal form of preference across media and minimal grouping.
>>
>> Was this compromise proposal better than the previous one with 
>> explicit preference value per list of humintlang attributes?
>>
>> /Gunnar
>>>
>>> Brian
>>>
>>>
>>>> used for both a priority indication with the whole sdp as scope, 
>>>> and an indication of grouping.
>>>>
>>>> Discussion: This compromise satisfies most use cases for which 
>>>> global preference and grouping are needed, but has some drawbacks 
>>>> compared to a system with finer graded preferences.
>>>>
>>>> English text, it cannot be seen what is best if it is not possible 
>>>> to provide the combination. There is no clue if it would be 
>>>> reasonably possible to provide only text or only spoken English.
>>>>
>>>>> changes but no agreed wording. That is what I refer to when I say 
>>>>> I want to see what the latest edits ended up in.
>>>>>
>>>>> sufficient to say that it is not enough detailed because it does 
>>>>> not provide directionality.
>>>>>
>>>>> The easiest way is to say that lang should not be used in sdp 
>>>>> where humintlang is used. Is that too drastic?
>>>>>
>>>>> want to have that effect, thus requiring to add the * in most 
>>>>> media specifications. Can we simplify the syntax by having "do not 
>>>>> fail call" as the default and delete the description of the * ? I 
>>>>> suggest that we delete it.
>>>>> If not, the description of the syntax of how the * is included 
>>>>> needs to be inserted in the syntax description in section 6.2 and 
>>>>> an example added.
>>>>>
>>>>> 5. In this part of 6.2:
>>>>> "In cases where the user
>>>>> accessibility needs has strong policy support, so it would be bad 
>>>>> to say that that must wait for another version of the document 
>>>>> when we already now have specified the need.
>>>>>
>>>>> A single digit numeric value on a humintlang attribute represents 
>>>>> a starting priority for the humintlang attributes of the same 
>>>>> medium and direction, with one being the highest priority.  If no 
>>>>> such value is indicated, the value 1 is assumed. The priority 
>>>>> value is increased by a value 0.1 for each humintlang attribute 
>>>>> for the same media and direction.
>>>>> This means that the user prefers to use American sign language 
>>>>> both ways, but as a possible selection on lower preference level 
>>>>> use text both ways.
>>>>> The fact that the humintlang attribute now can have values that 
>>>>> are not language tags needs to be reflected in a few other places 
>>>>> in the draft.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> solution/s that cover all the use cases. I think we can agree 
>>>>>> that going ahead with a simple solutions which is extensible 
>>>>>> covers both of these needs. It allows us to get something out 
>>>>>> there which can be implemented, and it allows us to answer all 
>>>>>> the use cases with extensibility which we will work on next (I 
>>>>>> appreciate this isn’t immediate but it’s favourable to making a 
>>>>>> complex solution now which is too difficult to implement). All 
>>>>>> advice I have received on this has suggested this is the best 
>>>>>> route forward.
>>>>>> Given we’re well over the time that we should have agreed on this 
>>>>>> I suggest we call rough consensus for this here. I understand 
>>>>>> there may be some frustration, but really this method solves for 
>>>>>> both needs and so is sensible.
>>>>>>
>>>>>> Natasha Rooney | Technologist, Web and Internet, W3C & IETF | 
>>>>>> GSMA | [email-masked] | +44 (0) 7730 219 765 | @thisNatasha | 
>>>>>> Skype: [email-masked]
>>>>>>
>>>>>>
>>>>>>> <[email-masked]> wrote:
>>>>>>>
>>>>>>>> In many cases this will be exactly what's desired, while in 
>>>>>>>> some cases there will be extra media that are not used.
>>>>>>>> This gives us something simple that has the best chance of 
>>>>>>>> rapid and wide deployment.  We can then build on this if need be.
>>>>>>> emergency registration mode, so we need to be able to express 
>>>>>>> user needs this way to the degree that they can be served well 
>>>>>>> in emergency calls.
>>>>>>> For that we need to
>>>>>>>>>  This includes providing guidance to the answering part so 
>>>>>>>>> that the answer can be made in the most appropriate language(s).
>>>>>>>>>
>>>>>>>>>  The user needs guidance if it is most appropriate to start 
>>>>>>>>> the conversation in voice, sign language or text or a 
>>>>>>>>> combination of these modalities. If not, the call will start 
>>>>>>>>> with confusion about what is the most efficient means for them 
>>>>>>>>> to communicate.
>>>>>>>>>
>>>>>> only and may be confidential. If they have come to you in error 
>>>>>> you must take no action based on them, nor must you copy or show 
>>>>>> them to anyone; please reply to this email or call +44 207 356 
>>>>>> 0600 and highlight the error.
>>>>>>
>>>>>
>>>>> --

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 23 May 2016 07:57:07 +0200

Randall,

> there will be extra media that are not used.
I do not see how this would work with the use cases that are already in 
the draft. Can you please explain your view?
The sixth paragraph in the introduction says:

" By treating language as another attribute that is negotiated along 
with other aspects of a media stream, it becomes possible to accommodate 
a range of users' needs and called party facilities.*For example,**some 
users may be able to speak several languages, but have a preference*. 
Some called parties may support some of those languages internally but 
require the use of a translation service for others, or may have a 
limited number of call takers able to use certain languages.*Another 
example would be a user who is able to speak but is deaf or 
hard-of-hearing and requires a voice stream plus a text stream (known as 
voice carry over). * Making language a media attribute allows the 
standard session negotiation mechanism to handle this by providing the 
information and mechanism for the endpoints to make appropriate decisions."

Here we have the different cases mentioned that I try to find a suitable 
notation for:

One is "some users may be able to speak several languages, but have a 
preference"

An example can be a user who prefers to receive spoken English, but can 
accept to read English instead as a less preferred alternative.
How would you code that?

The other case is "a user who is able to speak but is deaf or 
hard-of-hearing and requires a voice stream plus
a text stream (known as voice carry over)"

An example can be a user who prefers to receive spoken English, and 
needs to get it complemented with a written
transcription in English.
How would you code that?

I cannot see how the important difference between these cases can be 
expressed with the notation in the current draft.

The different additional notations we have discussed lately can express 
this difference. They have different advantages and shortcomings. I 
slightly prefer the compromise proposal redefining the meaning of the 
asterisk, because of its simplicity and because it works on single 
language level. What is your preference?

/Gunnar

---

From: Brian Rosen <[email-masked]>
Date: Mon, 23 May 2016 09:50:31 -0400

Inline

> On May 23, 2016, at 1:57 AM, Gunnar Hellström <[email-masked]> wrote:
> 
> Randall,
> 
>> I think we can start with what we have now: the offerer offers all media/languages it wants, and the answerer accepts those it supports.  In many cases this will be exactly what's desired, while in some cases there will be extra media that are not used. 
> I do not see how this would work with the use cases that are already in the draft. Can you please explain your view?
> " By treating language as another attribute that is negotiated along with other aspects of a media stream, it becomes possible to accommodate a range of users' needs and called party facilities. For example, some users may be able to speak several languages, but have a preference. Some called parties may support some of those languages internally but require the use of a translation service for others, or may have a limited number of call takers able to use certain languages. Another example would be a user who is able to speak but is deaf or hard-of-hearing and requires a voice stream plus a text stream (known as voice carry over). Making language a media attribute allows the standard session negotiation mechanism to handle this by         providing the information and mechanism for the endpoints to make appropriate decisions."
> 
> 
> Here we have the different cases mentioned that I try to find a suitable notation for:
> 
> One is "some users may be able to speak several languages, but have a preference"
> 
> An example can be a user who prefers to receive spoken English, but can accept to read English instead as a less preferred alternative.
> How would you code that?
This is not an example of “able to speak several languages, but have a preference".  An example of that would be “I know English well, but can manage Spanish, so English or Spanish with a preference for English”. It’s preference of language within one media.

To get what you want you ask for two streams, one text one audio, both in English, and you get more than you need.  The preference is not among media streams, it’s language within a stream.

> 
> The other case is "a user who is able to speak but is deaf or hard-of-hearing and requires a voice stream plus 
> An example can be a user who prefers to receive spoken English, and needs to get it complemented with a written 
Audio english, text English.
No preferences.

> 
> I cannot see how the important difference between these cases can be expressed with the notation in the current draft.
> 
> The different additional notations we have discussed lately can express this difference. They have different advantages and shortcomings. I slightly prefer the compromise proposal redefining the meaning of the asterisk, because of its simplicity and because it works on single language level. What is your preference?
> 
> /Gunnar
> 
>> 
>>>  <mailto:[email-masked]> <mailto:[email-masked]>[email-masked] <mailto:[email-masked]> 
>>>  +46 708 204 288 
>>>

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 23 May 2016 16:56:33 +0200

Brian,

Thanks for a good effort.

Den 2016-05-23 kl. 15:50, skrev Brian Rosen:
> Inline
>
>> On May 23, 2016, at 1:57 AM, Gunnar Hellström 
>>> media/languages it wants, and the answerer accepts those it 
>>> supports.  In many cases this will be exactly what's desired, while 
>>> in some cases there will be extra media that are not used.
>> I do not see how this would work with the use cases that are already 
>> in the draft. Can you please explain your view?
>> with other aspects of a media stream, it becomes possible to 
>> accommodate a range of users' needs and called party facilities.*For 
>> example,**some users may be able to speak several languages, but have 
>> a preference*. Some called parties may support some of those 
>> languages internally but require the use of a translation service for 
>> others, or may have a limited number of call takers able to use 
>> certain languages.*Another example would be a user who is able to 
>> speak but is deaf or hard-of-hearing and requires a voice stream plus 
>> a text stream (known as voice carry over). * Making language a media 
>> attribute allows the standard session negotiation mechanism to handle 
>> this by providing the information and mechanism for the endpoints to 
>> make appropriate decisions."
>>
>>
>> An example can be a user who prefers to receive spoken English, but 
>> can accept to read English instead as a less preferred alternative.
>> How would you code that?
> This is not an example of “able to speak several languages, but have a 
> preference".  An example of that would be “I know English well, but 
> can manage Spanish, so English or Spanish with a preference for 
> English”. It’s preference of language within one media.
[GH] For me it is an example “able to speak several languages, but have 
a preference". For what reason should we make a difference between 
media, when the preference of users can be across media limits. We are 
defining this to satisfy common user needs.
>
> To get what you want you ask for two streams, one text one audio, both 
> in English, and you get more than you need.  The preference is not 
> among media streams, it’s language within a stream.
[GH]We need it to reflect user needs and that is preference among media 
streams.
With your interpretation, we would assign relay services when we do not 
need any. That is waste of resources and causes delays and a bit less 
privacy. That should be avoided.

> Audio english, text English.
[GH] What do you mean that the evaluation rule would be?
Would it be: try to satisfy the highest possible preferred language in 
each direction in all media specifications together?  ( with preference 
only applied between languages in the same media and direction. )

That interpretation would satisfy the grouping need, but not the need 
for preference regardless of media. It is likely more common to have a 
need to indicate preference between languages in different media than a 
need to have two languages/modalities together. But we should satisfy both.

Gunnar

>> The different additional notations we have discussed lately can 
>> express this difference. They have different advantages and 
>> shortcomings. I slightly prefer the compromise proposal redefining 
>> the meaning of the asterisk, because of its simplicity and because it 
>> works on single language level. What is your preference?
>>
>> /Gunnar
>>
>>>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 23 May 2016 12:29:33 -0400

> [GH] For me it is an example “able to speak several languages, but have a preference". For what reason should we make a difference between media, when the preference of users can be across media limits. We are defining this to satisfy common user needs. 
I don’t think we’re treating spoken English as a different language from written English.  Same language, different media.

If that’s not what “some users may be able to speak several languages but have a preference” means, then we need to revisit the use case document.

> [GH]We need it to reflect user needs and that is preference among media streams. 
> With your interpretation, we would assign relay services when we do not need any. That is waste of resources and causes delays and a bit less privacy. That should be avoided. 
I don’t think I am alone in thinking that preference was per media, and not between media.  This effort isn’t designed to extend SDP in ways beyond signaling human language preferences within a media stream.  

Several of us (I’m looking at you Paul) have had conversations on how to signal a request for interpreters (transcoders).  I think we also might need a way to label a stream as a translated version of another stream, in the same or different media.  That’s label, not negotiate, although at some point if you can label it, it can be turned into an offer/answer negotiation.

But that is out of scope of this work group.

> Would it be: try to satisfy the highest possible preferred language in each direction in all media specifications together?  ( with preference only applied between languages in the same media and direction. )
I think that you negotiate language in each stream independently of any other stream.

I don’t think this effort is intended to provide a way to negotiate relationships between streams or media.  It’s just language on a stream.

If our charter intended us to extend SDP to negotiate relationships/grouping between streams, it would have been stated explicitly, and we would have had to discuss why that capability wasn’t a lot more general (not limited to human language issues).

> 
> That interpretation would satisfy the grouping need, but not the need for preference regardless of media. It is likely more common to have a need to indicate preference between languages in different media than a need to have two languages/modalities together. But we should satisfy both.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 May 2016 13:11:46 -0400

> Several of us (I’m looking at you Paul) have had conversations on how to signal a request for interpreters (transcoders).  I think we also might need a way to label a stream as a translated version…

Yes.

> But that is out of scope of this work group.

Yes. That was settled some time ago.

I've been resisting jumping into this conversation because I don't have 
anything new to add. Given the current scope I think it makes sense to 
keep things simple.

I understand that this may turn out to be insufficient for identifying 
the need for interpretation, and for what sort of interpretation. We can 
deal with that if/when we get to it.

	Thanks,
	Paul

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 23 May 2016 22:12:26 +0200

Den 2016-05-23 kl. 19:11, skrev Paul Kyzivat:
>> Several of us (I’m looking at you Paul) have had conversations on how 
>> to signal a request for interpreters (transcoders).  I think we also 
>> might need a way to label a stream as a translated version of another 
>> stream, in the same or different media.  That’s label, not negotiate, 
>> although at some point if you can label it, it can be turned into an 
>> offer/answer negotiation.
>
> Yes.
[GH] it is specified in rfc6497, the t- extension to RFC 5646.

Example     ja-t-it  The content is Japanese, transformed from Italian.

> Yes. That was settled some time ago.
[GH] Yes
>
> I've been resisting jumping into this conversation because I don't 
> have anything new to add. Given the current scope I think it makes 
> sense to keep things simple.
>
> the need for interpretation, and for what sort of interpretation. We 
> can deal with that if/when we get to it.
[GH] The idea is to declare the language needs, not the interpretation 
needs. The declaration shall be in sufficient detail to enable involved 
parties to get the call going efficiently. That includes to be able to 
judge if interpretation is needed. But that depends on what capabilities 
the answering party has initially.
We are at that level of needs, and have been so for some years now. 
(12!) It is time to get it solved and not pushed more into the future.

Thanks
Gunnar

---

From: Brian Rosen <[email-masked]>
Date: Mon, 23 May 2016 16:31:03 -0400

I’m done.

I don’t think we need to do this.  

Chairs can decide what to do.

Brian

> On May 23, 2016, at 4:12 PM, Gunnar Hellström <[email-masked]> wrote:
> 
> 
> 
>> I've been resisting jumping into this conversation because I don't have anything new to add. Given the current scope I think it makes sense to keep things simple. 
>> 
>> I understand that this may turn out to be insufficient for identifying the need for interpretation, and for what sort of interpretation. We can deal with that if/when we get to it. 
> [GH] The idea is to declare the language needs, not the interpretation needs. The declaration shall be in sufficient detail to enable involved parties to get the call going efficiently. That includes to be able to judge if interpretation is needed. But that depends on what capabilities the answering party has initially.
> We are at that level of needs, and have been so for some years now. (12!) It is time to get it solved and not pushed more into the future. 
> 
> Thanks
> Gunnar
>> 
>>     Thanks, 
>>     Paul 
>>

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 23 May 2016 22:56:01 +0200

> I don’t think we’re treating spoken English as a different language from written English.  Same language, different media.
[GH]Yes, we are dealing with language/modality/direction combinations.  
RFC 5646 has a weakness in that it does not differ between spoken and 
written language in the tags, but we compensate for that by placing the 
tag together with the media that is suitable for the modality to be 
used. And it is essential that we deal with language in different 
modalities as separate. Some users are not able to type but can speak.
> I don’t think I am alone in thinking that preference was per media, and not between media.  This effort isn’t designed to extend SDP in ways beyond signaling human language preferences within a med…
[GH] I hoped that I had explained the need sufficiently to realize that 
there is a need to specify priority for language between media.
And since it is a soft indication, not tightly tied to negotiation of 
media usage, you do not need to be afraid if it seems to extend sdp to 
handle priorities between media. It is mainly about how to use the 
negotiated media for language contents.

3GPP TS 122.228 clause 7.5.2 says: "A UE should support negotiation of 
the user's desired language(s) (as defined in IANA [29]) and modalities 
for spoken, signed and written languages. The system should be able to 
negotiate the user's desired language(s) and modalities, per media 
stream and/or session, in order of preference."

ETSI TR 103 201 refers to SLIM in many places. e.g. clause 6.5.4 and 
7.2.3.3.
http://www.etsi.org/deliver/etsi_tr/103200_103299/103201/01.01.01_60/tr_103201v010101p.pdf

These are clear indications that the need is here now, and has been for 
some years.

Did you like the proposal for how to code preference and grouping in RFC 
5888 notation?

/Gunnar