Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-01.txt - absolute preferences
Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> Fri, 19 July 2013 06:16 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 C98D821E8051 for <mmusic@ietfa.amsl.com>; Thu, 18 Jul 2013 23:16:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.572
X-Spam-Level:
X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.028, 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 attxLgl4mnzP for <mmusic@ietfa.amsl.com>; Thu, 18 Jul 2013 23:16:44 -0700 (PDT)
Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id ED6DF11E80E4 for <mmusic@ietf.org>; Thu, 18 Jul 2013 23:16:43 -0700 (PDT)
Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP for <mmusic@ietf.org>; Fri, 19 Jul 2013 08:16:29 +0200 (CEST)
Received: from [192.168.50.33] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-06-01.atm.binero.net (Postfix) with ESMTPA id 02DA53A10C for <mmusic@ietf.org>; Fri, 19 Jul 2013 08:16:29 +0200 (CEST)
Message-ID: <51E8D9C1.9050804@omnitor.se>
Date: Fri, 19 Jul 2013 08:16:33 +0200
From: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: mmusic@ietf.org
References: <p06240602ce081a3d3f8c@[10.121.65.183]> <51E322C9.4040002@omnitor.se>
In-Reply-To: <51E322C9.4040002@omnitor.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-01.txt - absolute preferences
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: Fri, 19 Jul 2013 06:16:50 -0000
We also have the need for absolute preferences to handle and decide on. On 2013-07-15 00:14, Gunnar Hellstrom wrote: > 3. Absolute preference is still needed. > I described earlier the need for an absolute preference indication. But I did not provide any coding proposal. > I suggest to add something at the end of the language tag. Regardless if it gets before or after the * if it is there. > Can a "+" be used to indicate a strongly preferred language and modality, no extra specification a managed language and modality > and a "-" a non-preferred, but possible language and modality. The background was in an earlier mail: There is also a need for absolute preference. Or relative order of preference between media. It is easy to use a sign language example fort that situation. A person prefers to use British sign language in both directions but is capable with some reluctance to use English text. That is natural. Text is always slower and less expressive than sign language or spoken language. A call goes to a call center that declared spoken English and English text in both directions. The result can be a direct connection using English text, or invocation of a sign relay service translating between British sign language and spoken English. An ability to declare that the British sign language is preferred over the English text would result in the invocation of the sign relay service and make both sides happy with a call with good flow. Without the relative preference between media, the call will likely result in the direct text communication that will work but with less satisfaction. This can be solved either by an absolute preference indication : British sing language *preferred* , English text *managed* Or by some order of preference between the media; video *preferred* text *managed* I think an absolute preference indication is easiest to handle. Media preference will collide with relative preference between languages in each medium. I suggest that that is introduced with some suitable coding. It seems best t enter this in a paragraph in 7.1. I also propose that 7.1 is subdivided in subsections to make it easier to navigate. This addition would fit as a paragraph after this existing one: " In an offer, the 'humintlang-send' values constitute a list in preference order (first is most preferred) of the languages the offerer wishes to send, and the 'humintlang-recv' values constitute a list in preference order of the languages the offerer wishes to receive. In cases where the user wishes to use one media for sending and another for receiving (such as a speech-impaired user who wishes to send using text and receive using audio), one of the two will be unset. In other cases, both SHOULD have the same values in the same order. The two SHOULD NOT be set to languages which are difficult to match together (e.g., specifying a desire to send audio in Hungarian and receive audio in Portuguese will make it difficult to successfully complete the call)." I suggest to add this paragraph: " In order to express order of preference between different media, an absolute preference indication MAY be inserted in the attribute, after the language tag. An exclamation mark "!" is used to indicate a strongly preferred language and modality, no addition is used to indicate a managed language and modality, and a hash sign "#" is used to indicate a non-preferred but possible fall-back language and modality. An example can be a person who prefers to use British sign language in both directions but is capable with some reluctance to use English text, calling a call center that has competence for spoken English and English text in both directions. The result can be a direct connection using English text, or invocation of a sign relay service translating between British sign language and spoken English. The preference indication on British sign language guides the call centre in this case to invoke a relay service to get most satisfaction in the call, while in another case, a relay service for the discovered gap between the preferred languages might not be available, and then the fall-back to English text is a viable alternative. " Introduction of this coding with "!" , nothing, and "#" creates a need for a syntax chapter, where the allowed combinations of the language tag, these markers and the "*" for connect anyway are described more formally. Regards, Gunnar
- [MMUSIC] draft-gellens-mmusic-negotiating-human-l… Randall Gellens
- Re: [MMUSIC] draft-gellens-mmusic-negotiating-hum… Gunnar Hellstrom
- Re: [MMUSIC] draft-gellens-mmusic-negotiating-hum… Christian Groves
- Re: [MMUSIC] draft-gellens-mmusic-negotiating-hum… Randall Gellens
- Re: [MMUSIC] draft-gellens-mmusic-negotiating-hum… Randall Gellens
- Re: [MMUSIC] draft-gellens-mmusic-negotiating-hum… Gunnar Hellstrom
- Re: [MMUSIC] draft-gellens-mmusic-negotiating-hum… Gunnar Hellstrom