Re: [Slim] Eric Rescorla's No Objection on draft-ietf-slim-negotiating-human-language-19: (with COMMENT)

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 11 January 2018 21:02 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 894C0126B6E for <slim@ietfa.amsl.com>; Thu, 11 Jan 2018 13:02:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 IHsRzvY0yAoL for <slim@ietfa.amsl.com>; Thu, 11 Jan 2018 13:02:13 -0800 (PST)
Received: from alum-mailsec-scanner-5.mit.edu (alum-mailsec-scanner-5.mit.edu [18.7.68.17]) by ietfa.amsl.com (Postfix) with ESMTP id A2008128961 for <slim@ietf.org>; Thu, 11 Jan 2018 13:02:13 -0800 (PST)
X-AuditID: 12074411-67dff70000000b66-f7-5a57d0d4038d
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 34.DF.02918.4D0D75A5; Thu, 11 Jan 2018 16:02:12 -0500 (EST)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id w0BL2AB9025903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 11 Jan 2018 16:02:11 -0500
To: Gunnar Hellström <gunnar.hellstrom@omnitor.se>, Randall Gellens <rg+ietf@randy.pensive.org>, Eric Rescorla <ekr@rtfm.com>
Cc: "slim@ietf.org" <slim@ietf.org>
References: <151528917109.10947.12045320996364596931.idtracker@ietfa.amsl.com> <CABcZeBNQLuaMLa3=gWqaYHL_ynQ1t+HRtsgEebCRORm+OUA0iw@mail.gmail.com> <ECD0168D-9C53-4ACA-BF28-C631DAE38A4D@gmail.com> <CABcZeBPwb5LzCEpaOMbR9CeETHSZiigovkTMhKm_3K=hsWZckA@mail.gmail.com> <p06240601d6785f2e3ad4@99.111.97.136> <CABcZeBNX4iTuvuqvvqjAQEgnhkV4f5Z1e8Ac2ebWOf=prAcPKg@mail.gmail.com> <p06240603d6795cbba847@99.111.97.136> <CABcZeBPsXfPGBRMTRJSNZiHaXA8dT1MYXsU+3GdPsmLyQHZigg@mail.gmail.com> <p06240605d679600b6eea@[99.111.97.136]> <p06240606d67963d25192@[99.111.97.136]> <2d4be9b6-08d0-236e-4230-6ebc12b4167b@alum.mit.edu> <p06240608d679789e3190@[99.111.97.136]> <4a2b52ff-3853-b159-6563-018e4080eb53@omnitor.se> <p06240609d6799905c9c0@[99.111.97.136]> <d556fd95-991a-635c-d513-265135b75b11@omnitor.se> <65963c20-0034-acbe-f66b-986344d7a067@alum.mit.edu> <975ebbe3-d796-d118-50db-8c9957541a2c@omnitor.se>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <8786bc77-d274-a64f-e733-b58cced18e67@alum.mit.edu>
Date: Thu, 11 Jan 2018 16:02:10 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <975ebbe3-d796-d118-50db-8c9957541a2c@omnitor.se>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPKsWRmVeSWpSXmKPExsUixO6iqHvlQniUwalXahYrXp9jt9jx/gyL xffnXYwWMz90sjmweCxZ8pPJY+LiT8weW+88ZvGY/LiNOYAlissmJTUnsyy1SN8ugSvj7Y0u toKHAhUL13UyNzDO4O1i5OSQEDCReP3kHxuILSSwg0liw/aELkYuIPshk0Rr62L2LkYODmGB YonbLVkgcRGBBYwSW74uZgRpYBZQlpi+8B47RMNcdolVL5eBJdgEtCTmHPrPAmLzCthLbOlr BdvAIqAqsWbiFrAaUYE0iVfPdjBD1AhKnJz5BKyeU8BOYvWhx8wQC2wl7szdDWWLS9x6Mp8J wpaXaN46m3kCo8AsJO2zkLTMQtIyC0nLAkaWVYxyiTmlubq5iZk5xanJusXJiXl5qUW6pnq5 mSV6qSmlmxghoS64g3HGSblDjAIcjEo8vA9yw6OEWBPLiitzDzFKcjApifLuSQcK8SXlp1Rm JBZnxBeV5qQWH2KU4GBWEuGt6QbK8aYkVlalFuXDpKQ5WJTEefmWqPsJCaQnlqRmp6YWpBbB ZGU4OJQkeFeeB2oULEpNT61Iy8wpQUgzcXCCDOcBGr4FpIa3uCAxtzgzHSJ/itGYo+XikzZm jhsvXrcxC7Hk5eelSonzzgcpFQApzSjNg5sGS1evGMWBnhPmfQ5SxQNMdXDzXgGtYgJadX5j KMiqkkSElFQDY41b6DEDZ/NkUfaOkoWyelERszK3d+WIXLc9+5vrbtTJ+1I/Dp3R3Jk8/zxb 9M6YiQ9N3a6Y7wqNnn5x6byoO0rTYmTzwsx6zpVovg/8sU05gutxn17riW9Xqk2jXsvP8llh uyG9KtCmJspsIuvK96rilU8ucWxYWe8/Z8o1Jnm5v6/4jlxWUWIpzkg01GIuKk4EAKfWEw0y AwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/4xdQ_gKZy9ahFqS_PQdmprSUVJ0>
Subject: Re: [Slim] Eric Rescorla's No Objection on draft-ietf-slim-negotiating-human-language-19: (with COMMENT)
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: Thu, 11 Jan 2018 21:02:15 -0000

On 1/10/18 3:02 PM, Gunnar Hellström wrote:
> Den 2018-01-10 kl. 16:51, skrev Paul Kyzivat:
>> Gunnar,
>>
>> I would like to understand your thinking about how the language 
>> indications will be used. Your comments below suggest to me that you 
>> are assuming that they will be exposed to the end users through a UI. 
>> If that is not the case then order of preference of one language over 
>> another won't have any influence over how the session proceeds.
> Yes, it is in most applications the human end users who are expected to 
> produce and understand the negotiated language(s). Therefore the final 
> result of the negotiation must be presented to the users. (or, in less 
> common automatic conversation cases, fed to an automata for generating 
> the agreed language).
> We say that this must happen, but it is not the task of the draft to say 
> how.
> 
> Examples:
> 
> If it is a regular conversational call application, it could present 
> what the application regards to be the best match on the screen: "Talk 
> English, expect English text".
> That prepares the users for how the call is best started.
> 
> Alternatively, the answering party can be provided with options for 
> selection among the common languages before the call is answered. E.g.
> "The far end user can receive ASL __ and written English __, which do 
> you want to produce?"
> "The far end user can produce ASL ___ and written English ___, which do 
> you want to receive?"
> The result goes into the coding of the hlang attributes in the answer.
> The answer will be presented to the offeror on the screen by e.g.
> "Sign ASL, prepare to receive ASL".
> 
> By following the advice on the screen, the call will start smoothly. 
> Nothing prevents the users to vary the use of languages and media by 
> mutual agreement after the initial exchange during the call.
> 
> Wide variations from these examples are imaginable.
> Gunnar

While this sounds helpful, it isn't current practice. I don't know what 
it will take make it common practice. Perhaps the draft should note this 
as an issue.

	Thanks,
	Paul