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

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

Den 2018-01-07 kl. 15:36, skrev Eric Rescorla:
>
>
> On Sat, Jan 6, 2018 at 7:31 PM, Bernard Aboba <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     On Jan 6, 2018, at 6:55 PM, Eric Rescorla <[e-mail]
>     <mailto:[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.
>
> 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.
<GH> Good discussion. However, I wonder what problem you see with early 
media? The offering party is supposed to express both which media and 
which languages are supported for both sending and receiving.

The answering party then has all needed information to start sending a 
matching language in a matching media as early media. The offering party 
will not see any explicit information about what language and media is 
used, but hopefully one (or more ) media and language(s) from the 
hlang-recv attributes will be sent, so that the contents will be 
perceived and understood.

Then, the answer is needed with both accepted media and the indications 
about which language and media the answering part prefers for receive. 
That will be conveyed in the answer and the enabled media and selected 
languages can be used both ways.

Your review ended a bit abruptly. Was there some intended sentence 
missing at the end? It ended:

" One reason you might is that you expect
the answer to resolve which language is in use, however because SIP
supports early media (i.e., media which is delivered prior to the
answer.)"


We have some similarities between the draft and RFC 4796 SDP Content 
Attribute.  The content attribute indicates only  what is intended to be 
SENT in the media, while we have indications separately for both 
directions. So, that is an existing example that it may be accepted to 
specify intentions for what to send.

I will check further where to add more explaining reasoning.

Thanks,

Gunnar

>
> -Ekr
>
>
>
>
> _______________________________________________
> SLIM mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/slim

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