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

Randall Gellens <rg+ietf@randy.pensive.org> Thu, 01 June 2017 18:28 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 8137112F280 for <slim@ietfa.amsl.com>; Thu, 1 Jun 2017 11:28:05 -0700 (PDT)
X-Quarantine-ID: <DMQBI_fQerQO>
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.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 DMQBI_fQerQO for <slim@ietfa.amsl.com>; Thu, 1 Jun 2017 11:28:04 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6CAD5129C4B for <slim@ietf.org>; Thu, 1 Jun 2017 11:28:04 -0700 (PDT)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 1 Jun 2017 11:30:21 -0700
Mime-Version: 1.0
Message-Id: <p06240607d5560c19be82@[99.111.97.136]>
In-Reply-To: <029e25ca-fbf7-b6b1-9432-497f2dfb5a0a@omnitor.se>
References: <149609884905.14640.4714137651572553743@ietfa.amsl.com> <54839aba-7ac8-79e4-74f8-927eb455d8af@omnitor.se> <p06240605d553b4cd71e6@[99.111.97.136]> <db378c1e-aecb-f312-fefe-bc7a6eacfebc@omnitor.se> <p06240600d5547791845c@[99.111.97.136]> <e25a2790-0feb-9377-a3c3-f4e984e2cdd8@omnitor.se> <029e25ca-fbf7-b6b1-9432-497f2dfb5a0a@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Thu, 01 Jun 2017 11:28:01 -0700
To: Gunnar Hellström <gunnar.hellstrom@omnitor.se>, slim@ietf.org
From: Randall Gellens <rg+ietf@randy.pensive.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/VTWpx2ZbaCDSy7gWCWr-KXR_KAw>
Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-10.txt
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, 01 Jun 2017 18:28:05 -0000

Edited down for clarity.

At 8:16 PM +0200 6/1/17, Gunnar Hellström wrote:

>>>>
>>>>  ---Change 2.5-----
>>>>  Requiring exactly one language per direction 
>>>> in the answer requires a tight coupling 
>>>> between the device and the user that we have 
>>>> avoided to specify. It would require either 
>>>> that the device takes the negotiation 
>>>> decision and dictates to the user e.g. 
>>>> "SPEAK GERMAN NOW !, or that there is a user 
>>>> interface interaction to decide which 
>>>> language to answer in, e.g. "The calling 
>>>> part may accept French or German, indicate 
>>>> here which one you will answer with".
>>>>
>>>>  We do not want to dictate that kind of tight 
>>>> coupling, and therefore must allow a number 
>>>> of alternative languages in various media to 
>>>> appear in the answer.
>>>>
>>>>  ---Old text 2.5---
>>>>  In an answer, 'hlang-send' is the language the answerer will send
>>>>  when using the media (which in most cases is one of the languages in
>>>>  the offer's 'hlang-recv'), and 'hlang-recv' is the language the
>>>>  answerer expects to receive in the media (which in most cases is one
>>>>  of the languages in the offer's 'hlang-send').
>>>>  ---New text 2.5---
>>>>  In an answer, 'hlang-send' may be one or a 
>>>> list of alternative languages the
>>>>  answerer will select from for sending if using the media for language
>>>>  (which in most cases is one of the languages in the offer's 'hlang-recv'),
>>>>  and 'hlang-recv' may be one or a list of 
>>>> alternative languages the answerer
>>>>  can accept to receive if the media is used 
>>>> for language (which in most cases is one
>>>>  of the languages in the offer's 'hlang-send').
>>>>
>>>
>>>  Having one language per media in the answer 
>>> has been part of the draft all along. I don't 
>>> recall seeing an objection to this before. 
>>> Further, Section 3 has said all along that 
>>> attempting to negotiate multiple languages 
>>> per media is out of scope:
>>>
>>>  (Negotiating multiple simultaneous languages within a media stream is
>>>  out of scope of this document.)
>>>
>>  <GH>Yes, the user will only use one language. 
>> But have you thought about the consequences 
>> for how to accomplish a negotiation result of 
>> just one language in a media, and just that 
>> language will also be used by the answering 
>> human?
>>
>>  It will require tight coupling in the user 
>> interface of a kind that you do not want to 
>> discuss. If the UA decides that the answering 
>> part will send spoken german, then that needs 
>> to be conveyed to the user. If the UA instead 
>> lets the user decide, then there must be a 
>> question-answer exchange between the UA and 
>> the user to enable the UA to have just one 
>> language for the media in the answer.
>>
>>  We have agreed that some kind of such coupling 
>> is needed, and we do not specify how. But the 
>> requirements on the operation will be much 
>> less strict if we allow a list of languages 
>> per media to be the result of the negotiation.
>>
>>  The paranthesis " (Negotiating multiple 
>> simultaneous languages within a media stream is
>>  out of scope of this document.) " will then apply to the user.
>>
>>
>>  This is a quite new finding from when trying 
>> to think through a real negotiation, so I am 
>> prepared to discuss how strict we should be.
>>
>  <GH>After the exercise with the negotiation 
> today, I see that I can relax this requirement.
>  But it needs to be clear that the negotiated 
> language in a media just maybe used for 
> language.
>  So that it is clear that no simultaneous use is normally required.
>
>  That leads to
>  --New text 2.5 ---
>  In an answer, 'hlang-send' is the language the answerer will send
>  if using the media for language (which in most 
> cases is one of the languages in
>  the offer's 'hlang-recv'), and 'hlang-recv' is the language the
>  answerer expects to receive in the media (which in most cases is one
>  of the languages in the offer's 'hlang-send').
>
>  ---end of 2.5 -------------------------

Your request is to change "when using the media" 
to "if using the media for language".  I can live 
with this.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
There are two ways to write error-free programs;
only the third one works.