Re: [MMUSIC] Update on Orlando time for human language draft discussion

Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> Mon, 11 March 2013 07:19 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8798E21F869E for <mmusic@ietfa.amsl.com>; Mon, 11 Mar 2013 00:19:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZFnPJWXDjfu for <mmusic@ietfa.amsl.com>; Mon, 11 Mar 2013 00:19:59 -0700 (PDT)
Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id C749F21F869C for <mmusic@ietf.org>; Mon, 11 Mar 2013 00:19:55 -0700 (PDT)
Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP; Mon, 11 Mar 2013 08:19:45 +0100 (CET)
Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-02-01.atm.binero.net (Postfix) with ESMTPA id A85BF3A479; Mon, 11 Mar 2013 07:47:01 +0100 (CET)
Message-ID: <513D7DE6.5030608@omnitor.se>
Date: Mon, 11 Mar 2013 07:47:02 +0100
From: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Randall Gellens <randy@qti.qualcomm.com>
References: <p0624060fcd51c3f6f708@[10.177.136.135]> <512C4B0D.5000701@cisco.com> <p06240612cd51fffa64e4@[10.177.136.135]> <6E90227CD3894A258EDE91D85B987169@DougEwell> <p06240604cd5b8a908bdc@[172.16.0.111]> <513B64DC.7070305@stpeter.im> <p06240603cd6124b4b62f@[99.111.97.136]> <p0624060ccd624b1ded46@[99.111.97.136]> <513CA193.30304@alvestrand.no> <949EF20990823C4C85C18D59AA11AD8BF2D9@FR712WXCHMBA11.zeu.alcatel-lucen t.com> <p0624061ccd629807c4e8@[99.111.97.136]> <513CDF15.8070601@alvestrand.no> <513CECB0.2010803@omnitor.se> <p06240622cd62b3079ccd@[99.111.97.136]> <513CFBC5.6060209@omnitor.se> <p06240624cd62c72d55a6@[99.111.97.136]>
In-Reply-To: <p06240624cd62c72d55a6@[99.111.97.136]>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Ari Keranen <ari.keranen@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>, "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>, Peter Saint-Andre <psaintan@cisco.com>, "ietf-languages-bounces@alvestrand.no" <ietf-languages-bounces@alvestrand.no>, Flemming Andreasen <fandreas@cisco.com>, "Hannes (NSN - FI/Espoo) Tschofenig" <hannes.tschofenig@nsn.com>, Peter Saint-Andre <stpeter@stpeter.im>, Brian Rosen <Brian.Rosen@neustar.biz>, Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: [MMUSIC] Update on Orlando time for human language draft discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Mar 2013 07:19:59 -0000

On 2013-03-11 00:30, Randall Gellens wrote:
> At 10:31 PM +0100 3/10/13, Gunnar Hellstrom wrote:
>
>>  On 2013-03-10 23:02, Randall Gellens wrote:
>>>  If possible, I think it may be better to keep service negotiation 
>>> distinct from language negotiation.  Otherwise things get very complex.
>>>
>>  That was just a use case.
>>
>>  Do you mean that we should divide it like this:
>>
>>   Imagined example in a call from A to B.
>>   A prefer to talk English, and A has some capability to talk French
>>   A Prefers to talk, but A is capable of typing
>>   A Needs to get text in English or French
>>   A has some benefit of getting spoken English or French, but A 
>> cannot accept that as the only channel for language perception.
>>
>>   A wants to have a conversation with B who declares only an ability 
>> to talk and understand spoken French.
>>
>>  An evaluation of the needs, preferences and capabilities of A and B 
>> would result in that the call is not possible because we have common 
>> capabilities only in the direction from A to the B.
>>  In the return path, from B to A, the only option it to receive 
>> spoken French from the B, while A is depending on getting written 
>> English or Written French.
>>
>>  -----
>>
>>  This information can then be used in a separate service request for 
>> getting a service C that adds rapid conversion of spoken French to 
>> typed French in the path from A to B, still letting the spoken French 
>> also pass over to A.
>
>
> It's very easy to add complexity in order to solve more aspects of the 
> problem.  I think we need to work very hard to keep this mechanism, at 
> least initially, very simple.
>
Yes, so I suggest that we now add a number of use cases, both simple and 
complex and then sort out which cases can be covered without getting 
lost in complexity.

/Gunnar