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 <> Tue, 20 February 2018 21:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D501120724 for <>; Tue, 20 Feb 2018 13:29:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zxrshPBbknU7 for <>; Tue, 20 Feb 2018 13:29:07 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C1D8412DA73 for <>; Tue, 20 Feb 2018 13:29:04 -0800 (PST)
X-Halon-ID: 0ba8d4f2-1685-11e8-9bc4-005056917f90
Received: from [] (unknown []) by (Halon) with ESMTPSA id 0ba8d4f2-1685-11e8-9bc4-005056917f90; Tue, 20 Feb 2018 22:28:52 +0100 (CET)
To: Randall Gellens <>
Cc:,,, The IESG <>,,,
References: <>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <>
Message-ID: <>
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: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [Slim] Protocol Action: 'Negotiating Human Language in Real-Time Communications' to Proposed Standard (draft-ietf-slim-negotiating-human-language-24.txt)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Selection of Language for Internet Media <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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:



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:
> 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

Gunnar Hellström
+46 708 204 288