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

[Eric Rescorla <[e-mail]>]

WFM. thanks

-Ekr


On Mon, Jan 8, 2018 at 10:10 AM, Randall Gellens <[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:
>>> [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:
>>> [e-mail]>[e-mail]><mailto:rg%2Bietf@
>>> randy.pensive.org>[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:[e-mail]>[e-mail]><mailto:bernard.
>>> [e-mail]>[e-mail]><mailto:<mailto:bern
>>> [e-mail]>[e-mail]><mailto:bernar
>>> [e-mail]>[e-mail]> wrote:
>>>
>>>     On Jan 6, 2018, at 6:55 PM, Eric Rescorla <<mailto:<mailto:<mailto:
>>> [e-mail]>[e-mail]><mailto:[e-mail]>[e-mail]><mail
>>> to:<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
>    answer contains one language per media 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 answerer indicates in the answer which additional
>    steps it is committing to.  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
>>>   [e-mail]
>>>   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
>>  [e-mail]
>>  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.
>