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

Randall Gellens <rg+ietf@randy.pensive.org> Wed, 31 May 2017 13:58 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 B8DDD129B8C for <slim@ietfa.amsl.com>; Wed, 31 May 2017 06:58:37 -0700 (PDT)
X-Quarantine-ID: <r88N5nt8p54I>
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.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 r88N5nt8p54I for <slim@ietfa.amsl.com>; Wed, 31 May 2017 06:58:36 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3975C12762F for <slim@ietf.org>; Wed, 31 May 2017 06:58:36 -0700 (PDT)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 31 May 2017 07:00:52 -0700
Mime-Version: 1.0
Message-Id: <p06240601d5547c6aa715@[99.111.97.136]>
In-Reply-To: <b4d3e366-1250-283c-9a02-1d6b0d7c822d@omnitor.se>
References: <149609884905.14640.4714137651572553743@ietfa.amsl.com> <54839aba-7ac8-79e4-74f8-927eb455d8af@omnitor.se> <p06240605d553b4cd71e6@[99.111.97.136]> <b4d3e366-1250-283c-9a02-1d6b0d7c822d@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Wed, 31 May 2017 06:58:30 -0700
To: Gunnar Hellström <gunnar.hellstrom@omnitor.se>, slim@ietf.org
From: Randall Gellens <rg+ietf@randy.pensive.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/D9C2snaO9VqJEsGDfxEcuPMIkYw>
Subject: Re: [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:58:38 -0000

This text should go in a separate document containing advice to implementers.

At 3:24 PM +0200 5/31/17, Gunnar Hellström wrote:

>  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
>  <mailto:gunnar.hellstrom@omnitor.se>gunnar.hellstrom@omnitor.se
>  +46 708 204 288
>
>  _______________________________________________
>  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: ---------------
He had that rare weird electricity about him -- that extremely
wild and heavy presence that you only see in a person who has
abandoned all hope of ever behaving "normally."
        --Hunter S. Thompson, "Fear and Loathing '72"