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

Paul Kyzivat <> Thu, 11 January 2018 21:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 894C0126B6E for <>; Thu, 11 Jan 2018 13:02:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.211
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IHsRzvY0yAoL for <>; Thu, 11 Jan 2018 13:02:13 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A2008128961 for <>; Thu, 11 Jan 2018 13:02:13 -0800 (PST)
X-AuditID: 12074411-67dff70000000b66-f7-5a57d0d4038d
Received: from (OUTGOING-ALUM.MIT.EDU []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 34.DF.02918.4D0D75A5; Thu, 11 Jan 2018 16:02:12 -0500 (EST)
Received: from PaulKyzivatsMBP.localdomain ( []) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by (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 <>, Randall Gellens <>, Eric Rescorla <>
Cc: "" <>
References: <> <> <> <> <p06240601d6785f2e3ad4@> <> <p06240603d6795cbba847@> <> <p06240605d679600b6eea@[]> <p06240606d67963d25192@[]> <> <p06240608d679789e3190@[]> <> <p06240609d6799905c9c0@[]> <> <> <>
From: Paul Kyzivat <>
Message-ID: <>
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: <>
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: <>
Subject: Re: [Slim] Eric Rescorla's No Objection on draft-ietf-slim-negotiating-human-language-19: (with COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Selection of Language for Internet Media <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.