Re: [Slim] Protocol Action: 'Negotiating Human Language in Real-Time Communications' to Proposed Standard (draft-ietf-slim-negotiating-human-language-24.txt)

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Tue, 20 February 2018 21:29 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 0D501120724 for <slim@ietfa.amsl.com>; Tue, 20 Feb 2018 13:29:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 zxrshPBbknU7 for <slim@ietfa.amsl.com>; Tue, 20 Feb 2018 13:29:07 -0800 (PST)
Received: from bin-vsp-out-02.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (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 C1D8412DA73 for <slim@ietf.org>; Tue, 20 Feb 2018 13:29:04 -0800 (PST)
X-Halon-ID: 0ba8d4f2-1685-11e8-9bc4-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [87.96.161.61]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id 0ba8d4f2-1685-11e8-9bc4-005056917f90; Tue, 20 Feb 2018 22:28:52 +0100 (CET)
To: Randall Gellens <rg+ietf@randy.pensive.org>
Cc: slim@ietf.org, draft-ietf-slim-negotiating-human-language@ietf.org, slim-chairs@ietf.org, The IESG <iesg@ietf.org>, alexey.melnikov@isode.com, bernard.aboba@gmail.com, rfc-editor@rfc-editor.org
References: <151915022392.3979.9697242318707955341.idtracker@ietfa.amsl.com>
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
Message-ID: <299e3b20-211f-9610-246b-8f294edf661b@omnitor.se>
Date: Tue, 20 Feb 2018 22:28:55 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <151915022392.3979.9697242318707955341.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/ADz8V5nUj8B8_qirgXcqTj6c3Zs>
Subject: Re: [Slim] Protocol Action: 'Negotiating Human Language in Real-Time Communications' to Proposed Standard (draft-ietf-slim-negotiating-human-language-24.txt)
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: Tue, 20 Feb 2018 21:29:09 -0000

Good to see, and congratulations Randall!

Can we switch topics now to the functionality extensions, specified in:

https://datatracker.ietf.org/doc/draft-hellstrom-slim-modality-grouping/

Regards

Gunnar



Den 2018-02-20 kl. 19:10, skrev The IESG:
> The IESG has approved the following document:
> - 'Negotiating Human Language in Real-Time Communications'
>    (draft-ietf-slim-negotiating-human-language-24.txt) as Proposed Standard
>
> This document is the product of the Selection of Language for Internet Media
> Working Group.
>
> The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell.
>
> A URL of this Internet Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/
>
>
>
>
> Technical Summary:
>
>     In establishing a multi-media communications session, it can be
>     important to ensure that the caller's language and media needs
>     match the capabilities of the called party.  This is important
>     in non-emergency uses (such as when calling a company call
>     center) or in emergencies where a call can be handled by a
>     call taker capable of communicating with the user, or a
>     translator or relay operator can be bridged into the call
>     during setup.
>
>     This document describes the problem of negotiating human
>     (natural) language needs, abilities and preferences
>     in spoken, written and signed languages.  It also provides
>     a solution using new stream attributes within the Session
>     Description Protocol (SDP).
>
> Working Group Summary:
>
>
> This draft has undergone 13 revisions since its initial IETF last call (which occurred on draft -06).  These
> revisions were required to address issues raised by the IETF community, such as:
>
> 1. The meaning of the "*" in language negotiation. The SDP directorate review in the initial IETF last call expressed concern
> over the handling of the asterisk, which had the properties of a session attribute while being included within individual m-lines.
> WG consensus was to remove the asterisk, whose role had been advisory.
>
> 2. Routing of calls.  The SDP directorate review in the initial IETF last call expressed concern about whether the document
> intended the use of SDP for routing of SIP traffic.  Language was added to indicate clearly that call routing was
> out of scope.
>
> 3. Combining of hlang-send/hlang-recv. In IETF last call, a reviewer suggested that the document allow combining the
> hlang-send and recv indications so as to allow more efficient representation in cases where language preference is
> symmetrical. This suggestion was not accepted by the WG since it was not clear that the efficiency was worth the
> additional complexity.
>
> In addition to issues brought up in IETF last call, there was substantial WG discussion on the following points:
>
> 4. Undefined language/modality combinations. Language tags do not always distinguish spoken from written
> language, so some combinations of languages and media are not well defined. The text in Section 5.4
> resulted from WG discussion of several scenarios:
>
>      a. Captioning. While the document supports negotiation of sign language in a video stream, it does not
>      define how to indicate that captioning (e.g. placement of text within the video stream) is desired.
>      WG Consensus did not support use of suppressed script tags for this purpose.
>
>      b. SignWriting (communicating sign language in written form). Currently only a single language tag has been defined
>      for SignWriting so that written communication of sign language in a text stream (or in captioning) is also not
>      defined.
>
>      c. Lipreading (spoken language within video). There was not WG consensus for explicitly indicating
>      the desire for spoken language in a video stream (e.g. by use of the -Zxxx script subtag), since the
>      ability to negotiate "lip sync" is already provided in RFC 5888.
>
> As a result of these discussions, Section 5.4 leaves a number of potential combinations of language and
> media undefined.  Assuming that implementation experience shows a need to define these scenarios, they
> can be addressed in future work.
>
> 5. Preferences between media.  As an example, an individual might be able to understand written English communicated using
> Realtime Text, but might prefer spoken English audio.  The current draft enables all modes of communication to be
> negotiated, but does not indicate a preference between them.  WG consensus was that it was acceptable and
> possibly more reliable for mutually supported media to be negotiated and brought up, then let the conversants
> decide which media to use, rather than taking on the additional complexity of negotiating media preference beforehand.
>
> During discussion, it was pointed out that quality issues could influence media preferences during a call.
> For example, on a call where audio, video and text are all available, sending video may interfere with
> audio quality so that video sending needs to be disabled.  Alternatively, audio quality could be poor so that
> the conversants need to resort to text.  So media quality issues can negate the "best laid plans" of
> media preference negotiation.
>
> Document Quality:
>
>    There are no current implementations of draft-ietf-slim-negotiating-language.  However, the North American Emergency Number Association
>    (NENA) has referenced it in NENA 08-01 (i3 Stage 3 version 2) in describing attributes of emergency calls presented to an ESInet and
>    within 3GPP some CRs introduced in SA1 have referenced the functionality.  Therefore implementation is expected.
>
> Personnel:
>
>    Bernard Aboba is the Document Shepard.  The responsible area director is Alexey Melnikov.
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

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