Subject: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-02.txt

From: [email-masked]
Date: Wed, 20 Jul 2016 02:50:43 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Selection of Language for Internet Media of the IETF.

        Title           : Negotiating Human Language in Real-Time Communications
        Author          : Randall Gellens
	Filename        : draft-ietf-slim-negotiating-human-language-02.txt
	Pages           : 17
	Date            : 2016-07-20

Abstract:
   Users have various human (natural) language needs, abilities, and
   preferences regarding spoken, written, and signed languages.  When
   establishing interactive communication ("calls") there needs to be a
   way to negotiate (communicate and match) the caller's language and
   media needs with the capabilities of the called party.  This is
   especially important with emergency calls, where a call can be
   handled by a call taker capable of communicating with the user, or a
   translator or relay operator can be bridged into the call during
   setup, but this applies to non-emergency calls as well (as an
   example, when calling a company call center).

   This document describes the need and a solution using new SDP stream
   attributes.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Randall Gellens <[email-masked]>
Date: Wed, 20 Jul 2016 02:56:00 -0700

Version -02 is now available.  It addresses all comments.  If you 
feel a comment was not correctly addressed, or you have another 
comment, please say so.  The group may want to especially look at 
Section 5 ("The existing 'lang' attribute") to be sure the text 
reflect group consensus.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Round up the usual suspects today.

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 20 Jul 2016 15:01:58 +0200

Randall,

Thanks for rapid and thorough action. Most of my comments and edit 
proposals are well covered in -02

I have some rapid feedback.

1. Check the informational references in 12.2 and delet the ones we do 
not use anymore.

2. In 4 and 6 it is said that we define 'a' media attribute and 'an' SDP 
attribute. Consider if we should say 'two' already there.

3. In 4, the lats paragraph ( the paranthesis ) indicates that 
negotiating multiple languages is not feasible. But firstly, the caller 
is described to have the option to offer multiple alternatives, and some 
feasible use cases use multiple languages to express their preferences. 
So, the draft is contradicting this paragraph. Or I miss something it 
wants to say that also other readers could miss. I suggest to delete the 
last paragraph of 4.

4. In 5, "The group" is used but not defined. And the discussion is not 
needed. "not sufficiently detailed" would be sufficient.

5. In 6.2, I suggested to add a sentence: "

Events during the session may influence which language(s) are used,

and the participants are not strictly bound to only use the declared

languages."

I think it is a valid clarification.

6. As 6.4 I suggest to insert the "Most preferred language" section 
discussed in mail today.

7. I suggested a syntax and examples section, but did not provide 
wording for it. I still think that that is needed. ( especially for 
understanding how the * is used, I remember some comments of 
astonishment that it is hooked on at the end of a language tag. )

8. I agree with the comment during the meeting, that additions to the 
security section with material from the use case document should be done.

These were my immediate reactions. More might come.

Thanks,

Gunnar

Den 2016-07-20 kl. 11:56, skrev Randall Gellens:
> Version -02 is now available.  It addresses all comments.  If you feel 
> a comment was not correctly addressed, or you have another comment, 
> please say so.  The group may want to especially look at Section 5 
> ("The existing 'lang' attribute") to be sure the text reflect group 
> consensus.
>

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

---

From: Randall Gellens <[email-masked]>
Date: Thu, 21 Jul 2016 02:40:24 -0700

Hi Gunar,

At 3:01 PM +0200 7/20/16, Gunnar Hellström wrote:

>  Randall,
>
>  Thanks for rapid and thorough action. Most of 
> my comments and edit proposals are well covered 
> in -02
>
>  1. Check the informational references in 12.2 
> and delet the ones we do not use anymore.

Good idea.  Done.

>
>  2. In 4 and 6 it is said that we define 'a' 
> media attribute and 'an' SDP attribute. 
> Consider if we should say 'two' already there.

I added some clarification here.

>
>  3. In 4, the lats paragraph ( the paranthesis ) 
> indicates that negotiating multiple languages 
> is not feasible. But firstly, the caller is 
> described to have the option to offer multiple 
> alternatives, and some feasible use cases use 
> multiple languages to express their 
> preferences. So, the draft is contradicting 
> this paragraph. Or I miss something it wants to 
> say that also other readers could miss. I 
> suggest to delete the last paragraph of 4.

I reworded the note to be more clear.

>
>  4. In 5, "The group" is used but not defined. 
> And the discussion is not needed. "not 
> sufficiently detailed" would be sufficient.

I reworded the text to be more clear.

>  I think it is a valid clarification.

Fair enough.  I added a note to this effect.

>
>  6. As 6.4 I suggest to insert the "Most 
> preferred language" section discussed in mail 
> today.

I did not see any such thing.  In which email is this?

>
>  7. I suggested a syntax and examples section, 
> but did not provide wording for it. I still 
> think that that is needed. ( especially for 
> understanding how the * is used, I remember 
> some comments of astonishment that it is hooked 
> on at the end of a language tag. )

It is consistent with other uses, such as SIP Accept-Language syntax.

It seems useful to have some examples, so I added a section for this.

>
>  8. I agree with the comment during the meeting, 
> that additions to the security section with 
> material from the use case document should be 
> done.

The test in the security considerations in the 
use cases document is actually a privacy 
consideration, not a security consideration.  I 
added a new section for this.

>  These were my immediate reactions. More might come.

Those can be submitted against WGLC or IETF LC.

>>  Version -02 is now available. It addresses all 
>> comments. If you feel a comment was not 
>> correctly addressed, or you have another 
>> comment, please say so. The group may want to 
>> especially look at Section 5 ("The existing 
>> 'lang' attribute") to be sure the text reflect 
>> group consensus.
>>
>
>  --
>  <mailto:[email-masked]>[email-masked]
>  +46 708 204 288
>
>  _______________________________________________
>  SLIM mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/slim

-------------- Randomly selected tag: ---------------
When a man tells you that he got rich through hard work, ask
him: "Whose?"                                  --Don Marquis

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 21 Jul 2016 14:39:15 +0200

Randall,

thanks for rapid action again,

Den 2016-07-21 kl. 11:40, skrev Randall Gellens:
>>  1. Check the informational references in 12.2 and delet the ones we 
>> do not use anymore.
>
> Good idea.  Done.
Good
>
>>
>>  2. In 4 and 6 it is said that we define 'a' media attribute and 'an' 
>> SDP attribute. Consider if we should say 'two' already there.
>
Good solution
>> negotiating multiple languages is not feasible. But firstly, the 
>> caller is described to have the option to offer multiple 
>> alternatives, and some feasible use cases use multiple languages to 
>> express their preferences. So, the draft is contradicting this 
>> paragraph. Or I miss something it wants to say that also other 
>> readers could miss. I suggest to delete the last paragraph of 4.
>
Yeah, says that we do not bother about selecting multiple languages per 
media, and does not mention our unsolved problem between media.   
Acceptable and understandable now.
>
>>
>>  4. In 5, "The group" is used but not defined. And the discussion is 
>> not needed. "not sufficiently detailed" would be sufficient.
>
5 is good now. Fine.
> Fair enough.  I added a note to this effect.
What you added is on a totally other topic than what I proposed. Yours 
is also relevant.
These additions are only clarifications on use, so maybe not so 
important, but please consider keeping yours and adding my proposal above.

Your says that media may be accepted even if they are not planned to 
contain any agreed language.

Mine says that the negotiation is (of course) not binding for the user 
behavior in the session. If participants negotiated spoken Spanish and 
started in spoken Spanish, but eventually an only English-speaking 
person is include on one side and they all agree on switching to spoken 
English, they are of course free to do so.
> I did not see any such thing.  In which email is this?
It was in the beginning of the thread called "awareness to the user in 
slim real-time draft"
and the proposal was to insert this section:

--------------------------------------------------------------------------------------------------------------------------------------------

6.4 Most preferred language

A mechanism is introduced that provides information on the most 
preferred language among all language indications in the session 
description. This is done in order to provide for a definite outcome of 
the negotiation of language in most cases, and thereby an opportunity 
for the call to start in a fruitful way.

The notation for the most preferred language is a plus ('+') character 
added after the language tag in the value of the corresponding language 
attribute. The notation MAY be used independently on both communication 
directions. The order between this indication and the indication for 
advisory versus required is not relevant.

--------------------------------------------------------------------------------------------------------------------------------------------------
I would be glad to see it included, but because of the discussions on 
this topic, it might be better to continue discussing it separately.
>> astonishment that it is hooked on at the end of a language tag. )
In video, the language tag for American Sign Language should be 'ase'
Otherwise good. Maybe we should add some words of clarification, but I 
think the examples are good and straightforward and clarify the syntax.

Is my impression right about the asterisk, that it is sufficient to have 
one asterisk anywhere in the humintlang attributes in the whole sdp, and 
that is an advice to not fail the call, regardless of what happens with 
the very media and language that the asterisk is hooked on?
>>  8. I agree with the comment during the meeting, that additions to 
>> the security section with material from the use case document should 
>> be done.
>
> The test in the security considerations in the use cases document is 
> actually a privacy consideration, not a security consideration.  I 
That is often one of the three security aspects included in security 
sections.

You could add, "The sdp negotiation SHOULD therefore be kept confident."
> Those can be submitted against WGLC or IETF LC.
Thanks, we are definitively converging.

/Gunnar

---

From: Randall Gellens <[email-masked]>
Date: Thu, 21 Jul 2016 06:29:04 -0700

Hi Gunnar,

I do not believe any further text changes are 
needed.  If you disagree, please raise the issue 
as a WGLC ticket and the group can decide how to 
proceed.

Thanks,

--Randy

At 2:39 PM +0200 7/21/16, Gunnar Hellström wrote:

>>> my comments and edit proposals are well 
>>> covered in -02
>>>
>>>  3. In 4, the lats paragraph ( the paranthesis 
>>> ) indicates that negotiating multiple 
>>> languages is not feasible. But firstly, the 
>>> caller is described to have the option to 
>>> offer multiple alternatives, and some 
>>> feasible use cases use multiple languages to 
>>> express their preferences. So, the draft is 
>>> contradicting this paragraph. Or I miss 
>>> something it wants to say that also other 
>  Yeah, says that we do not bother about 
> selecting multiple languages per media, and 
> does not mention our unsolved problem between 
> media. Acceptable and understandable now.
>
>>
>>>
>  What you added is on a totally other topic than 
> what I proposed. Yours is also relevant.
>  These additions are only clarifications on use, 
> so maybe not so important, but please consider 
> keeping yours and adding my proposal above.
>
>  Your says that media may be accepted even if 
> they are not planned to contain any agreed 
> language.
>
>  Mine says that the negotiation is (of course) 
> not binding for the user behavior in the 
> session. If participants negotiated spoken 
> Spanish and started in spoken Spanish, but 
> eventually an only English-speaking person is 
> include on one side and they all agree on 
> switching to spoken English, they are of course 
> free to do so.
>
>>
>>>
>  It was in the beginning of the thread called 
> "awareness to the user in slim real-time draft"
>  A mechanism is introduced that provides 
> information on the most preferred language 
> among all language indications in the session 
> description. This is done in order to provide 
> for a definite outcome of the negotiation of 
> language in most cases, and thereby an 
> opportunity for the call to start in a fruitful 
> way.
>
>  The notation for the most preferred language is 
> a plus ('+') character added after the language 
> tag in the value of the corresponding language 
> attribute. The notation MAY be used 
> independently on both communication directions. 
> The order between this indication and the 
> indication for advisory versus required is not 
> relevant.
>
> 
>  I would be glad to see it included, but because 
> of the discussions on this topic, it might be 
> better to continue discussing it separately.
>
>>>
>>> some comments of astonishment that it is 
>>> hooked on at the end of a language tag. )
>>>
>  Otherwise good. Maybe we should add some words 
> of clarification, but I think the examples are 
> good and straightforward and clarify the syntax.
>
>
>  Is my impression right about the asterisk, that 
> it is sufficient to have one asterisk anywhere 
> in the humintlang attributes in the whole sdp, 
> and that is an advice to not fail the call, 
> regardless of what happens with the very media 
> and language that the asterisk is hooked on?
>
>>
>>>  8. I agree with the comment during the 
>>> meeting, that additions to the security 
>>> section with material from the use case 
>>> document should be done.
>>>
>>
>  That is often one of the three security aspects 
> included in security sections.
>
>>>>  Version -02 is now available. It addresses 
>>>> all comments. If you feel a comment was not 
>>>> comment, please say so. The group may want 
>>>> to especially look at Section 5 ("The 
>>>> existing 'lang' attribute") to be sure the 
>>>> text reflect group consensus.
>>>>
>>>
>>>  --
>>> <mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>[email-masked]
>>>  +46 708 204 288
>>>
>>>  <mailto:[email-masked]>[email-masked]
>>> 
>>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>>
>>
>>
>
>  --

-------------- Randomly selected tag: ---------------
All generalizations are false, including this one.

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 21 Jul 2016 15:53:07 +0200

Den 2016-07-21 kl. 15:29, skrev Randall Gellens:
> Hi Gunnar,
>
> I do not believe any further text changes are needed.  If you 
> disagree, please raise the issue as a WGLC ticket and the group can 
> decide how to proceed.
You should correct the language tag in the example for American Sign 
Language in video .  it is 'ase' , not 'sgn-US' ( sgn-US was used before 
but was depreciated in 2009 )

And while you are in that section, I suggest that you add an example for 
text as well so that we have representation of all media that have 
implicit modalities.

m=text 45020 RTP/AVP 103 104
a=humintlang-send:gr
a=humintlang-recv:gr

Please also answer my question below on use of the asterisk.

Thanks,
Gunnar

>>>>  1. Check the informational references in 12.2 and delet the ones 
>>>> we do not use anymore.
>>>>
>>>
>>>  Good idea. Done.
>>>
>>  Good
>>
>>>
>>>>
>>>>  2. In 4 and 6 it is said that we define 'a' media attribute and 
>>>> 'an' SDP attribute. Consider if we should say 'two' already there.
>>>>
>>>
>>  Yeah, says that we do not bother about selecting multiple languages 
>> per media, and does not mention our unsolved problem between media. 
>>>>  4. In 5, "The group" is used but not defined. And the discussion 
>>>> is not needed. "not sufficiently detailed" would be sufficient.
>>>>
>>>
>>  What you added is on a totally other topic than what I proposed. 
>> Yours is also relevant.
>>  Mine says that the negotiation is (of course) not binding for the 
>> user behavior in the session. If participants negotiated spoken 
>> Spanish and started in spoken Spanish, but eventually an only 
>> English-speaking person is include on one side and they all agree on 
>> switching to spoken English, they are of course free to do so.
>>
>>>
>>>>
>>>>  6. As 6.4 I suggest to insert the "Most preferred language" 
>>>> section discussed in mail today.
>>>>
>>>
>>  It was in the beginning of the thread called "awareness to the user 
>> in slim real-time draft"
>> description. This is done in order to provide for a definite outcome 
>> of the negotiation of language in most cases, and thereby an 
>> opportunity for the call to start in a fruitful way.
>>
>>  The notation for the most preferred language is a plus ('+') 
>> character added after the language tag in the value of the 
>> corresponding language attribute. The notation MAY be used 
>> independently on both communication directions. The order between 
>> this indication and the indication for advisory versus required is 
>> not relevant.
>>
>>
>>  I would be glad to see it included, but because of the discussions 
>> on this topic, it might be better to continue discussing it separately.
>>
>>>>
>>  Otherwise good. Maybe we should add some words of clarification, but 
>> I think the examples are good and straightforward and clarify the 
>> syntax.
>>
>>
>>  Is my impression right about the asterisk, that it is sufficient to 
>> have one asterisk anywhere in the humintlang attributes in the whole 
>> sdp, and that is an advice to not fail the call, regardless of what 
>> happens with the very media and language that the asterisk is hooked on?
>>
>>>
>>>> the security section with material from the use case document 
>>>> should be done.
>>>>
>>>
>>>  The test in the security considerations in the use cases document 
>>> is actually a privacy consideration, not a security consideration. I

---

From: Randall Gellens <[email-masked]>
Date: Thu, 21 Jul 2016 07:38:43 -0700

At 3:53 PM +0200 7/21/16, Gunnar Hellström wrote:

>> needed.  If you disagree, please raise the 
>> issue as a WGLC ticket and the group can 
>> decide how to proceed.
>  You should correct the language tag in the 
> example for American Sign Language in video . 
> it is 'ase' , not 'sgn-US' ( sgn-US was used 
> before but was depreciated in 2009 )

My apologies, I looked in an outdated version of 
the IANA registry by accident.  I was actually 
surprised to see it listed as 'sgn-US' rather 
than 'ase' ('ase' was listed as a different 
spoken language).

>
>  And while you are in that section, I suggest 
> that you add an example for text as well so 
> that we have representation of all media that 
> have implicit modalities.
>

OK.

>>>>>   Thanks for rapid and thorough action. Most 
>>>>> of my comments and edit proposals are well 
>>>>> covered in -02
>>>>>
>>>>>   1. Check the informational references in 
>>>>> 12.2 and delet the ones we do not use 
>>>>> anymore.
>>>>>
>>>>
>>>>   Good idea. Done.
>>>>
>>>   Good
>>>
>>>>
>>>>>
>>>>>   2. In 4 and 6 it is said that we define 
>>>>> 'a' media attribute and 'an' SDP attribute. 
>>>>>   3. In 4, the lats paragraph ( the 
>>>>> paranthesis ) indicates that negotiating 
>>>>> multiple languages is not feasible. But 
>>>>> firstly, the caller is described to have 
>>>>> the option to offer multiple alternatives, 
>>>>> and some feasible use cases use multiple 
>>>>> languages to express their preferences. So, 
>>>>> the draft is contradicting this paragraph. 
>>>>> Or I miss something it wants to say that 
>>>>> also other readers could miss. I suggest to 
>>>>> delete the last paragraph of 4.
>>>>>
>>>>
>>>>>   4. In 5, "The group" is used but not 
>>>>> defined. And the discussion is not needed. 
>>>>> "not sufficiently detailed" would be 
>>>>> sufficient.
>>>>>
>>>>
>>>   What you added is on a totally other topic 
>>> than what I proposed. Yours is also relevant.
>>>   These additions are only clarifications on 
>>> use, so maybe not so important, but please 
>>> consider keeping yours and adding my proposal 
>>> above.
>>>
>>>   Mine says that the negotiation is (of 
>>> course) not binding for the user behavior in 
>>> the session. If participants negotiated 
>>> spoken Spanish and started in spoken Spanish, 
>>> but eventually an only English-speaking 
>>> person is include on one side and they all 
>>> agree on switching to spoken English, they 
>>> are of course free to do so.
>>>
>>>>
>>>>>
>>>>> preferred language" section discussed in 
>>>>> mail today.
>>>>>
>>>>
>>>   The notation for the most preferred language 
>>> is a plus ('+') character added after the 
>>> language tag in the value of the 
>>> corresponding language attribute. The 
>>> notation MAY be used independently on both 
>>> communication directions. The order between 
>>> this indication and the indication for 
>>>   I would be glad to see it included, but 
>>> because of the discussions on this topic, it 
>>> might be better to continue discussing it 
>>> separately.
>>>
>>>>>
>>>>>   7. I suggested a syntax and examples 
>>>>> section, but did not provide wording for 
>>>>> it. I still think that that is needed. ( 
>>>>> especially for understanding how the * is 
>>>>> used, I remember some comments of 
>>>   Otherwise good. Maybe we should add some 
>>> words of clarification, but I think the 
>>> examples are good and straightforward and 
>>> clarify the syntax.
>>>
>>>
>>>   Is my impression right about the asterisk, 
>>> that it is sufficient to have one asterisk 
>>> anywhere in the humintlang attributes in the 
>>> whole sdp, and that is an advice to not fail 
>>> the call, regardless of what happens with the 
>>> very media and language that the asterisk is 
>>> hooked on?

Yes, any use of the asterisk in the SDP means a 
preference to not fail the call.  Omitting the 
asterisk from all of the SDP indicates a 
preference to fail the call.  There is no 
requirement to fail the call regardless.

>>>>   The test in the security considerations in 
>>>> the use cases document is actually a privacy 
>>>> consideration, not a security consideration. 
>>>> I added a new section for this.
>>>>
>>>   That is often one of the three security 
>>> aspects included in security sections.
>>>
>>>>>>   Version -02 is now available. It 
>>>>>> addresses all comments. If you feel a 
>>>>>> comment was not correctly addressed, or 
>>>>>> you have another comment, please say so. 
>>>>>> The group may want to especially look at 
>>>>>> Section 5 ("The existing 'lang' 
>>>>>> attribute") to be sure the text reflect 
>>>>>> group consensus.
>>>>>>
>>>>>
>>>>>   --

-------------- Randomly selected tag: ---------------
We don't see things as they are; we see things as we are.
                                            --Anais Nin