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

Randall Gellens <> Mon, 08 January 2018 17:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D85AF12711D for <>; Mon, 8 Jan 2018 09:57:13 -0800 (PST)
X-Quarantine-ID: <yN5IpjBizZ7S>
X-Virus-Scanned: amavisd-new at
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yN5IpjBizZ7S for <>; Mon, 8 Jan 2018 09:57:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id BBCFF127023 for <>; Mon, 8 Jan 2018 09:57:11 -0800 (PST)
Received: from [] ( by with ESMTP (EIMS X 3.3.9); Mon, 8 Jan 2018 09:57:41 -0800
Mime-Version: 1.0
Message-Id: <p06240605d679600b6eea@[]>
In-Reply-To: <>
References: <> <> <> <> <p06240601d6785f2e3ad4@> <> <p06240603d6795cbba847@> <>
X-Mailer: Eudora for Mac OS X
Date: Mon, 08 Jan 2018 09:57:02 -0800
To: Eric Rescorla <>
From: Randall Gellens <>
Cc: Bernard Aboba <>, "" <>, Bernard Aboba <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Archived-At: <>
Subject: Re: [Slim] Eric Rescorla's No Objection on draft-ietf-slim-negotiating-human-language-19: (with COMMENT)
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: Mon, 08 Jan 2018 17:57:14 -0000

At 9:48 AM -0800 1/8/18, Eric Rescorla wrote:

>  On Mon, Jan 8, 2018 at 9:41 AM, Randall Gellens 
> <<>> wrote:
>  At 5:56 PM -0800 1/7/18, Eric Rescorla wrote:
>   On Sun, Jan 7, 2018 at 5:22 PM, Randall Gellens 
> <<mailto:<>><>> 
> 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:<>><>><mailto:<>><>> 
> wrote:
>    On Jan 6, 2018, at 6:55 PM, Eric Rescorla 
> <<mailto:<mailto:<>><>><mailto:<>><>> 
> 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.

Thanks, I think I understand your concern now.  You'd like the draft 
to explain why the answer contains one language per media stream, 
which is partly for provide knowledge so both ends know what has been 
negotiated, but also because supporting languages and/or modalities 
may require taking extra steps, such as having a call handled by an 
agent who speaks a requested language and/or can use a requested 
modality, or bridging external translation or relay resources into 
the call, etc.  The answerer indicates which additional steps it is 
committing to.  These steps may or may not be in place in time for 
early media.  I can add text explaining this to the Introduction.

>    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
>  _______________________________________________
>  SLIM mailing list

Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Algol was a great improvement on most of its successors.
                                          --C.A.R Hoare