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 20:53 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 6374C129C6A for <slim@ietfa.amsl.com>; Mon, 8 Jan 2018 12:53:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 L0ovPfIny8vG for <slim@ietfa.amsl.com>; Mon, 8 Jan 2018 12:53:09 -0800 (PST)
Received: from bin-vsp-out-01.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (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 50FF4127909 for <slim@ietf.org>; Mon, 8 Jan 2018 12:53:09 -0800 (PST)
X-Halon-ID: cff99d2e-f4b5-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 cff99d2e-f4b5-11e7-ab14-005056917a89; Mon, 08 Jan 2018 21:52:18 +0100 (CET)
To: Randall Gellens <rg+ietf@randy.pensive.org>, Eric Rescorla <ekr@rtfm.com>
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> <4966cfc1-089c-4441-ce05-45181272e7b0@omnitor.se> <p06240607d679783f1b46@[99.111.97.136]>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@omnitor.se>
Message-ID: <6673eca6-5699-c773-6e2c-8c566dad0717@omnitor.se>
Date: Mon, 8 Jan 2018 21:52:58 +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: <p06240607d679783f1b46@[99.111.97.136]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/5qsjEVRJ_XhbUENDQrZGjSYKCpM>
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 20:53:13 -0000

Yes, Randall, your latest proposal below is acceptable.

/Gunnar


Den 2018-01-08 kl. 20:35, skrev Randall Gellens:
> At 8:01 PM +0100 1/8/18, Gunnar Hellström wrote:
>
>>  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 
>>> <<mailto:rg+ietf@randy.pensive.org>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:<mailto:rg%2Bietf@randy.pensive.org>rg+ietf@randy.pensive.org><mailto:rg%2Bietf@randy.pensive.org>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:<mailto:<mailto:rg%252Bietf@randy.pensive.org>rg%2Bietf@randy.pensive.org><mailto:rg%2Bietf@randy.pensive.org>rg+ietf@randy.pensive.org><mailto:<mailto:rg%252Bietf@randy.pensive.org>rg%2Bietf@randy.pensive.org><mailto:rg%2Bietf@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:<mailto:<mailto:bernard.aboba@gmail.com>bernard.aboba@gmail.com><mailto:bernard.aboba@gmail.com>bernard.aboba@gmail.com><mailto:<mailto:bernard.aboba@gmail.com>bernard.aboba@gmail.com><mailto:bernard.aboba@gmail.com>bernard.aboba@gmail.com><mailto:<mailto:<mailto:bernard.aboba@gmail.com>bernard.aboba@gmail.com><mailto:bernard.aboba@gmail.com>bernard.aboba@gmail.com><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:<mailto:<mailto:ekr@rtfm.com>ekr@rtfm.com><mailto:ekr@rtfm.com>ekr@rtfm.com><mailto:<mailto:ekr@rtfm.com>ekr@rtfm.com><mailto:ekr@rtfm.com>ekr@rtfm.com><mailto:<mailto:<mailto:ekr@rtfm.com>ekr@rtfm.com><mailto:ekr@rtfm.com>ekr@rtfm.com><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.
>>>
>>>
>>>   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.
>>>
>>>
>
> OK, here is the revised paragraph:
>
>    In the offer/answer model used here, the offer contains a set of
>    languages per media (and direction) that the offerer is capable of
>    using, and the answer contains one language per media (and direction)
>    that the answerer will 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 answer indicates the
>    media and languages that the answerer is committing to support
>    (possibly after additional steps have been taken).  This model also
>    provides knowledge so 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.
>
>
>
>>
>>>
>>>
>>>
>>>      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
>>>    <mailto:SLIM@ietf.org>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
>>>   <mailto:SLIM@ietf.org>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
>>>  <mailto:SLIM@ietf.org>SLIM@ietf.org
>>>
>>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim 
>>>
>>>
>>
>>  --
>>  -----------------------------------------
>>  Gunnar Hellström
>>  Omnitor
>>  <mailto:gunnar.hellstrom@omnitor.se>gunnar.hellstrom@omnitor.se
>>  +46 708 204 288
>>
>>  _______________________________________________
>>  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