To: slim@ietf.org
References: <151555808122.21584.8379796998643581181.idtracker@ietfa.amsl.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <76085ca0-3203-bf78-4d30-e90a16abc276@alum.mit.edu>
Date: Wed, 10 Jan 2018 11:15:03 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0)
 Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <151555808122.21584.8379796998643581181.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/TtfzdxEy9nW--Gi_hK8A1EBDFfc>
Subject: Re: [Slim] Ben Campbell's Yes on
 draft-ietf-slim-negotiating-human-language-22: (with COMMENT)
Precedence: list

On 1/9/18 11:21 PM, Ben Campbell wrote:

> - 5.1, paragraph 2:  Can you elaborate on the motivation to have a separate
> hlang-send and hlang-recv parameter vs having a single language parameter and
> instead setting the stream to send or receive only, especially in light of the
> recommendation to set both directions the same for bi-directional language
> selection? I don't mean to dispute that approach; I just think a bit more
> explanation of the design choice would be helpful to the reader.  I can imagine
> some use cases, for example a speech-impaired person who does not plan to speak
> on a video call may still wish to send video to show facial expressions, etc.
> (I just re-read the discussion resulting from Ekr's comments, and recognize
> that this overlaps heavily with that.)

There are cases where what you suggest won't work. E.g., Sign language 
is embedded in video, but it isn't the sole purpose of the video. If I 
can understand sign language but not do it myself, I wouldn't want to 
indicate that by refusing to send video.

	Thanks,
	Paul