Re: IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)

Bernard Aboba <bernard.aboba@gmail.com> Mon, 13 February 2017 19:07 UTC

Return-Path: <bernard.aboba@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7C71296EE; Mon, 13 Feb 2017 11:07:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lD0fWYeyPSNu; Mon, 13 Feb 2017 11:07:21 -0800 (PST)
Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 055881297F0; Mon, 13 Feb 2017 11:07:19 -0800 (PST)
Received: by mail-vk0-x231.google.com with SMTP id r136so66896567vke.1; Mon, 13 Feb 2017 11:07:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=NDew0FUK8ElkqHlOhFFJAoOgzkDKBO5BiBkfzY1cYYU=; b=QwyqV12/Om7EB+mBGX0WgX78zxA9vPhc901aewOeBrCiW8lOYYkzXzQMRvBDQuNbvN pBAqzJ4FyOxtFSt7H39+mclF177fA/qeh4jkYL52tykux03EREbJMu3aSk76Uc2hBq2d DVyJm45wYey6YzMcrmDlSboXScS5R091/TRwz5mq1B2nbwKlHO0bKzvfu+FyB4k/g5O3 +/usNpFGqS1EHH5VA1rKtjoArWphmh8QW49ztM53xsHr4kYdUz9yg+vGQ0exuZTv9fiL VHvNMqoRNVmOhvkREtktBu+uknuBgY7XB9RnYBXanKFKRWVkmyzJH3jhGGPp0tNcRa/W YqMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NDew0FUK8ElkqHlOhFFJAoOgzkDKBO5BiBkfzY1cYYU=; b=n14XZLifLmaj43fg5OzZuv5vQ/Jy7/9ej5RZ+N2ly2hMehNJhjHscwee5ekak4vbnc pr6uQc5/bt44NlR6KLzPIRBk4ycdUfMVYi1J3tTEDFDZPMvOPQBFD6vr6gCm7Xw5LiN9 SxZvpZlouFTQhPX7WIzTHxb4oKJDu0PiUIJql8min+8AHWX/tLUxcP88Z4fLyMteuO3Q uSK6L4dnoKfNlXXNTLhzVnyoe1BSsIi1yOEJq3CBJkA3J/uujg2rFE8ubf+tMgWUGzKg mmXyNO9FSDV4jSoAwQvN7qQXnscY99rdUlnZCSFD/JF1hf7FSNoSJA4BMPJ51LyAdWUs CWSA==
X-Gm-Message-State: AMke39kk6wnT5cZ2fmD3xTJfruyj362JL7zHgPuAHR1Q6mPfQNPDGj6gjbSkQNkap5EaP5QB9SRYuO5+OPO+eA==
X-Received: by 10.31.191.71 with SMTP id p68mr9926607vkf.50.1487012837822; Mon, 13 Feb 2017 11:07:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.88.90 with HTTP; Mon, 13 Feb 2017 11:06:57 -0800 (PST)
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Mon, 13 Feb 2017 11:06:57 -0800
Message-ID: <CAOW+2du3zqYfS9iu4XjrQ6Rr6B5C50OXk49=u7Wrg0-1TE7QzA@mail.gmail.com>
Subject: Re: IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
To: slim@ietf.org, ietf@ietf.org
Content-Type: multipart/alternative; boundary="001a114ddaf8f9996105486e27b7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/XgN1GbiDzPLTApg4ZDC1CRkKQyA>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Feb 2017 19:07:23 -0000

Looking over Section 5.4, it seems to me that the title "Silly States" may
not be appropriate, because it mixes discussion of combinations of media
and language that have an "undefined" meaning with combinations for which
normative guidance can be provided  So rather than having a single "Silly
States" section, perhaps we can have a section on "Undefined States" (for
those combinations which have an undefined meaning) provide normative
guidance on defined combinations elsewhere.

5.4 <https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-06#section-5.4>.
Silly States

   It is possible to specify a "silly state" where the language
   specified does not make sense for the media type, such as specifying
   a signed language for an audio media stream.

   An offer MUST NOT be created where the language does not make sense
   for the media type.  If such an offer is received, the receiver MAY
   reject the media, ignore the language specified, or attempt to
   interpret the intent (e.g., if American Sign Language is specified
   for an audio media stream, this might be interpreted as a desire to
   use spoken English).

   A spoken language tag for a video stream in conjunction with an audio
   stream with the same language might indicate a request for
   supplemental video to see the speaker.


[BA] Rather than using terms like "might" for combinations that could have a

defined meaning, I would like to see the specification provide normative

language on these use cases. In particular, I would like the
specification to describe:


a. What it means when a spoken language tag is included for a video stream.

Is this to be interpreted as a request for captioning?

b. What it means when a signed language tag is included for an audio stream.

Is the meaning of this "undefined" and if so, should it be ignored?

c. What it means when a signed language tag is included for a text stream.


If some of these scenarios are not defined, the specification can say

"this combination does not have a defined meaning" or something like that.