Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
Randy Presuhn <randy_presuhn@alumni.stanford.edu> Wed, 15 February 2017 00:21 UTC
Return-Path: <randy_presuhn@alumni.stanford.edu>
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 CD47A12953B for <ietf@ietfa.amsl.com>; Tue, 14 Feb 2017 16:21:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.421
X-Spam-Level:
X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 y5OIrR1cdWM2 for <ietf@ietfa.amsl.com>; Tue, 14 Feb 2017 16:21:36 -0800 (PST)
Received: from mail-it0-f48.google.com (mail-it0-f48.google.com [209.85.214.48]) (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 DCB6812946E for <ietf@ietf.org>; Tue, 14 Feb 2017 16:21:35 -0800 (PST)
Received: by mail-it0-f48.google.com with SMTP id x75so54664092itb.0 for <ietf@ietf.org>; Tue, 14 Feb 2017 16:21:35 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=sK/tpB20jxzOLqJ60lPzTXfGAxvLfj8oyttxQYZakos=; b=CImgZpVJXJ73N+zs7ipgHMoE2cYR2l6vJVHlto6oCpwHyejQTCV4Vb4n0mXjHTsuxu untbJk377og16kbQTTf4kO+Tahu63HQxRX+YePwHx+rqLT4kq0cuygB0MfhlqQJI0OlA 7feQeF2wUwh4lNBvqSGtz8NQoGqnH033MOyNFrOFfsl0uH1ky0BKcQv2b4s5oMoX1056 ihcc/YHVJleaUVbcD1bNA7trY0eNaPwskeU5tAb0xQ6tghE4iLKV7Bil9VBw008pCm5Z dX6tBrl16P2t0FkPIyE092ySrNH66VEcrTwe5sywNLDtlp1zAWM2ZkROB3+4XcWu5rkd Bk0w==
X-Gm-Message-State: AMke39mwxAj8x92h5RRWTJPsVfYocXHyF+GhuJdNdFSXCLjaLooHQ4BqH4iZoqPH8EcuJKl0
X-Received: by 10.84.236.9 with SMTP id q9mr35996783plk.96.1487118095087; Tue, 14 Feb 2017 16:21:35 -0800 (PST)
Received: from [192.168.1.114] (c-50-143-178-150.hsd1.ca.comcast.net. [50.143.178.150]) by smtp.gmail.com with ESMTPSA id g85sm3329042pfe.38.2017.02.14.16.21.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 16:21:34 -0800 (PST)
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
To: ietf@ietf.org, "slim@ietf.org" <slim@ietf.org>
References: <20170213161000.665a7a7059d7ee80bb4d670165c8327d.917539e857.wbe@email0 3.godaddy.com> <ddc5af1d-f084-f57e-d6c9-5963e4fe98d3@omnitor.se> <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se> <p06240603d4c8f105055e@[99.111.97.136]> <434a4f06-f034-46ca-9df7-f59059e67e41@alumni.stanford.edu> <843f0cc1-2686-162d-25dc-0075847579bc@omnitor.se> <p06240609d4c937dc9ff8@[99.111.97.136]>
From: Randy Presuhn <randy_presuhn@alumni.stanford.edu>
Message-ID: <84760193-19e6-1f53-43cc-32b0493a1844@alumni.stanford.edu>
Date: Tue, 14 Feb 2017 16:21:35 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <p06240609d4c937dc9ff8@[99.111.97.136]>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/s31306oSwQnwWCLKepJOdMqTgxY>
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: Wed, 15 Feb 2017 00:21:37 -0000
Hi - On 2/14/2017 2:43 PM, Randall Gellens wrote: > At 8:59 PM +0100 2/14/17, Gunnar Hellström wrote: > >> Den 2017-02-14 kl. 19:05, skrev Randy Presuhn: >> >>> Hi - >>> >>> On 2/14/2017 9:40 AM, Randall Gellens wrote: >>>> At 11:01 AM +0100 2/14/17, Gunnar Hellström wrote: >>>> >>>>> My proposal for a reworded section 5.4 is: >>>>> >>>>> 5.4. Unusual language indications >>>>> >>>>> It is possible to specify an unusual indication where the language >>>>> specified may look unexpected for the media type. >>>>> >>>>> For such cases the following guidance SHALL be applied for the >>>>> humintlang attributes used in these situations. >>>>> >>>>> 1. A view of a speaking person in the video stream SHALL, when it >>>>> has relevance for speech perception, be indicated by a Language-Tag >>>>> for spoken/written language with the "Zxxx" script subtag to indicate >>>>> that the contents is not written. >>>>> >>>>> 2. Text captions included in the video stream SHALL be indicated >>>>> by a Language-Tag for spoken/written language. >>>>> >>>>> 3. Any approximate representation of sign language or >>>>> fingerspelling in the text media stream SHALL be indicated by a >>>>> Language-Tag for a sign language in text media. >>>>> >>>>> 4. When sign language related audio from a person using sign >>>>> language is of importance for language communication, this SHALL be >>>>> indicated by a Language-Tag for a sign language in audio media. >>>> >>>> [RG] As I said, I think we should avoid specifying this until we have >>>> deployment experience. >>> ... >>> >>> From a process perspective, it's far easier to remove constraints >>> as a specification advances than it is to add them. >> I agree. It is often better to specify normatively as far as you can >> imagine, so that interoperability and good functionality is achieved. >> Stopping halfway and have MAY in the specifications creates >> uncertainty and less useful specifications. > > My reading of what Randy says is the opposite of Gunnar's. In my > reading, Randy points out that is it easier to remove the SHOULD NOT in > the future then it is to change the meaning of the combinations or > switch to a different mechanism. > > In my experience, it's better to specify only what we know we need and > what we know we understand. Speculative specifications "as far as you > can imagine" more often lead to interoperability problems, unnecessary > complexity, limitations on what's needed in the future, and divergent > implementations. I think the difference in your positions comes down to (1) your respective notions of "what we know we need and what we know we understand"; (2) whether you believe that the interoperability and conformance consequences of removing a "SHOULD NOT" could be the same as those merely retaining a "MUST" or "SHALL" - this determines whether Randy G.'s proposal provides a path for some future revision to mandate (if deployment experience substantiates the need/understanding) the behavior proposed by Gunnar. That path is not at all obvious to me. Randy
- Re: IETF last call for draft-ietf-slim-negotiatin… Bernard Aboba
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Gunnar Hellström
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Bernard Aboba
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Gunnar Hellström
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randall Gellens
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Gunnar Hellström
- RE: [Slim] IETF last call for draft-ietf-slim-neg… Doug Ewell
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randall Gellens
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Gunnar Hellström
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Gunnar Hellström
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randall Gellens
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randy Presuhn
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Gunnar Hellström
- RE: [Slim] IETF last call for draft-ietf-slim-neg… Phillips, Addison
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randall Gellens
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randall Gellens
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randall Gellens
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randy Presuhn
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randall Gellens
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Gunnar Hellström
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Gunnar Hellström
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Gunnar Hellström
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Gunnar Hellström
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randall Gellens
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randall Gellens
- RE: [Slim] IETF last call for draft-ietf-slim-neg… Phillips, Addison
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Gunnar Hellström
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randall Gellens
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Bernard Aboba
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randall Gellens
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Gunnar Hellström
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randall Gellens