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

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Fri, 16 February 2018 07:39 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2ADD12D7E9 for <slim@ietfa.amsl.com>; Thu, 15 Feb 2018 23:39:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhpgypXgcvL2 for <slim@ietfa.amsl.com>; Thu, 15 Feb 2018 23:39:41 -0800 (PST)
Received: from bin-vsp-out-03.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99B6B124217 for <slim@ietf.org>; Thu, 15 Feb 2018 23:39:40 -0800 (PST)
X-Halon-ID: 869d0f9c-12ec-11e8-875e-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [87.96.161.61]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPSA id 869d0f9c-12ec-11e8-875e-0050569116f7; Fri, 16 Feb 2018 08:39:32 +0100 (CET)
To: Randall Gellens <rg+ietf@randy.pensive.org>, Bernard Aboba <bernard.aboba@gmail.com>
Cc: slim@ietf.org
References: <CAOW+2dtV5EaL_xTLSJNSiNjUZp-ZzFa2cMPUvSb65FRyYSNB1Q@mail.gmail.com> <6754134E-63FD-4212-90D5-D07293EFE36B@randy.pensive.org>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@omnitor.se>
Message-ID: <09dcffcc-a65d-65d8-614d-fa12b790dd4f@omnitor.se>
Date: Fri, 16 Feb 2018 08:39:32 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <6754134E-63FD-4212-90D5-D07293EFE36B@randy.pensive.org>
Content-Type: multipart/alternative; boundary="------------7F3E392A67360619D9391341"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/Gh6SSShIIrdfKf2O1nZHy7Gebi8>
Subject: Re: [Slim] Negotiation issue in draft-ietf-slim-negotiating-human-language
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Selection of Language for Internet Media <slim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/slim>, <mailto:slim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/slim/>
List-Post: <mailto:slim@ietf.org>
List-Help: <mailto:slim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/slim>, <mailto:slim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Feb 2018 07:39:44 -0000


Den 2018-02-15 kl. 23:44, skrev Randall Gellens:
> On 15 Feb 2018, at 4:53, Bernard Aboba wrote:
>
>> 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.
>
> 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 
>> accept his
>> proposal?
>
> Which language is this?  Can you copy the text or point to the message?
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
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288