Re: [Slim] Eric Rescorla's No Objection on draft-ietf-slim-negotiating-human-language-19: (with COMMENT)

"Randall Gellens (IETF)" <rg+ietf@randy.pensive.org> Sun, 07 January 2018 05:11 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 E213B124D37 for <slim@ietfa.amsl.com>; Sat, 6 Jan 2018 21:11:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 ARxz3kH_VAjn for <slim@ietfa.amsl.com>; Sat, 6 Jan 2018 21:11:08 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 039AD1200F3 for <slim@ietf.org>; Sat, 6 Jan 2018 21:11:07 -0800 (PST)
Received: from [99.111.97.179] (127.0.0.1) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sat, 6 Jan 2018 21:11:39 -0800
Content-Type: multipart/alternative; boundary="Apple-Mail-7DF45E14-0C81-4AEE-8CA3-6D891EA8660B"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
From: "Randall Gellens (IETF)" <rg+ietf@randy.pensive.org>
In-Reply-To: <ECD0168D-9C53-4ACA-BF28-C631DAE38A4D@gmail.com>
Date: Sat, 06 Jan 2018 21:02:43 -0800
Cc: Eric Rescorla <ekr@rtfm.com>, Bernard Aboba <bernard_aboba@hotmail.com>, "slim@ietf.org" <slim@ietf.org>
Message-Id: <D922629B-6004-49FA-99C6-5F45C15A79A5@randy.pensive.org>
References: <151528917109.10947.12045320996364596931.idtracker@ietfa.amsl.com> <CO2PR10MB0101A52C512BACCBEE0CF75593120@CO2PR10MB0101.namprd10.prod.outlook.com> <CABcZeBNQLuaMLa3=gWqaYHL_ynQ1t+HRtsgEebCRORm+OUA0iw@mail.gmail.com> <ECD0168D-9C53-4ACA-BF28-C631DAE38A4D@gmail.com>
To: Bernard Aboba <bernard.aboba@gmail.com>
X-Mailer: iPad Mail (14F89)
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/rkTN3fWbHL_05t6OaPIcuTpXeHk>
Subject: Re: [Slim] Eric Rescorla's No Objection on draft-ietf-slim-negotiating-human-language-19: (with COMMENT)
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: Sun, 07 Jan 2018 05:11:10 -0000

It hasn't been my understanding that language would be sprung on users; if video is requested in an offer to carry ASL, that would be in the offer, and if the answerer can support ASL, the answer includes video with ASL. In North America, callers needing sign language interpretation or text translation usually initiate calls via the interpreter/relay service, but this might not be true elsewhere. In North America, PSAPs have the ability to handle text calls (legacy PSAPs support TTY; next-gen PSAPs support RTT). Calls needing language translation might internally be handled by staff who speak the language or an external language translation service might be bridged in, (e.g., an emergency call routed to a PSAP in San Diego might have call takers who speak Spanish but might need a third-party translator for French, the opposite for a PSAP in Montreal). 

Sent from my iPad

> On Jan 6, 2018, at 7:31 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> 
> On Jan 6, 2018, at 6:55 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
>>> For disabled users, the capabilities may not be symmetric. 
>> 
>> But this is true for ordinary SDP as well. I might be able to receive H.264 but not send it.
> 
> [BA] Thanks. The draft should explain the reasoning. IMHO the argument goes sonething like this:
> 
> A pure recv/recv negotiation will not necessarily disclose beforehand what special services are needed for the call - services (e.g. ASL interpretation or RTT handling) that could take time to acquire. 
> 
> Since the actual video media sent is not labelled as ASL even if the answerer has ASL interpreters it can pull in and therefore advertises in SDP ASL reception capability in video, a recv/recv negotiation doesn’t tell the Answerer that the Offerer will need them, so the Answerer may need to (frantically) arrange for ASL interpretation after initial receipt of media. In an emergency, that can chew up valuable time.
> 
> 
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>