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

Randall Gellens <rg+ietf@randy.pensive.org> Thu, 11 January 2018 22:12 UTC

Return-Path: <rg+ietf@randy.pensive.org>
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 3823E12EC54 for <slim@ietfa.amsl.com>; Thu, 11 Jan 2018 14:12:37 -0800 (PST)
X-Quarantine-ID: <7mgi-9CdkyCg>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7mgi-9CdkyCg for <slim@ietfa.amsl.com>; Thu, 11 Jan 2018 14:12:36 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id DBFD712EC52 for <slim@ietf.org>; Thu, 11 Jan 2018 14:12:35 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 11 Jan 2018 14:13:10 -0800
Mime-Version: 1.0
Message-Id: <p06240608d67d91940c51@[99.111.97.136]>
In-Reply-To: <8786bc77-d274-a64f-e733-b58cced18e67@alum.mit.edu>
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> <8786bc77-d274-a64f-e733-b58cced18e67@alum.mit.edu>
X-Mailer: Eudora for Mac OS X
Date: Thu, 11 Jan 2018 14:12:32 -0800
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, Gunnar Hellström <gunnar.hellstrom@omnitor.se>, Eric Rescorla <ekr@rtfm.com>
From: Randall Gellens <rg+ietf@randy.pensive.org>
Cc: "slim@ietf.org" <slim@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/9HBbwEv0RRk2RfTtfLSAlu0uSAw>
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 22:12:37 -0000

At 4:02 PM -0500 1/11/18, Paul Kyzivat wrote:

>  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.

I'd rather leave this for other documents.  For 
example, Gunner has a few drafts that build on 
this one.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
One should always be a little improbable.          --Oscar Wilde