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

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Mon, 08 January 2018 19:02 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
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 2139312025C for <slim@ietfa.amsl.com>; Mon, 8 Jan 2018 11:02:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 YNHmV_C2HdXT for <slim@ietfa.amsl.com>; Mon, 8 Jan 2018 11:02:13 -0800 (PST)
Received: from bin-vsp-out-01.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFA3B12D7E9 for <slim@ietf.org>; Mon, 8 Jan 2018 11:02:12 -0800 (PST)
X-Halon-ID: 4de80f89-f4a6-11e7-ab14-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [83.209.156.53]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id 4de80f89-f4a6-11e7-ab14-005056917a89; Mon, 08 Jan 2018 20:01:17 +0100 (CET)
To: Eric Rescorla <ekr@rtfm.com>, 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>
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> <CABcZeBPsXfPGBRMTRJSNZiHaXA8dT1MYXsU+3GdPsmLyQHZigg@mail.gmail.com> <p06240605d679600b6eea@99.111.97.136> <p06240606d67963d25192@99.111.97.136> <CABcZeBNSnzAgzAwZN4_hWWYckLTSu6h0qRBdot0E+-1jm9kRyw@mail.gmail.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@omnitor.se>
Message-ID: <4966cfc1-089c-4441-ce05-45181272e7b0@omnitor.se>
Date: Mon, 8 Jan 2018 20:01:57 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <CABcZeBNSnzAgzAwZN4_hWWYckLTSu6h0qRBdot0E+-1jm9kRyw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------6BC2231022725173F184B4DF"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/rT4sgFmfkjLofLJ2VpkeVArtpE4>
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 19:02:17 -0000

Thanks Randall for providing your proposed wording.

I see a need for some small adjustments. See inline.


Den 2018-01-08 kl. 19:22, skrev Eric Rescorla:
> WFM. thanks
>
> -Ekr
>
>
> On Mon, Jan 8, 2018 at 10:10 AM, Randall Gellens 
> <rg+ietf@randy.pensive.org <mailto:rg+ietf@randy.pensive.org>> wrote:
>
>     At 9:57 AM -0800 1/8/18, Randall Gellens wrote:
>
>          At 9:48 AM -0800 1/8/18, Eric Rescorla wrote:
>
>               On Mon, Jan 8, 2018 at 9:41 AM, Randall Gellens
>             <<mailto:rg+ietf@randy.pensive.org
>             <mailto:rg%2Bietf@randy.pensive.org>>rg+ietf@randy.pensive.org
>             <mailto:rg%2Bietf@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:<mailto:rg%2Bietf@randy.pensive.org
>             <mailto:rg%252Bietf@randy.pensive.org>>rg+ietf@randy.pensive.org
>             <mailto:rg%2Bietf@randy.pensive.org>><mailto:rg%2Bietf@randy.pensive.org
>             <mailto:rg%252Bietf@randy.pensive.org>>rg+ietf@randy.pensive.org
>             <mailto:rg%2Bietf@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:<mailto:bernard.aboba@gmail.com
>             <mailto:bernard.aboba@gmail.com>>bernard.aboba@gmail.com
>             <mailto:bernard.aboba@gmail.com>><mailto:bernard.aboba@gmail.com
>             <mailto:bernard.aboba@gmail.com>>bernard.aboba@gmail.com
>             <mailto:bernard.aboba@gmail.com>><mailto:<mailto:bernard.aboba@gmail.com
>             <mailto:bernard.aboba@gmail.com>>bernard.aboba@gmail.com
>             <mailto:bernard.aboba@gmail.com>><mailto:bernard.aboba@gmail.com
>             <mailto:bernard.aboba@gmail.com>>bernard.aboba@gmail.com
>             <mailto:bernard.aboba@gmail.com>> wrote:
>
>                 On Jan 6, 2018, at 6:55 PM, Eric Rescorla
>             <<mailto:<mailto:<mailto:ekr@rtfm.com
>             <mailto:ekr@rtfm.com>>ekr@rtfm.com
>             <mailto:ekr@rtfm.com>><mailto:ekr@rtfm.com
>             <mailto:ekr@rtfm.com>>ekr@rtfm.com
>             <mailto:ekr@rtfm.com>><mailto:<mailto:ekr@rtfm.com
>             <mailto:ekr@rtfm.com>>ekr@rtfm.com
>             <mailto:ekr@rtfm.com>><mailto:ekr@rtfm.com
>             <mailto:ekr@rtfm.com>>ekr@rtfm.com <mailto: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.
>
>
>          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.
>
>
>
>     The third paragraph below is the additional text added to the
>     Introduction (the first two paragraphs are unchanged):
>
>        By treating language as another SDP attribute that is negotiated
>        along with other aspects of a media stream, it becomes possible to
>        accommodate a range of users' needs and called party
>     facilities.  For
>        example, some users may be able to speak several languages, but
>     have
>        a preference.  Some called parties may support some of those
>        languages internally but require the use of a translation
>     service for
>        others, or may have a limited number of call takers able to use
>        certain languages.  Another example would be a user who is able to
>        speak but is deaf or hard-of-hearing and and desires a voice stream
>        to send spoken language plus a text stream to receive written
>        language.  Making language a media attribute allows the standard
>        session negotiation mechanism to handle this by providing the
>        information and mechanism for the endpoints to make appropriate
>        decisions.
>
>        The term "negotiation" is used here rather than "indication"
>     because
>        human language (spoken/written/signed) can be negotiated in the
>     same
>        manner as media (audio/text/video) and codecs.  For example, if we
>        think of a user calling an airline reservation center, the user may
>        have a set of languages he or she speaks, with perhaps preferences
>        for one or a few, while the airline reservation center will
>     support a
>        fixed set of languages.  Negotiation should select the user's most
>        preferred language that is supported by the call center. Both sides
>        should be aware of which language was negotiated.  This is
>        conceptually similar to the way other aspects of each media stream
>        are negotiated using SDP (e.g., media type and codecs).
>
>        In the offer/answer model used here, the offer contains a set of
>        languages per media that the caller is capable of using, and the
>
<GH> "caller" should be "offerer" to match o/a language.
>
>        answer contains one language per media that the answerer will
>
<GH>"one language per media that the answerer will support" should be 
"one language per media and direction that the answerer will support for 
language communication"
>
>        support.  Supporting languages and/or modalities can require taking
>        extra steps, such as having a call handled by an agent who speaks a
>        requested language and/or with the ability to use a requested
>        modality, or bridging external translation or relay resources into
>        the call, etc.  The answerer indicates in the answer which
>     additional
>        steps it is committing to.  This model also provides knowledge so
>
<GH>"which additional steps it is committing to" should be "the 
resulting language and modality support when the additional steps are 
applied"
>
>        both ends know what has been negotiated.  Note that additional
>     steps
>        required to support the indicated languages or modalities may
>     or may
>        not be in place in time for any early media.
>
>
/Gunnar
>
>
>
>
>                 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
>             SLIM@ietf.org <mailto:SLIM@ietf.org>
>             https://www.ietf.org/mailman/listinfo/slim
>             <https://www.ietf.org/mailman/listinfo/slim>
>
>
>
>          --
>          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
>
>          _______________________________________________
>          SLIM mailing list
>         SLIM@ietf.org <mailto:SLIM@ietf.org>
>         https://www.ietf.org/mailman/listinfo/slim
>         <https://www.ietf.org/mailman/listinfo/slim>
>
>
>
>     -- 
>     Randall Gellens
>     Opinions are personal;    facts are suspect;    I speak for myself
>     only
>     -------------- Randomly selected tag: ---------------
>     If we do not change our direction we are likely to end up where we are
>     headed.
>
>
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288