Content-Type: multipart/alternative;
 boundary=Apple-Mail-A2DEA06B-B248-4C82-BE27-A8DCA1E847E0
Mime-Version: 1.0 (1.0)
From: Bernard Aboba <bernard.aboba@gmail.com>
In-Reply-To: <CABcZeBNQLuaMLa3=gWqaYHL_ynQ1t+HRtsgEebCRORm+OUA0iw@mail.gmail.com>
Date: Sat, 6 Jan 2018 19:31:49 -0800
Cc: Bernard Aboba <bernard_aboba@hotmail.com>, "slim@ietf.org" <slim@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <ECD0168D-9C53-4ACA-BF28-C631DAE38A4D@gmail.com>
References: <151528917109.10947.12045320996364596931.idtracker@ietfa.amsl.com>
 <CO2PR10MB0101A52C512BACCBEE0CF75593120@CO2PR10MB0101.namprd10.prod.outlook.com>
 <CABcZeBNQLuaMLa3=gWqaYHL_ynQ1t+HRtsgEebCRORm+OUA0iw@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/_9b6STg48aFTJotQls03hxy-aiw>
Subject: Re: [Slim] Eric Rescorla's No Objection on
 draft-ietf-slim-negotiating-human-language-19: (with COMMENT)
Precedence: list


--Apple-Mail-A2DEA06B-B248-4C82-BE27-A8DCA1E847E0
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Jan 6, 2018, at 6:55 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>> For disabled users, the capabilities may not be symmetric.=20
>=20
> But this is true for ordinary SDP as well. I might be able to receive H.26=
4 but not send it.

[BA] Thanks. The draft should explain the reasoning. IMHO the argument goes s=
onething like this:

A pure recv/recv negotiation will not necessarily disclose beforehand what s=
pecial services are needed for the call - services (e.g. ASL interpretation o=
r RTT handling) that could take time to acquire.=20

Since the actual video media sent is not labelled as ASL even if the answere=
r has ASL interpreters it can pull in and therefore advertises in SDP ASL re=
ception capability in video, a recv/recv negotiation doesn=E2=80=99t tell th=
e Answerer that the Offerer will need them, so the Answerer may need to (fra=
ntically) arrange for ASL interpretation after initial receipt of media. In a=
n emergency, that can chew up valuable time.



--Apple-Mail-A2DEA06B-B248-4C82-BE27-A8DCA1E847E0
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div></div><div>On Jan 6, 2018, at 6:55 PM,=
 Eric Rescorla &lt;<a href=3D"mailto:ekr@rtfm.com">ekr@rtfm.com</a>&gt; wrot=
e:</div><div><br></div><blockquote type=3D"cite"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Fo=
r disabled users, the capabilities may not be symmetric.&nbsp;</blockquote><=
div><br></div><div>But this is true for ordinary SDP as well. I might be abl=
e to receive H.264 but not send it.</div></div></div></div></blockquote><br>=
<div>[BA] Thanks. The draft should explain the reasoning. IMHO the argument g=
oes sonething like this:</div><div><br></div><div>A pure recv/recv negotiati=
on will not necessarily disclose beforehand what special services are needed=
 for the call - services (e.g. ASL interpretation or RTT handling) that coul=
d take time to acquire.&nbsp;</div><div><br></div><div>Since the actual vide=
o media sent is not labelled as ASL even if the answerer has ASL interpreter=
s it can pull in and therefore advertises in SDP ASL reception capability in=
 video, a recv/recv negotiation doesn=E2=80=99t tell the Answerer that the O=
fferer will need them, so the Answerer may need to (frantically) arrange for=
 ASL interpretation after initial receipt of media. In an emergency, that ca=
n chew up valuable time.</div><div><br></div><div><br></div></body></html>=

--Apple-Mail-A2DEA06B-B248-4C82-BE27-A8DCA1E847E0--