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

Randall Gellens <rg+ietf@randy.pensive.org> Mon, 08 January 2018 19:39 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 32240126BF6 for <slim@ietfa.amsl.com>; Mon, 8 Jan 2018 11:39:06 -0800 (PST)
X-Quarantine-ID: <43kDKrOL91sP>
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 43kDKrOL91sP for <slim@ietfa.amsl.com>; Mon, 8 Jan 2018 11:39:04 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5EABA12426E for <slim@ietf.org>; Mon, 8 Jan 2018 11:39:04 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 8 Jan 2018 11:39:36 -0800
Mime-Version: 1.0
Message-Id: <p06240608d679789e3190@[99.111.97.136]>
In-Reply-To: <2d4be9b6-08d0-236e-4230-6ebc12b4167b@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>
X-Mailer: Eudora for Mac OS X
Date: Mon, 08 Jan 2018 11:38:51 -0800
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, Eric Rescorla <ekr@rtfm.com>
From: Randall Gellens <rg+ietf@randy.pensive.org>
Cc: Bernard Aboba <bernard_aboba@hotmail.com>, "slim@ietf.org" <slim@ietf.org>, Bernard Aboba <bernard.aboba@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/YvwrpDpXpRL-1dQwwfqSWqGVuLc>
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: Mon, 08 Jan 2018 19:39:06 -0000

At 1:36 PM -0500 1/8/18, Paul Kyzivat wrote:

>  On 1/8/18 1:10 PM, Randall Gellens wrote:
>
>>      The term "negotiation" is used here rather than "indication" because
>>      human language (spoken/written/signed) can be negotiated in the same
>>      manner as media (audio/text/video) and codecs.  For example, if we
>>      think of a user calling an airline reservation center, the user may
>>      have a set of languages he or she speaks, with perhaps preferences
>>      for one or a few, while the airline reservation center will support a
>>      fixed set of languages.  Negotiation should select the user's most
>>      preferred language that is supported by the call center.  Both sides
>>      should be aware of which language was negotiated.  This is
>>      conceptually similar to the way other aspects of each media stream
>>      are negotiated using SDP (e.g., media type and codecs).
>
>  Certainly it will be common for the choices are mutually exclusive. 
> For instance, a caller *might* offer both French and Chinese. The 
> callee (a call center) may have agents that speak each, but may 
> well not have any agents that speak both.
>
>  OTOH, it is *possible* that they do have somebody who supports 
> both. If so, seems like it would be good to indicate that both are 
> supported.

Yes, although the additional gain in functionality is small relative 
to the additional complexity.  The draft explicitly rules this out of 
scope.  Section 3 says:

    (Negotiating multiple simultaneous languages within a media stream is
    out of scope of this document.)

This could, of course, be added in a future extension or revision.


>
>  	Thanks,
>  	Paul
>
>  _______________________________________________
>  SLIM mailing list
>  SLIM@ietf.org
>  https://www.ietf.org/mailman/listinfo/slim


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Don't sweat petty things . . . or pet sweaty things.