Re: [Slim] draft-ietf-slim-negotiating-human-language: Issue 38

Bernard Aboba <bernard.aboba@gmail.com> Thu, 13 July 2017 17:09 UTC

Return-Path: <bernard.aboba@gmail.com>
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 25A7212F257 for <slim@ietfa.amsl.com>; Thu, 13 Jul 2017 10:09:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 7cra71GXs7XC for <slim@ietfa.amsl.com>; Thu, 13 Jul 2017 10:09:47 -0700 (PDT)
Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 447B51298BA for <slim@ietf.org>; Thu, 13 Jul 2017 10:09:47 -0700 (PDT)
Received: by mail-ua0-x236.google.com with SMTP id g13so19011646uaj.0 for <slim@ietf.org>; Thu, 13 Jul 2017 10:09:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yOIsKeYIGg59OX71oVUnHmUcSU4eoNqqoV5obGHH7cE=; b=C9uOz8sG9Q6/w9wgkC+660kMmZ9JsfUFl13c+B71LLl9+1rrIU5tiM7EY09FlaqPzx +l1BdVD3uY2MrSaz62ykwoTnclcPe2x7RUFZ73Lz9lDOxjonys2GcYAU8RVdcl4xExqG vYFdH/NnX8YJm8KdWDfi6miagaPqFssrdWew9o5cYgxkRBXdl+gBtmdAz9744o4YTzwe xlzYqxjXTMlnT29aRXsu0OAbOmwy4256cU027odcHKN9o/HON/TSevP7tpJ2jEBfH8Kz dYXjN3r8petWJ/w1Yk2qUZgGKOGeE3i0cJBZ/eDkwbaSwaeND0wASvRMgzDTGlcsjWh4 5vug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yOIsKeYIGg59OX71oVUnHmUcSU4eoNqqoV5obGHH7cE=; b=FFWJjMtbL2jWEUMue8cwwlcxT6NWCyVIeikCcuW2IDGuDsB8UzEYZ7Tvdk2BdqcQZU YR9RxdasxakD1E3iPBsqtNziHP/Z2cOIMkwPItOU9nXvujFgqAGYcgbtFi1Qe28vymWS xIBKB75WxbFdh0VVe+1fyZaUaWXTiZmmeomdTiFx+E8T8uJzL0i8XMlD0IQlzgtCKaLC 1qKuJyw4nPWKVHlHiWiazM8HwFBCzCz1tKmayOMXANTNwrFLfN1lNlQWi00hGN4zhXgd ZjCF5UTGPN1OmhC1mKgnh1SiJOPKBPoGJtE+tSeM6ocTmhbwK1rqqqtT/FylIVtx4J1/ qJzQ==
X-Gm-Message-State: AIVw1100jJiKTyr7FToNCMNuMSVGnL4tFMkSWh9vZuvlILMf2BbI06yw 7UvbRu7A2+yAMpix4nqexciEGvmzXu52gpA=
X-Received: by 10.176.2.22 with SMTP id 22mr2605043uas.0.1499965786016; Thu, 13 Jul 2017 10:09:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.35.80 with HTTP; Thu, 13 Jul 2017 10:09:25 -0700 (PDT)
In-Reply-To: <275d4884-274e-8006-e46a-9abe52337df5@omnitor.se>
References: <CAOW+2duuFtjhfjew991HVHP7qw_uQa1APSseujF+1a=mXtaeGg@mail.gmail.com> <CAOW+2ds6LBVRpuwSGZWznQBd1_GC1RJ0O6VrA7h7HPutR+V3sw@mail.gmail.com> <f3dfd815-dbef-8730-999c-8441342732a0@nostrum.com> <275d4884-274e-8006-e46a-9abe52337df5@omnitor.se>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Thu, 13 Jul 2017 10:09:25 -0700
Message-ID: <CAOW+2dvjx+XaRj2G1jmmM8S93AbUUpv5o5KvcY74Q7HDiURaFQ@mail.gmail.com>
To: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
Cc: Adam Roach <adam@nostrum.com>, slim@ietf.org
Content-Type: multipart/alternative; boundary="001a113fa1e6d9d0b4055435ffc4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/uk1XuPdQOlFeFoj06EH_6Kc7oaM>
Subject: Re: [Slim] draft-ietf-slim-negotiating-human-language: Issue 38
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: Thu, 13 Jul 2017 17:09:50 -0000

Gunnar said:

" A long time ago, I stopped arguing for a SIP based solution when I
realized that SDP is more often used than SIP in the WebRTC environment.
Basing it on SDP makes it easier to convey the language and modality needs
across the SIP / WebRTC border. (There is a complication that real-time
text is an RTP stream on the SIP side and a multiplexed data channel on the
WebRTC side, but there are solutions defined for handling SDP attribute
conveyance for such situations. ). Indicating that a SIP solution may
follow kind of invalidates the whole work we have done."

[BA]  The group did indeed converge on SDP as the mechanism to negotiate
language and media modality (the subject of the draft).  As I read it, the
SDP Directorate review is not a request to reconsider that decision, but
rather a request for the document to more clearly indicate that SDP is not
being proposed as a solution to the routing problem.

"I prefer to just leave out the last sentence in 1.1. Saying that routing
is out-of-scope for this document is sufficient."

[BA]  Adam and Gunnar - Would the following work?

1.1 Applicability

Within this document, it is assumed that the negotiating endpoints
have already been determined, so that a per-stream negotiation
based on the Session Description Protocol (SDP) can proceed.

However, when setting up interactive communications sessions it
is first necessary to route signaling messages to the appropriate
endpoint(s). This document does not address the problem of
routing based on language and media capabilities.




On Thu, Jul 13, 2017 at 12:41 AM, Gunnar Hellström <
gunnar.hellstrom@omnitor.se> wrote:

> Bernard,
>
> I do not like the last sentence of 1.1. A long time ago, I stopped arguing
> for a SIP based solution when I realized that SDP is more often used than
> SIP in the WebRTC environment. Basing it on SDP makes it easier to convey
> the language and modality needs across the SIP / WebRTC border. (There is a
> complication that real-time text is an RTP stream on the SIP side and a
> multiplexed data channel on the WebRTC side, but there are solutions
> defined for handling SDP attribute conveyance for such situations. )
>
> Indicating that a SIP solution may follow kind of invalidates the whole
> work we have done. I prefer to just leave out the last sentence in 1.1.
> Saying that routing is out-of-scope for this document is sufficient.
> Gunnar
>
>
>
> Den 2017-07-12 kl. 19:21, skrev Adam Roach:
>
> Thanks. The text in 1.1, in particular, addresses my concern. The rest of
> the revisions look good as well.
>
> /a
>
> On 7/12/17 12:12, Bernard Aboba wrote:
>
>
> To resolve Issue 38 which arose from Adam Roach's review, I would like to
> suggest the following revision for Section 1 and introduction of a new
> applicability section 1.1 as follows:
>
>  1. Introduction
>
>     A mutually comprehensive language is helpful for human communication.
>     This document addresses the negotiation of human (natural) language
>     and media modality (spoken, signed, written) in real-time
>     communications.
>     A companion document [I-D.ietf-slim-multilangcontent] addresses
>     language selection in email.
>
>     Unless the caller and callee know each other or there is
>     contextual or out-of-
>     band information from which the language(s) and media modalities can
>     be determined, there is a need for spoken, signed, or written
>     languages
>     to be negotiated based on the caller's needs and the callee's
>     capabilities.
>     This need applies to both emergency and non-emergency calls.
>     For example, it is helpful for a caller to a company call center
>     or a Public Safety Answering Point (PSAP) to be able to indicate
>     preferred signed, written, and/or spoken languages, and for the callee
>     to be able to indicate its capabilities in this area, allowing
>     the call to proceed using the language(s) and media forms
>     supported by both.
>
>     For various reasons, including the ability to
>     establish multiple streams using different media (e.g., voice, text,
>     video), it makes sense to use a per-stream negotiation mechanism known
>     as the Session Description Protocol (SDP). Utilizing SDP enables
>     the solution described in this document to be applied to all
>     interactive communications negotiated using SDP, in emergency as well
>     as non-emergency scenarios.
>
>     By treating language as another SDP attribute that is negotiated along
>     with other aspects of a media stream, it becomes possible to
>     accommodate a range of users' needs and called party facilities. For
>     example, some users may be able to speak several languages, but have
>     a preference. Some called parties may support some of those
>     languages internally but require the use of a translation service for
>     others, or may have a limited number of call takers able to use
>     certain languages. Another example would be a user who is able to
>     speak but is deaf or hard-of-hearing and requires a voice stream plus
>     a text stream. Making language a media attribute allows the standard
>     session negotiation mechanism to handle this by providing the
>     information and mechanism for the endpoints to make appropriate
>     decisions.
>
>     The term "negotiation" is used here rather than "indication" because
>     human language (spoken/written/signed) can be negotiated in the same
>     manner as media (audio/text/video) and codecs. For example, if we
>     think
>     of a user calling an airline reservation center, the user may
>     have a set of languages he or she speaks, with perhaps preferences
>     for one or a few, while the airline reservation center will support a
>     fixed set of languages. Negotiation should select the user's most
>     preferred language that is supported by the call center. Both sides
>     should be aware of which language was negotiated. This is
>     conceptually similar to the way other aspects of each media stream
>     are negotiated using SDP (e.g., media type and codecs).
>
>     Since this is a protocol mechanism, the user equipment (UE client)
>     needs to know the user's preferred languages; a reasonable technique
>     could include a configuration mechanism with a default of the
>     language of the user interface. In some cases, a UE could tie
>     language and media preferences, such as a preference for a video
>     stream using a signed language and/or a text or audio stream using a
>     written/spoken language.
>
> 1.1 Applicability
>
>     Within this document, it is assumed that the negotiating endpoints
>     have already been determined, so that a per-stream negotiation
>     based on the Session Description Protocol (SDP) can proceed.
>
>     However, when setting up interactive communications sessions it
>     is first necessary to route signaling messages to the appropriate
>     endpoint(s). This document does not address the problem of
>     language-based routing. In order to enable intermediaries to make
>     make routing decisions based on language and media capabilities,
>     future documents may define extensions to the Session Initiation
>     Protocol (SIP).
>
>
> On Wed, Jul 12, 2017 at 10:11 AM, Bernard Aboba <bernard.aboba@gmail.com
> <mailto:bernard.aboba@gmail.com> <bernard.aboba@gmail.com>> wrote:
>
>     In reviewing open tickets
>     against draft-ietf-slim-negotiating-human-language, it appears to
>     me that Issue 38 remains unresolved.
>
>     This issue was raised by ART AD Adam Roach in his review:
>     ​https://mailarchive.ietf.org/arch/msg/slim/
> fZmbXKtwn1771DoZhh1Kt_kUWf4
>     <https://mailarchive.ietf.org/arch/msg/slim/
> fZmbXKtwn1771DoZhh1Kt_kUWf4>
> <https://mailarchive.ietf.org/arch/msg/slim/fZmbXKtwn1771DoZhh1Kt_kUWf4>
>
>     " Aside -- I have a concern that negotiating language in SDP rather
>
>         than SIP makes it necessary for proxies to look into SDP to make
>         routing decisions, which is a pretty substantial layer violation
>         (keep in mind, for example, that SIP was originally envisioned to
>         contain S/MIME encrypted bodies, which would render the SDP
>         unreadable by proxies). However, I note that section 5.1 indicates
>         that this has issue been litigated in the working group
>         already, and
>         that it chose to do things in the way documented in the
>         current draft."
>
>
>
>
>
>
> _______________________________________________
> SLIM mailing listSLIM@ietf.orghttps://www.ietf.org/mailman/listinfo/slim
>
>
> --
> -----------------------------------------
> Gunnar Hellström
> Omnitorgunnar.hellstrom@omnitor.se
> +46 708 204 288
>
>