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

Eric Rescorla <ekr@rtfm.com> Mon, 08 January 2018 17:49 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 AC642127023 for <slim@ietfa.amsl.com>; Mon, 8 Jan 2018 09:49:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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_NONE=-0.0001] 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 cZux5lhPcm3r for <slim@ietfa.amsl.com>; Mon, 8 Jan 2018 09:49:06 -0800 (PST)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 705E1127275 for <slim@ietf.org>; Mon, 8 Jan 2018 09:49:06 -0800 (PST)
Received: by mail-yw0-x22f.google.com with SMTP id x62so760184ywg.11 for <slim@ietf.org>; Mon, 08 Jan 2018 09:49:06 -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=gA3A2XFv+ofUckG7PlCZE/4S6l5oVYcgoUJi7M1rCqE=; b=hg0oMriX7wLzdVi2nRo+7T/6naL+NZW/Sr/ZDofHhkaW3n/UvDbfD03tRXkpgMnQsA s+sqdw2Z15jWDi8i9VgPbeFLxj+mWtVGyY3qRRkmegATfLPpzDKOiUa8BM6I/f+DUk3U 0MErtwPlsKGM4M3nBGT0WkNhm2ybUMvRAJpa2JxaF6ptbUj9iWHhC8xgu4Y52j/SdP34 nNDLOynpD6Ct4mT3iyqXUUAg4FlIul6tkffboVQZq+T3cxsSXvrg/edWmvQ9q4o34Ky5 3IiEwRt6fnCgLhNexe7PbGBsNiRweXPEnIiXbOCvcbZLYAiHSRb0/WR1cezdyZnVIA5Z Kpiw==
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=gA3A2XFv+ofUckG7PlCZE/4S6l5oVYcgoUJi7M1rCqE=; b=eAggQ0m0XmO2+ezvXV+qN3jMw+nixFynOs6tsXQ16129LgYC+NWJokdRkK2CL0Pccw m5mJddhDEE9EI19NrMFKkZopeV34nf28KmBq8B4pyCi66t31ZvbC6hyc24BGz4gCuBUP zSBHtw+lWKVNe3TNARaWuw7TvhFYNYmLD0NfYT9SB3of1GIRlR8NhYYEKWTJoHyb9y/T ZF37NlF89msd1WCcJKtjZYcNKXGoXb75oNPTyN9KuyJjSgkv2TamfOVnf9LS7LobYdmU WG1jzceESKRiiQomYOJImKSOLjqLIIhrutLP0TXTniMlOBLnHACyPzxbDnriDpC4oSPM TZwQ==
X-Gm-Message-State: AKGB3mL9tdgGMeKdi/1yFVLg61L8P4zSL/pczDRYOZiMz/XBXbiHKI4J w55m53g37PNkLgPIfmRLv5GApU2y4Xm9ck4QYV1s0g==
X-Google-Smtp-Source: ACJfBouHeT+5Tkb3bhF3/cqvyEemnn80xLdOUm8osATlhL9pfZOdnMty7nh2Z3L3O0v7qi/jc9yK3IU4l1jrjPXKrP4=
X-Received: by 10.129.152.16 with SMTP id p16mr11779646ywg.378.1515433745436; Mon, 08 Jan 2018 09:49:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.75.20 with HTTP; Mon, 8 Jan 2018 09:48:24 -0800 (PST)
In-Reply-To: <p06240603d6795cbba847@99.111.97.136>
References: <151528917109.10947.12045320996364596931.idtracker@ietfa.amsl.com> <CABcZeBNQLuaMLa3=gWqaYHL_ynQ1t+HRtsgEebCRORm+OUA0iw@mail.gmail.com> <ECD0168D-9C53-4ACA-BF28-C631DAE38A4D@gmail.com> <CABcZeBPwb5LzCEpaOMbR9CeETHSZiigovkTMhKm_3K=hsWZckA@mail.gmail.com> <p06240601d6785f2e3ad4@99.111.97.136> <CABcZeBNX4iTuvuqvvqjAQEgnhkV4f5Z1e8Ac2ebWOf=prAcPKg@mail.gmail.com> <p06240603d6795cbba847@99.111.97.136>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 8 Jan 2018 09:48:24 -0800
Message-ID: <CABcZeBPsXfPGBRMTRJSNZiHaXA8dT1MYXsU+3GdPsmLyQHZigg@mail.gmail.com>
To: Randall Gellens <rg+ietf@randy.pensive.org>
Cc: Bernard Aboba <bernard_aboba@hotmail.com>, "slim@ietf.org" <slim@ietf.org>, Bernard Aboba <bernard.aboba@gmail.com>
Content-Type: multipart/alternative; boundary="94eb2c0baa9c13f4420562476a1c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/Al4SUobgXBp8M3vd35cgOsfeIa4>
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: Mon, 08 Jan 2018 17:49:08 -0000

On Mon, Jan 8, 2018 at 9:41 AM, Randall Gellens <rg+ietf@randy.pensive.org>
wrote:

> At 5:56 PM -0800 1/7/18, Eric Rescorla wrote:
>
>  On Sun, Jan 7, 2018 at 5:22 PM, Randall Gellens <<mailto:
>> rg+ietf@randy.pensive.org>rg+ietf@randy.pensive.org> wrote:
>>
>>  At 6:36 AM -0800 1/7/18, Eric Rescorla wrote:
>>
>>   On Sat, Jan 6, 2018 at 7:31 PM, Bernard Aboba <<mailto:<mailto:
>> bernard.aboba@gmail.com>bernard.aboba@gmail.com><mailto:bernard.aboba@
>> gmail.com>bernard.aboba@gmail.com> wrote:
>>
>>   On Jan 6, 2018, at 6:55 PM, Eric Rescorla <<mailto:<mailto:ekr@rtfm.com
>> >ekr@rtfm.com><mailto:ekr@rtfm.com>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.
>>
>>
>>  I am not clear on what logic we want to add to the draft, or what about
>> the draft this logic is explaining.
>>
>>
>>  It would be helpful to explain in the draft why you have deviated from
>> the otherwise near-universal SDP negotiation pattern of each side
>> advertising what it accepts.
>>
>
> I'm not clear on what you're referring to.  Are you talking about early
> offer versus late offer?  To my understanding, the draft follows a typical
> offer/answer model: the caller lists the media and languages it supports,
> and the callee answers with the media and languages it supports.


That's not what this draft does. The typical SDP pattern is what you say
here: that the offerer (which might or might not be the caller) lists what
it supports and the answerer lists what it supports.
So, for instance, the offerer might list "VP8, H.264" and the answerer
might respond with "VP8, H.264", at which point either side could use
either codec (or intermix them). What this draft does is have the offerer
list what it supports and the answerer picks exactly one. I understood from
the previous emails in the thread that the reason for this design was so
that each side then knew exactly what languages would be used. However, as
noted upthread, this draft does not provide this function if early media is
used, because the media is delivered to the offerer prior to receiving the
answer, so the offerer is in the same position as it would be with the
typical negotiation model.


  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.
>>
>>
>>  The draft provides a useful mechanism that will be helpful.  As an
>> example of the fact that others find it useful, NENA has included it in
>> it's next-generation emergency call architecture standards. The draft does
>> not try to solve all problems related to human language in real-time
>> calling.
>>
>>
>>  I don't think I claimed it wasn't useful.
>>
>>  The rationale provided for this design is that you wish to have the
>> answerer notify the offerer of which language it would be providing. The
>> point I am making is that there is at least one important case where this
>> design does not provide that, which seems like it's relevant to the design
>> question.
>>
>
> I think I'm still not understanding your concern.  Even without providing
> a mechanism for the caller to know the languages used with any early media,
> the draft is still meeting a need.


I'm honestly not sure what you're responding to here. I'm not saying that
the draft doesn't meet a need.

-Ekr


>
>
> --
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> Imagination is more important than facts. --Albert Einstein
>