Re: [Slim] draft-hellstrom-slim-simultaneous-modalities & modalitypref

Paul Kyzivat <paul.kyzivat@comcast.net> Wed, 07 June 2017 19:43 UTC

Return-Path: <paul.kyzivat@comcast.net>
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CA112EBF9 for <slim@ietfa.amsl.com>; Wed, 7 Jun 2017 12:43:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 Jg7Ol7YhMmvn for <slim@ietfa.amsl.com>; Wed, 7 Jun 2017 12:43:25 -0700 (PDT)
Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA615129B40 for <slim@ietf.org>; Wed, 7 Jun 2017 12:43:24 -0700 (PDT)
Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-11v.sys.comcast.net with SMTP id IgqDdtYMIT4XXIgrUdTmTM; Wed, 07 Jun 2017 19:43:24 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1496864604; bh=XM+xHtxpBqcSAcy/fhzn/3ltHgUTAeGIwcqnwGhO7/k=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=BsmiYOpNPaNu7JH/qUzh9Y0LOzgJP5vsxot2K9vF0ykiYH5HyK3SGDk+w69j43S6E mY6sxOJQWC/Ff1KNK7xgdH9LWRmqquCmXs8w414OIzV+F2tNx1yB8EaJuqKNOkCxEW fePqXpKRwzCNvjCMzFeKqA3IXNsWrhJJvLjUvUOBpqF4RZho4lMMYDz/yyRxgMCZK0 ZW05+TQrr/x8gwknZ0p5oznthXLWyUQ/iLzM9ioMoyI27dqz/+8wSRhpuSH56grkFr f/M2232UcpBALpgQMkXAyKuf+CSfgmL9Bj7tR2TvR4UNnmGUgASBbuIJIcNyfnMWsu Hw6cGHmjNGZ9Q==
Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-04v.sys.comcast.net with SMTP id IgrTdyi83FcZ2IgrTddHVj; Wed, 07 Jun 2017 19:43:24 +0000
To: slim@ietf.org
References: <33a3da56-427b-5e86-f6f7-ea53a5d7a7ad@omnitor.se>
From: Paul Kyzivat <paul.kyzivat@comcast.net>
Message-ID: <9016202e-3c8d-4ed0-192c-a4f2c198771a@comcast.net>
Date: Wed, 07 Jun 2017 15:43:23 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <33a3da56-427b-5e86-f6f7-ea53a5d7a7ad@omnitor.se>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfMNHl1AcmzzWfIbvJ041sxUqp7XGsUtu+VkrBOgxXL48/Lc2EFg4VDioNmKMrmTVCi2OpUPC58V+4yCAAjkoiWy9Q93rniIRVmPQuCikZIK4gWp7dBY1 sRGFohBNf6UbvU1KTPZwROZb4PL1JlQwpfjBDIbHBlxUOOBo4FlZU6aQ
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/_HEPNTPNeT-LRA6s9ms4zd2NCPE>
Subject: Re: [Slim] draft-hellstrom-slim-simultaneous-modalities & modalitypref
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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, 07 Jun 2017 19:43:26 -0000

I did a quick review of these documents. My feeling is that these have 
moved to quickly to specific solution syntax without first sorting out 
exactly what the needs are. I am sympathetic to what I think the goals 
are, but am concerned that the proposed solutions are not ideal.

For instance, simultaneous-modalities indicates the languages of the 
source form and the transformed form. But it does not indicate precisely 
which media stream contains the source form. I guess the assumption is 
that there will only be one other media stream with the appropriate 
language indication. But that is just an assumption. It may well apply 
in a number of common cases, but I'm sure we can come up with more 
complex cases where that isn't true. ISTM that it would be better to 
come up with a syntax that explicitly links the source and transformed 
media streams. (E.g. a new usage of the grouping framework.)

In the modalitypref document if find the semantics fuzzy, and the 
relationship of the use of "*" for this to be even more fuzzy when 
related to its use in draft-ietf-slim-negotiating-human-language. For 
instance, I see a potential conflict between need to express degree of 
competence with a modality with preference for that modality. It may be 
that those should be handles as two distinct indicators. Further 
discussion is needed.

	Thanks,
	Paul