[Slim] New wording for the use of the asterisk in draft-ietf-slim-negotiating-human-language

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Wed, 31 May 2017 13:24 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
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 5131C129438 for <slim@ietfa.amsl.com>; Wed, 31 May 2017 06:24:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 hzZH1WvwGksQ for <slim@ietfa.amsl.com>; Wed, 31 May 2017 06:24:49 -0700 (PDT)
Received: from bin-vsp-out-03.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C18E8129524 for <slim@ietf.org>; Wed, 31 May 2017 06:24:48 -0700 (PDT)
X-Halon-ID: 830da33e-4604-11e7-bca7-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA for <slim@ietf.org>; Wed, 31 May 2017 15:24:44 +0200 (CEST)
To: slim@ietf.org
References: <149609884905.14640.4714137651572553743@ietfa.amsl.com> <54839aba-7ac8-79e4-74f8-927eb455d8af@omnitor.se> <p06240605d553b4cd71e6@[99.111.97.136]>
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
Message-ID: <b4d3e366-1250-283c-9a02-1d6b0d7c822d@omnitor.se>
Date: Wed, 31 May 2017 15:24:40 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <p06240605d553b4cd71e6@[99.111.97.136]>
Content-Type: multipart/alternative; boundary="------------658743ECD68DC0B9772FA8E4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/77S4Ab5VgIVpl6Fgo6_1aShR1yw>
Subject: [Slim] New wording for the use of the asterisk in draft-ietf-slim-negotiating-human-language
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: Wed, 31 May 2017 13:24:52 -0000

Regarding the many review comments about the use of the asterisk 
parameter in draft-ietf-slim-negotiating-human-language, ( e.g. by Adam 
Roach on 28/3/2017) I propose the following change that both gives a 
meaning to the position of the asterisk and satisfies issue #26 with 
media preferences.

I propose to use this solution if there is a decision to not satisfy 
Issue #34, to use the Accept-Language syntax.:

--Change proposal - to draft version -10---

--First change--

in section 5.2

--old text-

    In an offer, each value MAY have an asterisk appended as the final
    value.  An asterisk appended to either value in an offer indicates a
    request by the caller to the callee to not fail the call if there is
    no language in common.  See Section 5.3 for more information and
    discussion.

-new text

    In an offer or answer, each value MAY have an asterisk appended as the final
    parameter.  An asterisk appended to a value in an offer indicates a
    that the caller has higher preference for the corresponding modality
  to be used in the specified direction than other modalities for the indicated
direction without an asterisk. If no such preference is indicated in any hlang-
attribute, it should be taken as a preference by the caller to get the call denied
if no languages are in common between the caller and the callee.
In an answer, the asterisk indicates a modality that is preferred by the callee to be used in the session.

See Section 5.3 for more information and
    discussion.

--end of first change----

---second change----
In 5.3
----old text---


5.3.  No Language in Common

    A consideration with the ability to negotiate language is if the call
    proceeds or fails if the callee does not support any of the languages
    requested by the caller.  This document does not mandate either
    behavior, although it does provide a way for the caller to indicate a
    preference for the call succeeding when there is no language in
    common.  It is OPTIONAL for the callee to honor this preference.  For
    example, a PSAP is likely to attempt the call even without an
    indicated preference when there is no language in common, while a
    call center might choose to fail the call.

    The mechanism for indicating this preference is that, in an offer, if
    the last value of either 'hlang-recv' or 'hlang-send' is an asterisk,
    this indicates a request to not fail the call.  The called party MAY
    ignore the indication, e.g., for the emergency services use case,
    regardless of the absence of an asterisk, a PSAP will likely not fail
    the call; some call centers might reject a call even if the offer
    contains an asterisk.

---New text ----


5.3. Preferred modality and action if no match

    A user may have a clear preference to use one specific modality in a
    direction, while use of other modalities may be acceptable but lower in
    preference. This condition MAY be indicated by appending an asterisk
    as the last parameter in the corresponding humlang- value. This
    indication should also be seen as a preference to not have the call
    denied even if no indicated languages are in common.

    When negotiating language use for a direction, languages and modalities
   specified together with the asterisk should be given preference to be selected for use.

    No specific preference between modalities in the same direction should
    be indicated by appending an asterisk on all or no humlang- values for that direction.

    If there is a preference for denying the call when no languages match,
    then it is not possible to indicate any preferred modality at the same time.

    It is OPTIONAL for the callee to honor the preference for denying the call at no match.
    For example, a PSAP is likely to attempt the call even without an
    indicated preference when there is no language in common, while a
    call center might choose to fail the call.

    The called party MAY ignore the indication for denying the call, e.g.,
    for the emergency services use case,
    regardless of the absence of an asterisk, a PSAP will likely not fail
    the call; some call centers might reject a call in case of no matching language
    even if the offer contains an asterisk.

-----end of change ------------------


---Change in 5.5----

---Add this text as a separate example e.g. last in 5.5---

    An offer requesting the following media streams: audio for the caller
    to send using spoken English (most preferred modality) or American
    Sign Language (less preferred modality),
    audio for the caller to receive spoken English (most preferred modality) or
    American Sign Language (less preferred modality),
    supplemental text.  The offer also requests that the
    call proceed even if the callee does not support any of the
    languages. The offer is likely from a hearing person with knowledge in sign language:

       m=text 45020 RTP/AVP 103 104

       m=audio 49250 RTP/AVP 20
       a=hlang-recv:en *
       a=hlang-send:en *

      m=video 51372 RTP/AVP 31 32
      a=hlang-recv: ase
      a=hlang-send: ase

  An answer for the above offer, indicating video in which the callee will send and receive American Sign Language, because that callee had no capability for spoken English. The text and audio streams are opened as supplementary streams.

       m=text 45020 RTP/AVP 103 104
       
       m=audio 49250 RTP/AVP 20


       m=video 51372 RTP/AVP 31 32
       a=hlang-send: ase
       a=hlang-recv: ase

---end of change---






-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288