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

From: Natasha Rooney <[email-masked]>
Date: Fri, 13 May 2016 17:44:59 +0000

Hi all!

I hope everyone is well and enjoying some short vacations throughout May. In this email we would like to discuss a route towards getting rough consensus for draft-ietf-slim-negotiating-human-language.

In Buenos Aires, we discussed the completeness of draft-ietf-slim-negotiating-human-language.  In particular, we discussed advancing the draft as it is versus adding mechanisms for grouping and absolute priority.  Most participants (with one objection) at the meeting believed the draft to be sufficient for deployment now, that it is better to start with a simple mechanism that will be easier to implement and see earlier use, and that additional complexity can be added later (in an extension or -bis document) if we find we need grouping, absolute priority, or other advanced features.

Therefore, the chairs would like to ask SLIM members on the list to respond to this suggestion: please let us know if you are happy with this to proceed or not and if not, why.

Thanks everyone!

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

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: Fri, 13 May 2016 20:27:41 +0200

We also discussed another issue that we need to decide on before moving on.

I think the conclusion on how the current lang attribute in sdp can be 
used, that is currently documented in the draft, is not what was 
intended with the attribute.

We collected history about the attribute with the intention to sort out 
the issue.

I suggest that that action is followed up with a discussion in mmusic 
before we move on.

The work with 4566bis has accepted an improved description of the 
attribute, but it would be good to have a common view already about the 
use according to RFC 4566.

Regards

Gunnar

Den 2016-05-13 kl. 19:44, skrev Natasha Rooney:
> Hi all!
>
> I hope everyone is well and enjoying some short vacations throughout 
> May. In this email we would like to discuss a route towards getting 
> rough consensus for draft-ietf-slim-negotiating-human-language.
>
> In Buenos Aires, we discussed the completeness of 
> draft-ietf-slim-negotiating-human-language.  In particular, we 
> discussed advancing the draft as it is versus adding mechanisms for 
> grouping and absolute priority.  Most participants (with one 
> objection) at the meeting believed the draft to be sufficient for 
> deployment now, that it is better to start with a simple mechanism 
> that will be easier to implement and see earlier use, and that 
> additional complexity can be added later (in an extension or -bis 
> document) if we find we need grouping, absolute priority, or other 
> advanced features.
>
> Therefore, the chairs would like to ask SLIM members on the list to 
> respond to this suggestion: please let us know if you are happy with 
> this to proceed or not and if not, why.
>
> Thanks everyone!
>
> 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]>
>
>
> 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.
>
>
>
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

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

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 13 May 2016 22:11:19 +0200

Thanks Natasha for pushing us to action,

I am not happy to move on before we have a solution to the use cases.

I do not understand why we mention that the languages are listed in 
preference order within a media description, but do not mention what 
relation there is in preference between languages in different media 
descriptions. The need for preference ordering can appear between media 
as well as within a medium.

And we need to have a way to indicate the difference between requiring 
to use two or more lanuage/modalities together versus providing them as 
selectable options. If we do not sort this out, we cause the same 
confusion as we have around the current lang attribute.  We were 
discussing solutions to part of this on April 10 in the list, but had no 
final conclusion on suitable wording that would cause less confusion 
than current RFC 4566. That discussion needs to be concluded.

Can we start with getting to see the current wording of the sections 
under discussion on April 10?

Thanks,

Gunnar

---

From: Randall Gellens <[email-masked]>
Date: Sat, 14 May 2016 16:06:21 -0700

I believe the draft can proceed as is.

At 5:44 PM +0000 5/13/16, Natasha Rooney wrote:

>  Hi all!
>
>  I hope everyone is well and enjoying some short vacations 
> throughout May. In this email we would like to discuss a route 
> towards getting rough consensus for 
> draft-ietf-slim-negotiating-human-language.
>
> respond to this suggestion: please let us know if you are happy 
> with this to proceed or not and if not, why.
>
>
>  Thanks everyone!
>
>  Natasha
>
>
>  Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA 
> | <mailto:[email-masked]>[email-masked] | +44 (0) 7730 219 765 
> | @thisNatasha | Skype: <mailto:[email-masked]>[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.
>
>

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Algorhyme
       I think that I shall never see
       a graph more lovely than a tree.
       A tree whose crucial property
       is loop-free connectivity.
       A tree that must be sure to span
       so packet can reach every LAN.
       First, the root must be selected.
       By ID, it is elected.
       Least-cost paths from root are traced.
       In the tree, these paths are placed.
       A mesh is made by folks like me,
       then bridges find a spanning tree.
                      --Radia Perlman

---

From: Randall Gellens <[email-masked]>
Date: Sat, 14 May 2016 16:07:54 -0700

I believe that, at this point, this is a 
distraction and not important.  We are defining 
new SDP attributes.

At 8:27 PM +0200 5/13/16, Gunnar Hellström wrote:

>  I think the conclusion on how the current lang 
> attribute in sdp can be used, that is currently 
> documented in the draft, is not what was 
>  We collected history about the attribute with 
> the intention to sort out the issue.
>
>  I suggest that that action is followed up with 
> a discussion in mmusic before we move on.
>
>  The work with 4566bis has accepted an improved 
> description of the attribute, but it would be 
> good to have a common view already about the 
>>  I hope everyone is well and enjoying some 
>> short vacations throughout May. In this email 
>> we would like to discuss a route towards 
>> getting rough consensus for 
>>  In Buenos Aires, we discussed the completeness 
>> of draft-ietf-slim-negotiating-human-language. 
>> In particular, we discussed advancing the 
>> draft as it is versus adding mechanisms for 
>> grouping and absolute priority. Most 
>> participants (with one objection) at the 
>> meeting believed the draft to be sufficient 
>> for deployment now, that it is better to start 
>> with a simple mechanism that will be easier to 
>> implement and see earlier use, and that 
>> additional complexity can be added later (in 
>> an extension or -bis document) if we find we 
>> need grouping, absolute priority, or other 
>> advanced features.
>>
>>  Therefore, the chairs would like to ask SLIM 
>> members on the list to respond to this 
>> suggestion: please let us know if you are 
>> happy with this to proceed or not and if not, 
>> why.
>>
>>
>>  Thanks everyone!
>>
>>  Natasha
>>
>>
>> <mailto:[email-masked]>[email-masked] | 
>> +44 (0) 7730 219 765 | @thisNatasha | Skype: 
>> <>[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.
>>
>>
>>
>>  <mailto:[email-masked]>[email-masked]
>> 
>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>
>
>  --
>  <mailto:[email-masked]>[email-masked]
>  +46 708 204 288
>

-------------- Randomly selected tag: ---------------
The way to make a small fortune in the commodities market is to start
with a large fortune.

---

From: Randall Gellens <[email-masked]>
Date: Sat, 14 May 2016 16:10:49 -0700

I think the draft is sufficient for us to move 
forward.  If we later find we need to describe 
"preference between languages in different media 
descriptions" or "requiring to use two or more 
language/modalities together" then we can define 
mechanisms to do so, either as an extension or in 
a -bis document.

t 10:11 PM +0200 5/13/16, Gunnar Hellström wrote:

>  I do not understand why we mention that the 
> languages are listed in preference order within 
> a media description, but do not mention what 
> relation there is in preference between 
> languages in different media descriptions. The 
> need for preference ordering can appear between 
> media as well as within a medium.
>
>  And we need to have a way to indicate the 
> difference between requiring to use two or more 
> lanuage/modalities together versus providing 
> them as selectable options. If we do not sort 
> this out, we cause the same confusion as we 
> have around the current lang attribute. We were 
> discussing solutions to part of this on April 
> 10 in the list, but had no final conclusion on 
> suitable wording that would cause less 
> confusion than current RFC 4566. That 
> discussion needs to be concluded.
>
>  Can we start with getting to see the current 
> wording of the sections under discussion on 
> April 10?
>
>  Thanks,
>
>  Gunnar
>
>
>
>

-------------- Randomly selected tag: ---------------
Trying to be happy is like trying to build a machine for which
the only specification is that it should run noiselessly.

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 15 May 2016 14:40:17 -0400

On 5/14/16 7:10 PM, Randall Gellens wrote:
> I think the draft is sufficient for us to move forward.  If we later
> find we need to describe "preference between languages in different
> media descriptions" or "requiring to use two or more language/modalities
> together" then we can define mechanisms to do so, either as an extension
> or in a -bis document.

I am ok with this approach *if* we agree that there is no implicit 
assumption about preference. Absent anything else, I think we must 
assume that the offerer wants *all* m-lines in the offer to be accepted, 
and intends to use them all.

My fear is that implementers will make some assumption, but they won't 
all make the same assumption. Then there are surprises when something 
unexpected happens.

Alternately, we could make a particular assumption and state it clearly.

	Thanks,
	Paul

>> descriptions. The need for preference ordering can appear between
>>  And we need to have a way to indicate the difference between
>> requiring to use two or more lanuage/modalities together versus
>> providing them as selectable options. If we do not sort this out, we
>> cause the same confusion as we have around the current lang attribute.
>> We were discussing solutions to part of this on April 10 in the list,
>> but had no final conclusion on suitable wording that would cause less
>> confusion than current RFC 4566. That discussion needs to be concluded.
>>
>>> <mailto:[email-masked]>[email-masked] | +44 (0) 7730 219 765 |
>>> @thisNatasha | Skype: <>[email-masked]
>>>
>>>

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 16 May 2016 00:35:40 +0200

>> together" then we can define mechanisms to do so, either as an extension
The need is described in the use cases.

Lacking any other mechanism for describing the preference between media, 
I proposed introducing the q-value similar to how that is used for SIP 
media tags.

I and others were concerned about the introduced complexity by that 
mechanism.

Here is another proposal:
Let the humintlang attribute position in each media specification 
represent a relative preference, lower the later it appears within the 
media specification.
Let the first position in each media specification represent the same 
preference.
Insert language subtag zxx "No Linguistic content" before humintlang 
attributes for languages of lower preference than the ones in earlier 
positions in other media specifications.

Example

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.

Even if this is accepted for the preference notation between media, we 
still need a notation for differentiating between using two languages in 
different media  versus providing a selection between two 
language/modality combinations in different media.

Requiring to use more than one medium in the same direction is an 
unusual case, so that should not be the default.

We could have the notation that if two languages are specified at the 
same preference level but in different media, then they are both 
required. That would mean that a selection always must be specified with 
a difference in preference.

> assume that the offerer wants *all* m-lines in the offer to be 
> accepted, and intends to use them all.
Yes, the medium is uíndicated as wanted by including its m-line. The 
humintlang attribute just specifies how the users prefer to use the media.
> Alternately, we could make a particular assumption and state it clearly.
Yes, we are aware of the problem now, so we should be able to formulate 
clear rules.
Randall and I discussed in the list some of the wording for getting the 
intentions more clearly specified. I would like to see the resulting 
wording.
>     Paul
Thanks
Gunnar

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 15 May 2016 16:49:17 -0600

> with lower preference accept to type and read English.

What does this have to do with the meaning of 'zxx' as "No linguistic 
content", or for that matter "Not applicable" (the other Description 
field currently associated with 'zxx')?

BCP 47 subtags are not to be redefined as application-specific sentinel 
values. If you need a mechanism to rank humintlang attributes by 
priority or preference, create a mechanism to do that; don't make up 
your own meanings for subtags.

The main reason I monitor this group is to help ensure that SLIM becomes 
a proper application of BCP 47, and doesn't try to bastardize it in some 
way. This would be an example of the latter.

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

---

From: Randall Gellens <[email-masked]>
Date: Sun, 15 May 2016 16:59:08 -0700

At 2:40 PM -0400 5/15/16, Paul Kyzivat wrote:

>  I am ok with this approach *if* we agree that 
> there is no implicit assumption about 
> preference. Absent anything else, I think we 
> must assume that the offerer wants *all* 
> m-lines in the offer to be accepted, and 
> intends to use them all.

I don't think we can assume the offerer intends 
to use them all, but that's OK.  Possibly some 
media streams get established that are not used 
(because more preferred streams were also set up).

>
>  My fear is that implementers will make some 
> assumption, but they won't all make the same 
> assumption. Then there are surprises when 
> something unexpected happens.

As long as we keep it simple, we'll be OK.  If 
the answer contains all media and languages from 
the offer that the answerer supports, the user 
gets to use whichever he or she wants.

-------------- Randomly selected tag: ---------------
Q:  Why do mountain climbers rope themselves together?
A:  To prevent the sensible ones from going home.

---

From: Randall Gellens <[email-masked]>
Date: Sun, 15 May 2016 17:01:09 -0700

I do not think we need the complexity of 
preference between media.  Let's start out with 
the simplest approach.  We can add complexity 
later if we find we need it.

At 12:35 AM +0200 5/16/16, Gunnar Hellström wrote:

>  Lacking any other mechanism for describing the 
> preference between media, I proposed 
> introducing the q-value similar to how that is 
> used for SIP media tags.
>
>  I and others were concerned about the 
> introduced complexity by that mechanism.
>
>  Let the humintlang attribute position in each 
> media specification represent a relative 
> preference, lower the later it appears within 
> the media specification.
>  Let the first position in each media 
> specification represent the same preference.
>  Insert language subtag zxx "No Linguistic 
> content" before humintlang attributes for 
> languages of lower preference than the ones in 
> earlier positions in other media specifications.
>
>  Example
>
>  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.
>
>  Even if this is accepted for the preference 
> notation between media, we still need a 
> notation for differentiating between using two 
> languages in different media versus providing a 
> selection between two language/modality 
> combinations in different media.
>
>  Requiring to use more than one medium in the 
> same direction is an unusual case, so that 
> should not be the default.
>
>  We could have the notation that if two 
> languages are specified at the same preference 
> level but in different media, then they are 
> both required. That would mean that a selection 
> always must be specified with a difference in 
> preference.
>
>
>
>
>
>>
>  Yes, the medium is uíndicated as wanted by 
> including its m-line. The humintlang attribute 
> just specifies how the users prefer to use the 
> media.
>
>>
>  Yes, we are aware of the problem now, so we 
> should be able to formulate clear rules.
>  Randall and I discussed in the list some of the 
> wording for getting the intentions more clearly 
> specified. I would like to see the resulting 
> wording.
>
>>
>>
>>  Thanks,
>>  Paul
>>
>  Thanks
>  Gunnar
>
>>
>>>>> <mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>[email-masked] 
>>>>> | +44 (0) 7730 219 765 |
>>>>>  @thisNatasha | Skype: <><mailto:[email-masked]>[email-masked]
>>>>>
>>>>>
>>>>> <mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>[email-masked]
>>>>>
>>>>> 
>>>>> <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
>>>>>
>>>>
>>>>  --
>>>> <mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>[email-masked]
>>>>  +46 708 204 288
>>>>

-------------- Randomly selected tag: ---------------
An economist is an expert who will know tomorrow why the things he
predicted yesterday didn't happen today.       --Laurence J. Peter

---

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

> field currently associated with 'zxx')?
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.
>
> BCP 47 subtags are not to be redefined as application-specific 
> sentinel values. If you need a mechanism to rank humintlang attributes 
> by priority or preference, create a mechanism to do that; don't make 
> up your own meanings for subtags.
I do not realize why this use of 'zxx' is not in line with the 
definition of the use of BCP 47 subtags. Is the intention with 'zxx' 
specified somewhere? The name looked useful for me.

There are certainly other possible ways to indicate how a language in 
one media relates in priority to a language in another media. I have 
tried earlier with some hi, med and lo marks, and the q-values. All 
possible, but none elegant.

We could put a number for where the preferences for language in one 
medium starts relative to the others. That is however so close to the 
q-number notation that it probably saves more implementation effort to 
use the q-number notation.

The example would then be:

m=video ...
a=humintlang-send:1;ase
a=humintlang-recv:1;ase

m=text ...
a=humintlang-send:3;en
a=humintlang-recv:3;en

I put here 3 instead of 2 to indicate a clearly lower preference for 
written Ennglish as an alternative.

>
> The main reason I monitor this group is to help ensure that SLIM 
> becomes a proper application of BCP 47, and doesn't try to bastardize 
> it in some way. This would be an example of the latter.
Thanks for watching. Can you explein in some more words why it would not 
be proper to use 'zxx' in a place where the syntax requires a language 
subtag, but we do not have any language content?

---

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

Den 2016-05-16 kl. 02:01, skrev Randall Gellens:

> I do not think we need the complexity of preference between media.  
> Let's start out with the simplest approach.  We can add complexity 
I see the clear need especially for marking a possible but much less 
preferred alternative in another media as a contrast against 'select 
whichever you want among the alternatives in different media'.
That would signal to the callee to make efforts to satisfy the preferred 
case but a good guidance on what to do if that seems impossible to 
achieve. I don't want to wait when we already now see the need.

I wonder if the problem to get to an agreement is that I see the 
language indication as guidance to the answering part on what they shall 
use media for rather than a base for just acceptance to connect media.

Can you accept the view that the language/modality indication can be 
used for routing to the proper person with the right language competence 
and as a guide to that person for what modality and language to answer 
the call?

/Gunnar

>>  Lacking any other mechanism for describing the preference between 
>> media, I proposed introducing the q-value similar to how that is used 
>> for SIP media tags.
>>
>> represent a relative preference, lower the later it appears within 
>> the media specification.
>>  Let the first position in each media specification represent the 
>> same preference.
>>  Would mean that the user prefers to use American sign language but 
>> can with lower preference accept to type and read English.
>>
>>  Even if this is accepted for the preference notation between media, 
>> we still need a notation for differentiating between using two 
>> languages in different media versus providing a selection between two 
>>  We could have the notation that if two languages are specified at 
>> the same preference level but in different media, then they are both 
>> required. That would mean that a selection always must be specified 
>> with a difference in preference.
>>
>>
>>
>>
>>
>>>
>>>  My fear is that implementers will make some assumption, but they 
>>> won't all make the same assumption. Then there are surprises when 
>>  Yes, we are aware of the problem now, so we should be able to 
>> formulate clear rules.
>>  Randall and I discussed in the list some of the wording for getting 
>> the intentions more clearly specified. I would like to see the 
>> resulting wording.
>>
>>>
>>>
>>>  Thanks,
>>>  Paul
>>>
>>  Thanks
>>  Gunnar
>>
>>>
>>>>>> throughout
>>>>>> only

---

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

On May 15, 2016, at 11:40, Paul Kyzivat <[email-masked]> wrote:
> 
> I am ok with this approach *if* we agree that there is no implicit assumption about preference. Absent anything else, I think we must assume that the offerer wants *all* m-lines in the offer to be accepted, and intends to use them all.
> 
> My fear is that implementers will make some assumption, but they won't all make the same assumption. Then there are surprises when something unexpected happens.

[BA] I agree that this is very important. At worst, if we assume the offerer wants all m-lines, we might end up with more modes/languages than we need, with no indication of preference. This might lead to some fumbling (e.g. peers might need to figure out which modes/languages to use) but communications can be established, and having everything available might actually be an advantage in some cases (e.g. troubles with audio or bad video so text is needed even though it is lower preference).