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
- [Slim] Protocol Action: 'Negotiating Human Langua… The IESG
- Re: [Slim] Protocol Action: 'Negotiating Human La… Gunnar Hellström