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

[Gunnar Hellström <[e-mail]>]

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:[e-mail]>[e-mail]> 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:[e-mail]>[e-mail]><mailto:[e-mail]>[e-mail]> 
>>> 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:[e-mail]>[e-mail]><mailto:[e-mail]>[e-mail]><mailto:<mailto:[e-mail]>[e-mail]><mailto:[e-mail]>[e-mail]> 
>>> 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:[e-mail]>[e-mail]><mailto:[e-mail]>[e-mail]><mailto:<mailto:[e-mail]>[e-mail]><mailto:[e-mail]>[e-mail]><mailto:<mailto:<mailto:[e-mail]>[e-mail]><mailto:[e-mail]>[e-mail]><mailto:<mailto:[e-mail]>[e-mail]><mailto:[e-mail]>[e-mail]> 
>>> wrote:
>>>
>>>      On Jan 6, 2018, at 6:55 PM, Eric Rescorla 
>>> <<mailto:<mailto:<mailto:<mailto:[e-mail]>[e-mail]><mailto:[e-mail]>[e-mail]><mailto:<mailto:[e-mail]>[e-mail]><mailto:[e-mail]>[e-mail]><mailto:<mailto:<mailto:[e-mail]>[e-mail]><mailto:[e-mail]>[e-mail]><mailto:<mailto:[e-mail]>[e-mail]><mailto:[e-mail]>[e-mail]> 
>>> 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:[e-mail]>[e-mail]
>>>
>>> <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:[e-mail]>[e-mail]
>>>
>>> <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:[e-mail]>[e-mail]
>>>
>>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim 
>>>
>>>
>>
>>  --
>>  -----------------------------------------
>>  Gunnar Hellström
>>  Omnitor
>>  <mailto:[e-mail]>[e-mail]
>>  [phone]
>>
>>  _______________________________________________
>>  SLIM mailing list
>>  [e-mail]
>>  https://www.ietf.org/mailman/listinfo/slim
>
>

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[e-mail]
[phone]