[Slim] Ben Campbell's Yes on draft-ietf-slim-negotiating-human-language-22: (with COMMENT)

Ben Campbell <ben@nostrum.com> Wed, 10 January 2018 04:21 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: slim@ietf.org
Delivered-To: slim@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 426AC1200B9; Tue, 9 Jan 2018 20:21:21 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ben Campbell <ben@nostrum.com>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-slim-negotiating-human-language@ietf.org, slim-chairs@ietf.org, bernard.aboba@gmail.com, slim@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.68.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151555808122.21584.8379796998643581181.idtracker@ietfa.amsl.com>
Date: Tue, 09 Jan 2018 20:21:21 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/0XcqqdSI-FoRrLKehESsBogM4wQ>
Subject: [Slim] Ben Campbell's Yes on draft-ietf-slim-negotiating-human-language-22: (with COMMENT)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Selection of Language for Internet Media <slim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/slim>, <mailto:slim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/slim/>
List-Post: <mailto:slim@ietf.org>
List-Help: <mailto:slim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/slim>, <mailto:slim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jan 2018 04:21:21 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-slim-negotiating-human-language-22: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


I'm balloting "yes" because I think this is important work, but I have some

Substantive Comments:

- General: It seems to be that this is as much about human behavior as it is
capabilities negotiating. Example case: I make a video call and express that I
would like to receive Klingon. (Is there a tag for that ? :-) The callee can
speak Klingon and Esperanto, so we agree on Klingon. What keeps the callee from
speaking Esparanto instead?

I realize we can't force people to stick to the negotiated languages--but
should we expect that users should at least be given some sort of UI indication
about the negotiated language(s)? It seems like a paragraph or two on that
subject is warranted, even if it just to say it's out of scope.

-1, paragraph 6:  (related to Ekr's comments) Does the selection of a single
tag in an answer imply  an assumption only one language will be used? There are
communities where people tend to mix 2 or more languages freely and fluidly. Is
that sort of thing out of scope?

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

-5.1, paragraph 3: "... which in most cases is one of the
   languages in the offer's..."
Are there cases where it might not?

-5.1, last paragraph: "This is not a problem."
Can you elaborate? That sort of statement usually takes the form "This is not a
problem, because..."

-5.2, last paragraph: Is there a reason to give such weak guidance on how to
indicate the call is rejected?  (Along those lines, are non-SIP uses of SDP in

Editorial Comments and Nits:

-5.1, paragraph 4: The first MUST seems like a statement of fact.