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

[Bernard Aboba <[e-mail]>]

EKR said:

"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."

[BA] It seems like a relevant question, particularly for a case where a
call back might occur, so that the roles of Offerer and Answerer are
reversed.

On Sun, Jan 7, 2018 at 5:56 PM, Eric Rescorla <[e-mail]> wrote:

>
>
> On Sun, Jan 7, 2018 at 5:22 PM, Randall Gellens <[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:
>>> [e-mail]>[e-mail]> wrote:
>>>
>>>  On Jan 6, 2018, at 6:55 PM, Eric Rescorla <<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.
>
>
>
>>  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.
>
> -Ekr
>
>
>>
>> --
>> Randall Gellens
>> Opinions are personal;    facts are suspect;    I speak for myself only
>> -------------- Randomly selected tag: ---------------
>> (If you can't hear me, it's because I'm in parentheses)
>>
>
>