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