Re: [I18ndir] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07

Patrik Fältström <patrik@frobbit.se> Sat, 09 May 2020 06:03 UTC

Return-Path: <patrik@frobbit.se>
X-Original-To: i18ndir@ietfa.amsl.com
Delivered-To: i18ndir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774C43A07D5; Fri, 8 May 2020 23:03:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=frobbit.se
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 6-SWlr4yUj9d; Fri, 8 May 2020 23:03:48 -0700 (PDT)
Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (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 4BA733A0474; Fri, 8 May 2020 23:03:48 -0700 (PDT)
Received: from [192.165.72.241] (unknown [IPv6:2a02:80:3ffc:0:4461:8a41:6460:34a1]) by mail.frobbit.se (Postfix) with ESMTPSA id E8AC3289F1; Sat, 9 May 2020 08:03:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=frobbit.se; s=mail; t=1589004226; bh=UadEYOakqs/oVDc5GwlYvkoxk1biKLtDN+SrtPFgGOU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=M8L3KVfuQLFNXXEBQNxtGpIICq3wG1oM2H/Mnoq6njxYL6S5cNX+HH6WJafAbHRQQ CuY8QM3279dJnxrgbSzFHATI1dB2g2KthjxjoJeAcjEu+zdJHvyfWT24MfPc7PXDkE EN1hsVyU39f3A9nuhGKfNJWUySZRcy0nNt96sWtQ=
From: Patrik Fältström <patrik@frobbit.se>
To: John R Levine <johnl@taugh.com>
Cc: Myles Borins <mylesborins@google.com>, Barry Leiba <barryleiba@computer.org>, DISPATCH WG <dispatch@ietf.org>, draft-ietf-dispatch-javascript-mjs.all@ietf.org, i18ndir@ietf.org
Date: Sat, 09 May 2020 08:03:43 +0200
X-Mailer: MailMate (1.13.1r5676)
Message-ID: <C6B94276-EB9F-4A5B-9E1B-0DE170A05EBC@frobbit.se>
In-Reply-To: <alpine.OSX.2.22.407.2005081926580.81728@ary.qy>
References: <158896904545.17044.5288882047334991439@ietfa.amsl.com> <CALaySJ+CRJumYtDCxvGsSwzanz4y=7icuqd+toc0wMivf-mJGg@mail.gmail.com> <CAD7Fb3diej1-3fAgqZsS_E9wOs1KC=OwVWbvxV5mVjOdQEQm5g@mail.gmail.com> <alpine.OSX.2.22.407.2005081926580.81728@ary.qy>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_40758AEF-C6E3-4F9F-9B01-DA18757DF618_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18ndir/_Uj7eQSb8PrkcbdrYORW-21-8J4>
Subject: Re: [I18ndir] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07
X-BeenThere: i18ndir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Internationalization Directorate <i18ndir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i18ndir/>
List-Post: <mailto:i18ndir@ietf.org>
List-Help: <mailto:i18ndir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 May 2020 06:03:55 -0000

On 9 May 2020, at 1:31, John R Levine wrote:

> I completely agree that for something like this which is widely implemented, the spec should describe what actually works.  But I was wondering if you could narrow down the range of what you describe so future implementors don't waste time worrying about screwups that aren't an issue in practice.

It is also the case that the IETF document can explain exactly this, that the use of filename extensions is discouraged (for a multitude of reasons), and still define a new MIME-type which is the recommended use case. Collaboration with W3C is of course essential.

> I'm sorry to hear that people are using filename extensions to tell what's in a file.  I'd hoped that all of the badness from old versions of Windows doing that might have been a hint.

This is something that just must go away, and I think a big note in non-friendly letters must be added in the security considerations section is needed that explain the situation and why the current practice is not really what we want in the wild.

I.e. yes, while still documenting "what works", that should not be the goal. It will lead to even more problems getting secure mechanisms in browsers deployed.

   Patrik