IETF Logo Mail Archive

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

Bernard Aboba <bernard.aboba@gmail.com> Sun, 07 January 2018 03:31 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 DA68A126B6D for <slim@ietfa.amsl.com>; Sat, 6 Jan 2018 19:31:53 -0800 (PST)
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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 fJMXbIE9UN-g for <slim@ietfa.amsl.com>; Sat, 6 Jan 2018 19:31:52 -0800 (PST)
Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (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 2E0F71201F8 for <slim@ietf.org>; Sat, 6 Jan 2018 19:31:52 -0800 (PST)
Received: by mail-pg0-x22a.google.com with SMTP id t67so3537526pgc.5 for <slim@ietf.org>; Sat, 06 Jan 2018 19:31:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=k74Z1HHdVK12N+YvrnF2iON/9CNq1MZOW1i3HUpfQa8=; b=Z/MtXrJ0hPvLvSoYEj7I+Afr6lWlYDYUuyu0O32S8fT6CjOQwKXA8jAPEVkRKMoJ4q VJD7nyt2FYCWuYaJccmkjx9Hl+VOXTQl5j/a/ly4N8SmCzIPEdpryYpS16sb8neoiold KjKeKrBYxC0XQObsA5ZUzNPQAUwc9IuDw+xMcz+t0mKdkVWAm8iUhzNE7E/nxY45Go13 Aiug3TzRfijsRlUYcNOG7k3cBopZ25KWl7ZgchN6e9wpbEYCGfNTwAcoujMwfiytYoFJ WJQkpQQKiTUijaVvQuuFgFeGKBVJ7dTDQNIYqBnFHkJxcBkxV3zC0AJ2rZpozjoOTtP8 GFUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=k74Z1HHdVK12N+YvrnF2iON/9CNq1MZOW1i3HUpfQa8=; b=VseQM2YxKZCc6CAHrmB+NiJCD+NqATJ7Uta1DSnIRTVccJXglfnubrzAhe55VqcZ26 eo5rfqbMaRiTMxsxjrgLRfDwy8Ta/HYhw3jdZFYTfWa+8EcP+6baTxwl0HveJSkYjvxj qyF/J1rGGjIsEK5bIj1Wy2mXtxffBna9iTSakb9umKcQXZlesOua8KL8lT8ZmTCgcxSs dnU656G1igMdoIi3N8nvVVRHyLk3iSmWcNovEdSHgx3bD7j6WcDzUIeVJWf3WBHNtfUU Nft85u9zCaoPeHbpPNhhJVpH8HZY84Wa3y4hEhkP0yTydYt+AqKXrd+YzBZUpVJ5486N Ligw==
X-Gm-Message-State: AKGB3mLUh/2s3KEvNZq7Puq+zpxksbBwo7KLG63uYEhjlVd1GPmXqCVD EvxQyNkr9zLQdprAbKFfmpM=
X-Google-Smtp-Source: ACJfBosCOhHryXEkvZhiqG8zF5A57ZiHhREA/MuvX4ZSnX8Go9qZqsrEeps+xerKdjlAFp8MVQGwCw==
X-Received: by 10.98.93.13 with SMTP id r13mr7234023pfb.5.1515295911408; Sat, 06 Jan 2018 19:31:51 -0800 (PST)
Received: from [10.169.227.21] (mobile-166-176-186-180.mycingular.net. [166.176.186.180]) by smtp.gmail.com with ESMTPSA id e5sm727498pff.160.2018.01.06.19.31.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Jan 2018 19:31:50 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-A2DEA06B-B248-4C82-BE27-A8DCA1E847E0"
Mime-Version: 1.0 (1.0)
From: Bernard Aboba <bernard.aboba@gmail.com>
X-Mailer: iPhone Mail (15C153)
In-Reply-To: <CABcZeBNQLuaMLa3=gWqaYHL_ynQ1t+HRtsgEebCRORm+OUA0iw@mail.gmail.com>
Date: Sat, 06 Jan 2018 19:31:49 -0800
Cc: Bernard Aboba <bernard_aboba@hotmail.com>, "slim@ietf.org" <slim@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <ECD0168D-9C53-4ACA-BF28-C631DAE38A4D@gmail.com>
References: <151528917109.10947.12045320996364596931.idtracker@ietfa.amsl.com> <CO2PR10MB0101A52C512BACCBEE0CF75593120@CO2PR10MB0101.namprd10.prod.outlook.com> <CABcZeBNQLuaMLa3=gWqaYHL_ynQ1t+HRtsgEebCRORm+OUA0iw@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/_9b6STg48aFTJotQls03hxy-aiw>
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 03:31:54 -0000

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.

v2.29.0 | Report a Bug | By Email | System Status