[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: https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm balloting "yes" because I think this is important work, but I have some comments: 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 scope?) Editorial Comments and Nits: -5.1, paragraph 4: The first MUST seems like a statement of fact.
- [Slim] Ben Campbell's Yes on draft-ietf-slim-nego… Ben Campbell
- Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-… Randall Gellens
- Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-… Paul Kyzivat
- Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-… Ben Campbell
- Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-… Ben Campbell
- Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-… Randall Gellens
- Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-… Gunnar Hellström
- Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-… Randall Gellens
- Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-… Bernard Aboba
- Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-… Bernard Aboba
- Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-… Gunnar Hellström
- Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-… Randall Gellens
- Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-… Bernard Aboba
- Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-… Gunnar Hellström
- [Slim] Text stating that negotiation isn't restri… Randall Gellens
- [Slim] Allowing multiple values in an answer Randall Gellens
- Re: [Slim] Allowing multiple values in an answer Randall Gellens
- Re: [Slim] Allowing multiple values in an answer Gunnar Hellström
- Re: [Slim] Allowing multiple values in an answer Bernard Aboba
- [Slim] Action or not on multiple values in an ans… Randall Gellens
- Re: [Slim] Allowing multiple values in an answer Bernard Aboba
- Re: [Slim] Allowing multiple values in an answer Randall Gellens