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

Eric Rescorla <ekr@rtfm.com> Sun, 07 January 2018 23:28 UTC

Return-Path: <ekr@rtfm.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 2125112704A for <slim@ietfa.amsl.com>; Sun, 7 Jan 2018 15:28:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 wZtOfXySgvDi for <slim@ietfa.amsl.com>; Sun, 7 Jan 2018 15:28:15 -0800 (PST)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 EA8DA124B17 for <slim@ietf.org>; Sun, 7 Jan 2018 15:28:14 -0800 (PST)
Received: by mail-yw0-x22b.google.com with SMTP id v139so712729ywg.4 for <slim@ietf.org>; Sun, 07 Jan 2018 15:28:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IW4Q2JPbGqzMJAMoc2LmZKESeea3CtTUWA7xn389Uys=; b=P/+gyXbJ8J98C0J/rlNRsFbD0VypPodGctZoAM3xHCmwrlV/RlWgxdWsh0WVI4axnF 7ozAVQ+PyVwgY629W4kE9v2tHKAppqQS9/0xZqxOgJLlRgMfiFgM+kJFrNXZqAlJAC/e RPAfuRf/c10sL8WHIhvn9yzEfqCmxgJYVsfGdZmwd56ft9FciW5MZJas112SsW4o10ij y6Qtjc8f6SfkcNqFJvoj9tLDfkiiOAjZ6+7YE6RgCO3jr3SGGBwtmSfbnnayls1YDrJ0 wLKi7s1eKxenEgCqy6H0S3fPRzca/1S/CtvrXnUXvJxawmtqeULiAM8YrHTJHl91Vuzl s2TQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IW4Q2JPbGqzMJAMoc2LmZKESeea3CtTUWA7xn389Uys=; b=DaETsYhEbcHJHsKC12xJRLUZrwzZJwRkgv41GbO+6e0h8onu4DCa4O1ai5TEc7RkGG pT86tClQ4TFMlxowDL4R5shp9GaxaCOK7fvxGXctjhF9I0w+RzjN3fUWt+qnVYAoBE1i aaFI049kZ9KTuZTFiWvvxKgiwejB1152zgq7f82OZ+DxLU9ZU7Tcm9b7GK7Y72pqc+yT JFtrGTvrFkrnt2K5nd3e2nJOFIIOiOXa29JM8LILW1v1ydQYoGBLJwORQeXicVWuzMKL nNBzhtWNZXBwmzL8ahxkEraYEgQjsVDyqKHvaobWwwlNZj39qmf86D41KjSn9ueo8gwM SDFg==
X-Gm-Message-State: AKGB3mKropK5nmwS4yW07WNYiXIB6n/mNZsY5LtZGBnrdS9SunM5YwXj KQgrJ+iriLEIzxLMUAYWSqlkKWc/qd/9WxjGufOybg==
X-Google-Smtp-Source: ACJfBov0k0B0de+T6XAjrzSrs+88mI9ZZcVA5+CObpgXKrqM2TonXsjj/wgb+8PMQlcw1BdUUmW9r+hlJuwWMsCHqOo=
X-Received: by 10.129.114.2 with SMTP id n2mr1974030ywc.296.1515367694076; Sun, 07 Jan 2018 15:28:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.123.132 with HTTP; Sun, 7 Jan 2018 15:27:33 -0800 (PST)
In-Reply-To: <8cbf760f-8998-3f77-f294-ee7048c1ac32@omnitor.se>
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> <CABcZeBPwb5LzCEpaOMbR9CeETHSZiigovkTMhKm_3K=hsWZckA@mail.gmail.com> <8cbf760f-8998-3f77-f294-ee7048c1ac32@omnitor.se>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 7 Jan 2018 15:27:33 -0800
Message-ID: <CABcZeBPMsR-maTZiYRXQtTeJES1qUqW+2wgJQ5+QE7SfvPjFKg@mail.gmail.com>
To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= <gunnar.hellstrom@omnitor.se>
Cc: Bernard Aboba <bernard_aboba@hotmail.com>, "slim@ietf.org" <slim@ietf.org>
Content-Type: multipart/alternative; boundary="001a1141b0b01c1ff80562380981"
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/u5K5gbdEwFLlAn4fOwyLranF3Xk>
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 23:28:17 -0000

On Sun, Jan 7, 2018 at 12:43 PM, Gunnar Hellström <
gunnar.hellstrom@omnitor.se> wrote:

> Den 2018-01-07 kl. 15:36, skrev Eric Rescorla:
>
>
>
> On Sat, 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.
>>
>
> Thanks. I think it would be helpful to put this logic in the draft.
>
> That said, as I noted in my review, it is still possible to get some media
> (early media) prior to receiving the answer, so this isn't a complete
> solution.
>
> <GH> Good discussion. However, I wonder what problem you see with early
> media? The offering party is supposed to express both which media and which
> languages are supported for both sending and receiving.
>
> The answering party then has all needed information to start sending a
> matching language in a matching media as early media. The offering party
> will not see any explicit information about what language and media is
> used, but hopefully one (or more ) media and language(s) from the
> hlang-recv attributes will be sent, so that the contents will be perceived
> and understood.
>
> Then, the answer is needed with both accepted media and the indications
> about which language and media the answering part prefers for receive. That
> will be conveyed in the answer and the enabled media and selected languages
> can be used both ways.
>

The point I'm making is just that having the answer contain the selected
language is not totally sufficient to guarantee that the offerer knows what
will be sent by the answerer, because media can flow from the answerer to
the offerer prior to the answer arriving.


Your review ended a bit abruptly. Was there some intended sentence missing
> at the end? It ended:
>
> " One reason you might is that you expect
> the answer to resolve which language is in use, however because SIP
> supports early media (i.e., media which is delivered prior to the
> answer.)"
>
>
I was just making the point above.


> We have some similarities between the draft and RFC 4796 SDP Content
> Attribute.  The content attribute indicates only  what is intended to be
> SENT in the media, while we have indications separately for both
> directions. So, that is an existing example that it may be accepted to
> specify intentions for what to send.
>

But that's not a negotiation, it's just metadata decoration.

-Ekr


>
> I will check further where to add more explaining reasoning.
>
> Thanks,
>
> Gunnar
>
>
> -Ekr
>
>
>
>
> _______________________________________________
> SLIM mailing listSLIM@ietf.orghttps://www.ietf.org/mailman/listinfo/slim
>
>
> --
> -----------------------------------------
> Gunnar Hellström
> Omnitorgunnar.hellstrom@omnitor.se
> +46 708 204 288
>
>