Subject: [Slim] Negotiation issue in draft-ietf-slim-negotiating-human-language

From: Bernard Aboba <[email-masked]>
Date: Thu, 15 Feb 2018 07:53:30 -0500

As noted in the below thread, multiple ambiguities need to be resolved in
draft-ietf-slim-negotiating-human-language:
https://www.ietf.org/mail-archive/web/slim/current/msg01300.html

In the SDP codec negotiation, multiple codecs are offered, and the answerer
selects among them, with the first codec being the preferred one.  Codecs
not present in the Offer cannot be included in the Answer.

The model proposed in draft-ietf-slim-negotiating-human-language does not
conform to this paradigm, allowing languages not present in the Offer to be
presented in the Answer, and also (previously) having an ambiguity about
whether a single language or multiple languages can be included in an
Answer.

Gunnar has proposed language to address this.  Any reason not to accept his
proposal?

---

From: "Randall Gellens" <[email-masked]>
Date: Thu, 15 Feb 2018 14:44:09 -0800

> whether a single language or multiple languages can be included in an

There are important reasons why we need to permit an answer to 
potentially select a language that was not included in the offer, e.g., 
in an emergency services case, if the PSAP does not support any of the 
languages in the offer, it still wants the call to proceed, and will 
indicate the language it supports.  (In some cases this is likely to 
result in a more or less comprehensible communication stream, e.g., in 
some Scandinavian countries where cross-border languages may be 
different enough not to be included in an offer but mutually 
comprehensible to an extent, while in some cases it may result in 
incomprehensible communication that is still of value to the PSAP in 
responding to the emergency.)

> Gunnar has proposed language to address this.  Any reason not to 

Which language is this?  Can you copy the text or point to the message?

--Randall

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 16 Feb 2018 08:39:32 +0100

Den 2018-02-15 kl. 23:44, skrev Randall Gellens:
> potentially select a language that was not included in the offer, 
> e.g., in an emergency services case, if the PSAP does not support any 
> of the languages in the offer, it still wants the call to proceed, and 
> will indicate the language it supports.  (In some cases this is likely 
> to result in a more or less comprehensible communication stream, e.g., 
> in some Scandinavian countries where cross-border languages may be 
I find that the changes to version -23 prepared by Randall and provided 
in this archive mail are good:
https://www.ietf.org/mail-archive/web/slim/current/msg01289.html

That version allows answers to contain languages not contained in the 
offer (that was already allowed and well specified in version -23),
and allows multiple languages per media and direction in the answer.

I think both of these conditions are good and important for successful 
use of the draft.
We need to imagine all kinds of feasible applications, e.g. the decision 
on including interpreting resources taken by the offeror after receiving 
the answer. That calls for providing the full and true picture about the 
supported languages in the answer.

So, I repeat my comment from 
https://www.ietf.org/mail-archive/web/slim/current/msg01297.html
"I find the diff you sent to be good, and also version -23 solving all 
other issues in a good way. So, I vote for applying your proposed 
changes on -23 and hope that that can be the final version."

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

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

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 17 Feb 2018 03:36:57 +0000

Yes, the proposed changes seem good. One question: is there enough
normative language about adding languages to an Answer that were not in the
Offer? For example, can this only occur if the Answerer has no languages in
common with the Offerer? Or can an Answerer add any languages(s) they would
put into an Offer if roles were reversed?

On Fri, Feb 16, 2018 at 02:39 Gunnar Hellström <[email-masked]>
wrote:

> I find that the changes to version -23 prepared by Randall and provided in
> this archive mail are good:
> I think both of these conditions are good and important for successful use
> of the draft.
> other issues in a good way. So, I vote for applying your proposed changes
> on -23 and hope that that can be the final version."
>
> Gunnar
>
>
>
> --Randall
>
> [email-masked]
> +46 708 204 288
>
>

---

From: "Randall Gellens" <[email-masked]>
Date: Sat, 17 Feb 2018 01:52:02 -0800

Hi Bernard,

Putting a language in an answer that was not in the offer is an unusual 
case (as the text says).  I don’t think we need to add more text 
(normative or descriptive) about it.

—Randall

On 16 Feb 2018, at 19:36, Bernard Aboba wrote:

>> changes

--Randall

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 17 Feb 2018 23:20:58 +0100

I agree with Randall. No more normative or descriptive language is 
needed. There is already a warning against providing language 
indications that will be hard to match. That will happen if you decide 
to answer with a language that was not in the offer. But it is better 
than answering with no language indication and it indicates how you 
might answer the call.

There is however one small adjustment to do. The sentence about having 
the languages in preference order in the lists should be included also 
in the paragraph about the answer in 5.2.  Or it could be pulled out 
from the paragraph about the offer and put in a common paragraph below 
both paragraphs about the offer and the answer. And the lists should be 
in plural in the sentence.
Here the sentence is attached last in the paragraph about the answer:
-----------------------------5.2 paragraph about the answer, with new 
sentence attached last------------------------------------------

  In an answer, 'hlang-send' is a list of one or more languages the answerer might send if
    using the media for language (which in most cases contains one or more of the
    languages in the offer's 'hlang-recv'), and 'hlang-recv' is a list of one or more of the
    languages the answerer is prepared to receive if using the media for
    language (which in most cases contains one or more of the languages in the offer's
    'hlang-send'). The lists of languages are in preference order (first is most
    preferred).

----------------------------------------------------------------------------------------------------------------------------------------------------------
/Gunnar

Den 2018-02-17 kl. 10:52, skrev Randall Gellens:
>
> Hi Bernard,
>
> Putting a language in an answer that was not in the offer is an 
> unusual case (as the text says). I don’t think we need to add more 
> text (normative or descriptive) about it.
>
> —Randall
>
>     normative language about adding languages to an Answer that were
>     not in the Offer? For example, can this only occur if the Answerer
>     has no languages in common with the Offerer? Or can an Answerer
>     add any languages(s) they would put into an Offer if roles were
>     reversed?
>
>     On Fri, Feb 16, 2018 at 02:39 Gunnar Hellström
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>
>         I find that the changes to version -23 prepared by Randall and
>         provided in this archive mail are good:
>         That version allows answers to contain languages not contained
>         in the offer (that was already allowed and well specified in
>         version -23),
>         I think both of these conditions are good and important for
>         successful use of the draft.
>         We need to imagine all kinds of feasible applications, e.g.
>         the decision on including interpreting resources taken by the
>         offeror after receiving the answer. That calls for providing
>         the full and true picture about the supported languages in the
>         answer.
>
>         "I find the diff you sent to be good, and also version -23
>         solving all other issues in a good way. So, I vote for
>         applying your proposed changes on -23 and hope that that can
>         be the final version."
>
>         Gunnar
>>
>>
>>         --Randall
>>
>>         [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>
>         +46 708 204 288
>
>
>
> --Randall
>
>
>

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 18 Feb 2018 10:27:44 -0500

Gunnar said:

"That will happen if you decide to answer with a language that was not in
the offer. But it is better than answering with no language indication and
it indicates how you might answer the call."

[BA] I understand how an Answerer could respond only with language(s) not
in the Offer.  But if the Answerer can support some of the offered
languages, what are the restrictions on non-offered languages?
Can an Answerer put a non-offered language first in the preference list and
an offered language in a less preferred position?  Should it be able to
include a non-offered language at all?  If you offer English and
Swedish and receive an Answer with Swahili and Swedish, that could result
in confusion at best.

On Sat, Feb 17, 2018 at 5:20 PM, Gunnar Hellström <
[email-masked]> wrote:

> I agree with Randall. No more normative or descriptive language is needed.
> There is already a warning against providing language indications that will
> be hard to match. That will happen if you decide to answer with a language
> that was not in the offer. But it is better than answering with no language
> indication and it indicates how you might answer the call.
>
> There is however one small adjustment to do. The sentence about having the
> languages in preference order in the lists should be included also in the
> paragraph about the answer in 5.2.  Or it could be pulled out from the
> paragraph about the offer and put in a common paragraph below both
> paragraphs about the offer and the answer. And the lists should be in
> plural in the sentence.
> ------------------------------------------------------------
> ------------------------------------------------------------
> ----------------------------------
> /Gunnar
>
>
>
>
>
>
> case (as the text says). I don’t think we need to add more text (normative
> or descriptive) about it.
>
> —Randall
>
> On Fri, Feb 16, 2018 at 02:39 Gunnar Hellström <
> [email-masked]> wrote:
>
>> So, I repeat my comment from https://www.ietf.org/mail-
>> archive/web/slim/current/msg01297.html
> SLIM mailing [email-masked]://www.ietf.org/mailman/listinfo/slim
>
>
> --

---

From: Randall Gellens <[email-masked]>
Date: Sun, 18 Feb 2018 23:40:32 +0800

We don't expect an answer to contain a non-offered language except in unusual cases. What's in an answer is decided by policies at the answerer. I don't think we need to get into an exercise of trying to describe what is permitted vs forbidden for such edge cases. I think we can assume that the people who create the policies want to enable communication and not sow pointless confusion. 

Sent from my iPhone

> On Feb 18, 2018, at 11:27 PM, Bernard Aboba <[email-masked]> wrote:
> 
> Gunnar said: 
> 
> "That will happen if you decide to answer with a language that was not in the offer. But it is better than answering with no language indication and it indicates how you might answer the call."
> 
> [BA] I understand how an Answerer could respond only with language(s) not in the Offer.  But if the Answerer can support some of the offered languages, what are the restrictions on non-offered languages? 
> Can an Answerer put a non-offered language first in the preference list and an offered language in a less preferred position?  Should it be able to include a non-offered language at all?  If you offer English and
> Swedish and receive an Answer with Swahili and Swedish, that could result in confusion at best.
> 
>> On Sat, Feb 17, 2018 at 5:20 PM, Gunnar Hellström <[email-masked]> wrote:
>> I agree with Randall. No more normative or descriptive language is needed. There is already a warning against providing language indications that will be hard to match. That will happen if you decide to answer with a language that was not in the offer. But it is better than answering with no language indication and it indicates how you might answer the call.  
>> 
>> There is however one small adjustment to do. The sentence about having the languages in preference order in the lists should be included also in the paragraph about the answer in 5.2.  Or it could be pulled out from the paragraph about the offer and put in a common paragraph below both paragraphs about the offer and the answer. And the lists should be in plural in the sentence.
>> -----------------------------5.2 paragraph about the answer, with new sentence attached last------------------------------------------
>>> Putting a language in an answer that was not in the offer is an unusual case (as the text says). I don’t think we need to add more text (normative or descriptive) about it.
>>> 
>>> —Randall
>>> 
>>> Yes, the proposed changes seem good. One question: is there enough normative language about adding languages to an Answer that were not in the Offer? For example, can this only occur if the Answerer has no languages in common with the Offerer? Or can an Answerer add any languages(s) they would put into an Offer if roles were reversed?
>>> 
>>>> On Fri, Feb 16, 2018 at 02:39 Gunnar Hellström <[email-masked]> wrote:
>>>> I find that the changes to version -23 prepared by Randall and provided in this archive mail are good:
>>>> That version allows answers to contain languages not contained in the offer (that was already allowed and well specified in version -23),
>>>> I think both of these conditions are good and important for successful use of the draft. 
>>>> We need to imagine all kinds of feasible applications, e.g. the decision on including interpreting resources taken by the offeror after receiving the answer. That calls for providing the full and true picture about the supported languages in the answer.  
>>>> 
>>>> So, I repeat my comment from https://www.ietf.org/mail-archive/web/slim/current/msg01297.html
>>>> "I find the diff you sent to be good, and also version -23 solving all other issues in a good way. So, I vote for applying your proposed changes on -23 and hope that that can be the final version."
>>>> 
>>>> Gunnar 
>>>>> 
>>>>> 
>>>>> --Randall 
>>>>>

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 18 Feb 2018 20:54:50 +0100

Again, I agree with Randall. We do not need to complicate this with more 
rules. It will be a matter for the unspecified user interface to express 
the result of the negotiation to the users so that they rapidly can 
grasp the situation and know how to start the conversation smoothly. It 
is much more important to complement the draft with ways to express 
relative preference between languages in different media (in another 
draft) than to detail the rules about the mix of offered and un-offered 
languages in the answer in each media.

Gunnar

Den 2018-02-18 kl. 16:40, skrev Randall Gellens:
> We don't expect an answer to contain a non-offered language except in 
> unusual cases. What's in an answer is decided by policies at the 
> answerer. I don't think we need to get into an exercise of trying to 
> describe what is permitted vs forbidden for such edge cases. I think 
> we can assume that the people who create the policies want to enable 
> communication and not sow pointless confusion.
>
> Sent from my iPhone
>
> On Feb 18, 2018, at 11:27 PM, Bernard Aboba <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Gunnar said:
>>
>> "That will happen if you decide to answer with a language that was 
>> not in the offer. But it is better than answering with no language 
>> indication and it indicates how you might answer the call."
>>
>> [BA] I understand how an Answerer could respond only with language(s) 
>> not in the Offer.  But if the Answerer can support some of the 
>> offered languages, what are the restrictions on non-offered languages?
>> Can an Answerer put a non-offered language first in the preference 
>> list and an offered language in a less preferred position?  Should it 
>> be able to include a non-offered language at all?  If you offer 
>> English and
>> On Sat, Feb 17, 2018 at 5:20 PM, Gunnar Hellström 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     I agree with Randall. No more normative or descriptive language
>>     is needed. There is already a warning against providing language
>>     indications that will be hard to match. That will happen if you
>>     decide to answer with a language that was not in the offer. But
>>     it is better than answering with no language indication and it
>>     indicates how you might answer the call.
>>
>>     There is however one small adjustment to do. The sentence about
>>     having the languages in preference order in the lists should be
>>     included also in the paragraph about the answer in 5.2.  Or it
>>     could be pulled out from the paragraph about the offer and put in
>>     a common paragraph below both paragraphs about the offer and the
>>     answer. And the lists should be in plural in the sentence.
>>     -----------------------------5.2 paragraph about the answer, with
>>     new sentence attached last------------------------------------------
>>
>>>     unusual case (as the text says). I don’t think we need to add
>>>     more text (normative or descriptive) about it.
>>>
>>>     —Randall
>>>
>>>         Yes, the proposed changes seem good. One question: is there
>>>         enough normative language about adding languages to an
>>>         Answer that were not in the Offer? For example, can this
>>>         only occur if the Answerer has no languages in common with
>>>         the Offerer? Or can an Answerer add any languages(s) they
>>>         would put into an Offer if roles were reversed?
>>>
>>>         <[email-masked]
>>>         <mailto:[email-masked]>> wrote:
>>>
>>>             I find that the changes to version -23 prepared by
>>>             Randall and provided in this archive mail are good:
>>>             <https://www.ietf.org/mail-archive/web/slim/current/msg01289.html>
>>>
>>>             That version allows answers to contain languages not
>>>             contained in the offer (that was already allowed and
>>>             well specified in version -23),
>>>             We need to imagine all kinds of feasible applications,
>>>             e.g. the decision on including interpreting resources
>>>             taken by the offeror after receiving the answer. That
>>>             calls for providing the full and true picture about the
>>>             <https://www.ietf.org/mail-archive/web/slim/current/msg01297.html>
>>>             "I find the diff you sent to be good, and also version
>>>             -23 solving all other issues in a good way. So, I vote
>>>             for applying your proposed changes on -23 and hope that
>>>             that can be the final version."
>>>
>>>             Gunnar
>>>>
>>>>
>>>>             --Randall
>>>>
>>>>             <https://www.ietf.org/mailman/listinfo/slim>
>>>
>>>             -- 
>>>             <mailto:[email-masked]>
>>>             +46 708 204 288
>>>
>>>
>>>
>>>     --Randall
>>>
>>>
>>>
>>>     <https://www.ietf.org/mailman/listinfo/slim>
>>
>>     --

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 18 Feb 2018 14:56:40 -0500

The fact that Answers containing “pointless confusion” are allowed means that implementations need to be prepared to handle these edge cases. I see no benefit arising from this.

Why not require that an Answer place mutually supported language(s) before languages only supported by the Answerer? In what situations would it be necessary to do something else?

> On Feb 18, 2018, at 10:40 AM, Randall Gellens <[email-masked]> wrote:
>

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 18 Feb 2018 21:20:02 +0100

Den 2018-02-18 kl. 20:56, skrev Bernard Aboba:
> The fact that Answers containing “pointless confusion” are allowed 
> means that implementations need to be prepared to handle these edge 
> cases. I see no benefit arising from this.
>
> Why not require that an Answer place mutually supported language(s) 
> before languages only supported by the Answerer? In what situations 
> would it be necessary to do something else?
<GH>
Example within one media:  You might get an offer for spoken English, 
you feel quite unsure about talking English, but want to accept that but 
also express that your strong preference is spoken French. This is 
expressed by listing French before English in the answer. The offering 
party can then understand that it is possible to start the conversation 
in English, but if problems appear, it might be better to invoke a 
French - English interpreter, or hand it over to a French-speaking agent.

Example with two media: You might get an offer for spoken English in 
audio and a text stream, without any language indication. You do not 
hear so well, so you can barely manage a spoken conversation in English. 
Therefore you add written English in the text stream in the answer in 
the quite likely hope that the offering party can use English text. You 
would like to indicate strong preference for receiving English text 
before receiving English voice, but that is not possible with the 
current specification, so you need to hope that the offfering party can 
guess that from your insertion of reception of English text in the answer.

I do not think these examples provide any pointless confusion, but 
rather more clarity about the conditions for a successful conversation.

/Gunnar
>
> On Feb 18, 2018, at 10:40 AM, Randall Gellens 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>>> [BA] I understand how an Answerer could respond only with 
>>> language(s) not in the Offer.  But if the Answerer can support some 
>>> of the offered languages, what are the restrictions on non-offered 
>>> languages?
>>> list and an offered language in a less preferred position?  Should 
>>> it be able to include a non-offered language at all?  If you offer 
>>> English and
>>>     could be pulled out from the paragraph about the offer and put
>>>     in a common paragraph below both paragraphs about the offer and
>>>     the answer. And the lists should be in plural in the sentence.
>>>     -----------------------------5.2 paragraph about the answer,
>>>     with new sentence attached
>>>     last------------------------------------------
>>>

---

From: "Randall Gellens" <[email-masked]>
Date: Sun, 18 Feb 2018 19:20:36 -0800

> cases. I see no benefit arising from this.

In that case, let’s move forward with the draft as-is, which does only 
permits one language in the answer.

> would it be necessary to do something else?

I don’t think it’s necessary, because we don’t expect non-offered 
languages to be in an answer except in unusual edge cases.

—Randall

>> <[email-masked]> wrote:
>>
>>>> <[email-masked]> wrote:
>>>> decide to answer with a language that was not in the offer. But it 
>>>> is better than answering with no language indication and it 
>>>> could be pulled out from the paragraph about the offer and put in a 
>>>> common paragraph below both paragraphs about the offer and the 
>>>> new sentence attached 
>>>>>> <[email-masked]> wrote:
>>>>>> That version allows answers to contain languages not contained in 
>>>>>> the offer (that was already allowed and well specified in version 
>>>>>> -23),
>>>>>> I think both of these conditions are good and                     
>>>>>> important for successful use of the draft.
>>>>>> We need to imagine all kinds of feasible applications, e.g. the 
>>>>>> decision on including interpreting resources taken by the offeror 
>>>>>> after receiving the answer. That calls for providing the full and 
>>>>>> true picture about the supported languages in the answer.
>>>>>>
>>>>>> solving all other issues in a good                       way. So, 
>>>>>> I vote for applying your proposed changes on -23 and hope that 

--Randall

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 19 Feb 2018 08:43:23 +0100

> permits one language in the answer.
<GH>As explained in another reply, I do not see it adding pointless 
confusion. It adds clarity about the language situation and prepares for 
a smooth start of the dialogue.
> languages to be in an answer except in unusual edge cases.
<GH>It is the opposite situation that is of interest to express, when 
the answerer has some limited capability in one of the offered languages 
and a much higher preference for a non-offered language in the same 
media. So the answer contains both, with the non-offered first. That 
explains the language situation well to the offeror, and makes it 
possible for both parties to accommodate to the situation by whatever 
means and resources they have; either go with only the common language 
or do something to make it easier for the answering party.

Indicating a non-offered language in an answer with lower preference 
than a common language is of less interest. If you already agree on a 
language with good preference, why tell about your non-matched lower 
preference capabilities? But we do not need more rules about how 
indications for offered and non-offered languages are mixed or not.

/Gunnar

>>> We don't expect an answer to contain a non-offered language except 
>>> in unusual cases. What's in an answer is decided by policies at the 
>>>>>> enough normative language about adding languages to an Answer 
>>>>>> that were not in the Offer? For example, can this only occur if 
>>>>>> the Answerer has no languages in common with the Offerer? Or can 
>>>>>> an Answerer add any languages(s) they would put into an Offer if 
>>>>>> roles were reversed?
>>>>>>
>>>>>>> I think both of these conditions are good 
>>>>>>> and                     important for successful use of the draft.
>>>>>>> decision on including interpreting resources taken by the 
>>>>>>> offeror after receiving the answer. That calls for providing the 
>>>>>>> full and true picture about the supported languages in the answer.
>>>>>>>
>>>>>>> solving all other issues in a good                       way. 
>>>>>>> So, I vote for applying your proposed changes on -23 and hope 
>>>>>>> that that can be the final version."
>>>>>>>
>>>>>>> Gunnar
>>>>>>>>
>>>>>>>>
>>>>>>>> --Randall
>>>>>>>>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 19 Feb 2018 09:48:13 -0500

Randall said:

"In that case, let’s move forward with the draft as-is, which does only
permits one language in the answer."

[BA] I'm beginning to think that is a better idea, since the edge cases are
dramatically reduced (e.g. the one language would be one of the Offered
languages, unless none are supported).

" I don’t think it’s necessary, because we don’t expect non-offered
languages to be in an answer except in unusual edge cases."

[BA] If there were only one language in the Answer that is more likely to
be true, which is a good argument for that approach.

On Sun, Feb 18, 2018 at 10:20 PM, Randall Gellens <[email-masked]

> The fact that Answers containing “pointless confusion” are allowed means
>> that implementations need to be prepared to handle these edge cases. I see
>> no benefit arising from this.
>>
>
> Why not require that an Answer place mutually supported language(s) before
>> languages only supported by the Answerer? In what situations would it be
>> necessary to do something else?
>>
>
>>> unusual cases. What's in an answer is decided by policies at the answerer.
>>> I don't think we need to get into an exercise of trying to describe what is
>>> permitted vs forbidden for such edge cases. I think we can assume that the
>>> people who create the policies want to enable communication and not sow
>>> pointless confusion.
>>>
>>> Sent from my iPhone
>>>
>>>> "That will happen if you decide to answer with a language that was not
>>>> in the offer. But it is better than answering with no language indication
>>>> and it indicates how you might answer the call."
>>>>
>>>> not in the Offer.  But if the Answerer can support some of the offered
>>>> Can an Answerer put a non-offered language first in the preference list
>>>> and an offered language in a less preferred position?  Should it be able to
>>>>> needed. There is already a warning against providing language indications
>>>>> that will be hard to match. That will happen if you decide to answer with a
>>>>> language that was not in the offer. But it is better than answering with no
>>>>> language indication and it indicates how you might answer the call.
>>>>>
>>>>> the languages in preference order in the lists should be included also in
>>>>> the paragraph about the answer in 5.2.  Or it could be pulled out from the
>>>>>> unusual case (as the text says). I don’t think we need to add more text
>>>>>>> the offer (that was already allowed and well specified in version -23),
>>>>>>> decision on including interpreting resources taken by the offeror after
>>>>>>> receiving the answer. That calls for providing the full and true picture
>>>>>>> about the supported languages in the answer.
>>>>>>>
>>>>>>> "I find the diff you sent to be good, and also version -23 solving
>>>>>>> all other issues in a good                       way. So, I vote for
>>>>>>> applying your proposed changes on -23 and hope that that can be the final
>>>>>>> version."
>>>>>>>
>>>>>>> Gunnar
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --Randall
>>>>>>>>

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 19 Feb 2018 16:24:18 +0100

Den 2018-02-19 kl. 15:48, skrev Bernard Aboba:
> Randall said:
>
> "In that case, let’s move forward with the draft as-is, which does 
> only permits one language in the answer."
>
> [BA] I'm beginning to think that is a better idea, since the edge 
> cases are dramatically reduced (e.g. the one language would be one of 
> the Offered languages, unless none are supported).
<GH>We would create even more unbalance than we already have between 
what is allowed within one media compared to what is allowed in multiple 
media. The wording is now per media and direction. If we introduce a 
restriction to one language per media and direction, we can still have 
one offered language in the answer for one media and direction and one 
non-offered language in the answer for another media and the same 
direction. That would mean that one of these can be selected for use.

The fact that the answering party bothered to include the non-offered 
language in another media can likely be understood as an indication of 
preference for that language. The inclusion of the common language in 
one media can be understood as a safety measure to have some language 
that is surely possible to start with.
I think that is good and we should not limit the opportunity to provide 
such answers in multiple media. Why should we then introduce limitations 
for the similar indication within one media?

The edge cases do not hurt, and it is up to the applications to decide 
how much flexibility and clarity about the language situation they will 
provide to the user.
> [BA] If there were only one language in the Answer that is more likely 
> to be true, which is a good argument for that approach.
>
>
> On Sun, Feb 18, 2018 at 10:20 PM, Randall Gellens 
>         The fact that Answers containing “pointless confusion” are
>         allowed means that implementations need to be prepared to
>         handle these edge cases. I see no benefit arising from this.
>
>
>     In that case, let’s move forward with the draft as-is, which does
>     only permits one language in the answer.
>
>         Why not require that an Answer place mutually supported
>         language(s) before languages only supported by the Answerer?
>         In what situations would it be necessary to do something else?
>
>
>             <[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>             We don't expect an answer to contain a non-offered
>             language except in unusual cases. What's in an answer is
>             decided by policies at the answerer. I don't think we need
>             to get into an exercise of trying to describe what is
>             permitted vs forbidden for such edge cases. I think we can
>             assume that the people who create the policies want to
>             enable communication and not sow pointless confusion.
>
>             Sent from my iPhone
>
>                 "That will happen if you decide to answer with a
>                 language that was not in the offer. But it is better
>                 than answering with no language indication and it
>                 indicates how you might answer the call."
>
>                 [BA] I understand how an Answerer could respond only
>                 with language(s) not in the Offer.  But if the
>                 Answerer can support some of the offered languages,
>                 what are the restrictions on non-offered languages?
>                 Can an Answerer put a non-offered language first in
>                 the preference list and an offered language in a less
>                 preferred position?  Should it be able to include a
>                 non-offered language at all?  If you offer English and
>                 Swedish and receive an Answer with Swahili and
>                 Swedish, that could result in confusion at best.
>
>                     I agree with Randall. No more normative or
>                     descriptive language is needed. There is already a
>                     warning against providing language indications
>                     that will be hard to match. That will happen if
>                     you decide to answer with a language that was not
>                     in the offer. But it is better than answering with
>                     no language indication and it indicates how you
>                     might answer the call.
>
>                     There is however one small adjustment to do. The
>                     sentence about having the languages in preference
>                     order in the lists should be included also in the
>                     paragraph about the answer in 5.2. Or it could be
>                     pulled out from the paragraph about the offer and
>                     put in a common paragraph below both paragraphs
>                     about the offer and the answer. And the lists
>                     should be in plural in the sentence.
>                     -----------------------------5.2 paragraph about
>                     the answer, with new sentence attached
>                      In an answer, 'hlang-send' is a list of one or
>                     more languages the answerer might send if
>                        languages in the offer's 'hlang-recv'), and
>                     'hlang-recv' is a list of one or more of the
>                         Putting a language in an answer that was not
>                         in the offer is an unusual case (as the text
>                         says). I don’t think we need to add more text
>                         Yes, the proposed changes seem good. One
>                         question: is there enough normative language
>                         about adding languages to an Answer that were
>                         not in the Offer? For example, can this only
>                         occur if the Answerer has no languages in
>                         common with the Offerer? Or can an Answerer
>                         add any languages(s) they would put into an
>                         Offer if roles were reversed?
>
>                             On Fri, Feb 16, 2018 at 02:39 Gunnar
>                             Hellström <[email-masked]
>                             I find that the changes to version -23
>                             prepared by Randall and provided in this
>                             archive mail are good:
>                             That version allows answers to contain
>                             languages not contained in the offer (that
>                             was already allowed and well specified in
>                             version -23),
>                             We need to imagine all kinds of feasible
>                             applications, e.g. the decision on
>                             including interpreting resources taken by
>                             the offeror after receiving the answer.
>                             That calls for providing the full and true
>                             picture about the supported languages in
>                             the answer.
>
>                             "I find the diff you sent to be good, and
>                             also version -23 solving all other issues
>                             in a good                       way. So, I
>                             vote for applying your proposed changes on
>                             -23 and hope that that can be the final
>                             version."
>
>                             Gunnar
>
>
>
>                                 --Randall
>
>                             +46 708 204 288 <tel:%2B46%20708%20204%20288>
>
>
>
>
>                         --Randall
>
>
>
>                     +46 708 204 288 <tel:%2B46%20708%20204%20288>
>
>
>
>
>
>
>     --Randall
>
>

---

From: Martin J. Dürst <[email-masked]>
Date: Sun, 25 Feb 2018 15:49:50 +0900

Hello everybody,

>>> cases. I see no benefit arising from this.

This is just a general observation, but I think human language abilities 
are much more nuanced and fluent than e.g. supported codecs. That's why 
it's difficult to call such things "pointless confusions".

Regards,   Martin.

---

From: "Randall Gellens" <[email-masked]>
Date: Sun, 25 Feb 2018 02:42:18 -0800

On 24 Feb 2018, at 22:49, Martin J. Dürst wrote:

>>>> allowed means that implementations need to be prepared to handle 
>>>> these edge cases. I see no benefit arising from this.
>
> This is just a general observation, but I think human language 
> abilities are much more nuanced and fluent than e.g. supported codecs. 
> That's why it's difficult to call such things "pointless confusions".
>
> Regards,   Martin.

Hi Martin,

I don’t think anyone disagrees with that.  The range of possibilities 
with human languages are far greater than what the document tries to 
codify.

--Randall