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

[Randall Gellens <[e-mail]>]

Hi Gunnar,

At 11:06 PM +0100 3/1/17, Gunnar Hellström wrote:

>  Den 2017-03-01 kl. 18:47, skrev Randall Gellens:
>>  At 8:26 AM +0100 3/1/17, Gunnar Hellström wrote:
>>
>>>   Hi Randall,
>>>
>>>   Den 2017-03-01 kl. 02:08, skrev Randall Gellens:
>>>
>>>>   Hi Gunnar,
>>>>
>>>>   I'm starting a new message to cut out the huge amount of quoting.
>>>>
>>>>   Your proposal is that text be added that 
>>>> advises the calling client to place an 
>>>> asterisk on the least-preferred 
>>>> language/media, and advises the answering 
>>>> client to indicate to the answering human 
>>>> which language/media is not the least 
>>>> preferred (did not have an asterisk in the 
>>>> offer), is that accurate?
>>>>
>>>   Yes, with slight rewording to:
>>>   "text that advises the offering client to 
>>> place an asterisk on the least-preferred 
>>> language/media indications, and advises the 
>>> answering client to indicate to the answering 
>>> human which language/media are not the least 
>>> preferred (did not have an asterisk in the 
>>> offer)"
>>>
>>>   The inclusion of the "indications" is just 
>>> to assure that it is clear that it does not 
>>> need to be just one indication that gets the 
>>> asterisk .
>>>   The last part sounds awkward, but matches 
>>> technically what the lack of an asterisk 
>>> means. I inherited the inverted logic for the 
>>> asterisk from its already defined non-denial 
>>> meaning.
>>>   If you are considering wording for the 
>>> draft, I suggest that you straighten the 
>>> logic to say "which language/media are most 
>>> preferred (did not have an asterisk in the 
>>> offer)"
>>>
>>>   It does also not need to be an "answering 
>>> human" that gets this indication and makes 
>>> use of it for guidance on how to answer the 
>>> call. It can just as well be e.g. a 
>>> multi-modal answering machine or some other 
>>> application interacting with human language. 
>>> I am not sure if "answering party" is more 
>>> appropriate and can be considered including 
>>> such automata.
>>
>>  Hi Gunnar,
>>
>>  Thanks for clarifying, I think I understand 
>> your proposal in detail now.  After thinking 
>> it over, I still think this would be better 
>> done in a new draft, because (a) it is advice 
>> on a way of using the mechanism to convey 
>> additional information; (b) it would be good 
>> for the group to discuss the proposal and work 
>> through various cases (e.g., what if the 
>> offering client is not going to include an 
>> asterisk, what if there is more than one 
>> most-preferred language); and (c) it would be 
>> good for the group to decide if this meets 
>> your need.
>  Randall,
>  Good that you understand it now.
>  I realize that this kind of added rules for an 
> already existing parameter could be specified 
> in an additional draft. Especially since it has 
> no impact on the current meaning of the 
> asterisk.
>  I still think it is best to add the few words 
> needed now. The preference indication is so 
> severely unbalanced without it, in that only 
> preference between languages in the same 
> modality can be specified. I am afraid that it 
> can be seen as a discrimination against those 
> who would need to specify preference between 
> different modalities in order to tget equal 
> opportunities to get smoothly performed calls 
> through, but cannot.
>
>  You are right that there are situations that 
> will not be explained if we accept my little 
> extra sentence or something similar.
>  That is true also for the currently specified 
> indications. We have said that we nearly only 
> specify the indications and not how the 
> negotiation shall be performed. It can be a 
> topic for a BCP to advice on how the 
> negotiation could be performed both with the 
> currently specified language and in-media 
> preferences and with the additional preference 
> between media. We could discuss e.g. the case 
> when two same spoken languages are specified 
> but with the opposite preference order by the 
> offeror and answering party. A decision must be 
> taken, because the protocol says that oly one 
> language per media and direction may be 
> indicated in the answer, and also that the 
> answering instance need to become aware of 
> which language it shall produce.
>  I do not say that we need to resolve this case. 
> It can be discussed in a BCP, and indicated 
> that additional policy may be applied for 
> solving that kind of undefined cases.
>
>  Similarily, there will be situations with the 
> additional use of the asterisk that will be 
> good to provide extra information for in a BCP. 
> The preference indication is very rough, with 
> only two levels. So there wil of course be 
> situations when the users will wonder how to 
> set their profile, and cases when the 
> negotiation will be hard to assign a well 
> motivated result. But we have said that we want 
> to have the specification on this rough level.
>
>  The two cases that you bring up can have this treatment:
>
>  1. If the calling user want to get the call 
> denied if no languages match, then the user 
> must make a decision if that preference is more 
> important to specify than the preference 
> between modalities. In order to keep complexity 
> low, I do not think that we should specify how 
> to code both preferences.
>
>  2. If there are more than one most-preferred 
> language. I understand this as for example a 
> user is equally happy to use French sign 
> language as spoken French, and can also, but on 
> lower preference level write French text. That 
> would be indicated by an asterisk on the French 
> text, and the answering party having all these 
> three capabilities may omit the French text 
> from the answer but keep the others. Then the 
> answering user select one of the spoken French 
> and French Sign Language for its start of the 
> call, knowing that the caller will be 
> approximately equally happy with the call in 
> both these cases.   Was that the case you 
> thought about for the second case?
>
>  I understand that you wanted to check more than 
> these two cases and discuss them with the WG, 
> so the above is just a start. We can do more 
> cases if you want, but I do not think we need 
> any lengthy discussion that would delay the 
> current draft.
>
>>
>>
>>  A new draft, especially one that will be 
>> either Informational or BCP, can be done 
>> fairly quickly. It could be quite short, 
>> perhaps only a page or two of real text plus 
>> the boilerplate text.  I am happy to help with 
>> it.

I see your point, however, my view is that this 
is best covered in a separate draft.  As I said 
above, the draft can be completed very quickly if 
it is Informational (or even BCP), clear and not 
controversial.  I am happy to help.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
    The highlight of the annual Computer Bowl occurred when Bill Gates,
who was a judge, posed the following question to the contestants:
    "What contest, held via Usenet, is dedicated to examples of weird,
obscure, bizarre, and really bad programming?"
    After a moment of silence, Jean-Louis Gassee (ex-honcho at Apple)
hit his buzzer and answered "Windows."
                                          --Recounted by Adam C. Engst