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

[Gunnar Hellström <[e-mail]>]

Den 2018-02-19 kl. 04:20, skrev Randall Gellens:
> On 18 Feb 2018, at 11:56, Bernard Aboba wrote:
>
>> 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.
<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.
>
>> 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?
>
> 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.
<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


>
> —Randall
>
>>
>>> On Feb 18, 2018, at 10:40 AM, Randall Gellens 
>>> <[e-mail]> 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
>>>
>>>> On Feb 18, 2018, at 11:27 PM, Bernard Aboba 
>>>> <[e-mail]> 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 
>>>>> <[e-mail]> 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.
>>>>> 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
>>>>>>
>>>>>> On 16 Feb 2018, at 19:36, Bernard Aboba wrote:
>>>>>>
>>>>>> 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 
>>>>>>> <[e-mail]> 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),
>>>>>>> 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
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>>>>
>>>>>>>
>>>>>>> -- 
>>>>>>> -----------------------------------------
>>>>>>> Gunnar Hellström
>>>>>>> Omnitor
>>>>>>> [e-mail]
>>>>>>> [phone]
>>>>>>
>>>>>>
>>>>>>
>>>>>> --Randall
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> SLIM mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>>
>>>>> -- 
>>>>> -----------------------------------------
>>>>> Gunnar Hellström
>>>>> Omnitor
>>>>> [e-mail]
>>>>> [phone]
>>>>
>
>
>
>
> --Randall
>
> _______________________________________________
> SLIM mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/slim

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[e-mail]
[phone]