Re: [dispatch] Murray Kucherawy's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT)

ned+dispatch@mrochek.com Tue, 11 January 2022 22:32 UTC

Return-Path: <ned+dispatch@mrochek.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7522D3A12BE for <dispatch@ietfa.amsl.com>; Tue, 11 Jan 2022 14:32:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.556
X-Spam-Level:
X-Spam-Status: No, score=-0.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.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 8r6XK6MJZZxC for <dispatch@ietfa.amsl.com>; Tue, 11 Jan 2022 14:32:24 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (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 D693A3A12BB for <dispatch@ietf.org>; Tue, 11 Jan 2022 14:32:23 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S8F3X80CQ800IH94@mauve.mrochek.com> for dispatch@ietf.org; Tue, 11 Jan 2022 14:27:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1641940039; bh=/pwAi/09Oi0/nW+TsJt+ZzvhFafr57hmwsuZpD6xPd0=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=acUiC4iruYVIUJ0apsFCsx8Zs/DNoppPWg1XyaDa6by9f2vbF11YOsfaIoGnlSjI3 EHph1Ad6E+kVyrmwfunxtXOO2z7AIOkPVEzykqA9HMoirwUMvLfLWYtub4s8fN8EVr reJYB63iwdo6U8rA9vdt2n8R5bCau+l+XvvyG0E8=
MIME-version: 1.0
Content-transfer-encoding: 8bit
Content-type: TEXT/PLAIN; charset="UTF-8"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S8CCV4AC8W00D1OX@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dispatch@ietf.org; Tue, 11 Jan 2022 14:27:12 -0800 (PST)
From: ned+dispatch@mrochek.com
Cc: "Murray S. Kucherawy" <superuser@gmail.com>, DISPATCH WG <dispatch@ietf.org>, Ben Campbell <ben@nostrum.com>, dispatch chairs <dispatch-chairs@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-dispatch-javascript-mjs@ietf.org
Message-id: <01S8F3X371ZE00D1OX@mauve.mrochek.com>
Date: Tue, 11 Jan 2022 07:53:18 -0800
In-reply-to: "Your message dated Mon, 10 Jan 2022 14:20:27 +0100" <CADizRgaN9BvLztmJ6Q+kjV8fJM_hhXkQxFSRX2mgaFsP1RaBCA@mail.gmail.com>
References: <164144481153.28700.9521326921012553920@ietfa.amsl.com> <CADizRgYZhzFrNsoFP0M845zK9DgGi5Ci6pgVGVfcNzPkT31JyQ@mail.gmail.com> <CAL0qLwYgc13KXriZNPcB-XqC7i_ORDw01C5h2x93U22R3VCnSg@mail.gmail.com> <CADizRgaN9BvLztmJ6Q+kjV8fJM_hhXkQxFSRX2mgaFsP1RaBCA@mail.gmail.com>
To: Mathias Bynens <mths=40google.com@dmarc.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/1Q5-Xl1I2bzMH4rCuRstaXUZwFs>
Subject: Re: [dispatch] Murray Kucherawy's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jan 2022 22:32:29 -0000

In regards to all these obsolete registrations and x- registrtions
in particular...

> > What I've observed is that the current media type registry does not at
> > present contain any of the "x-" media types this document is registering.
> > I believe that makes them new registrations, and so I suggest that there
> > should be text explaining why BCP 178 doesn't apply here.
> >

> Thank you. Please take a look at this patch:
> https://github.com/linuxwolf/bmeck-ids/pull/65/files

> For context, these are historical legacy types that are supported in
> practice: https://mathiasbynens.be/demo/javascript-mime-type Although they
> are OBSOLETED, it’s important that the document specifies them because they
> are required for Web compatibility.

There seems to be considerable misunderstanding about the rules regarding
obsolete type names, unfaceted types, and type names beginning with "X-".

First, RFC 6838 eliminated the special status of type names beginning with
"X-". So nothing prevents you from registering type names beginning with
"X-" as long as the registration is in the standards tree. Appendix A
of RFC 6838 only applies if the type is being registered in, say, the vendor
tree, which AFAICT is not the case here.

Of course the fact that you can register names beginning with "X-" doesn't
mean you should. So if you're doing this, a note explaining why ths makes
sense would be a good idea.

However, the better question is why are all these obsolete type names
being registered separately. RFC 6838 section 4.2.9 explains the proper
way to handle old names for the same media type, and the registration
form now contains a field for listing all of these names.

If you're going to register a bunch of separate types for a bunch of
similar things, you need to explain why you're doing things this way,
and more importantly, why they warrant having different names.

And since in this case all of these additional registrations are marked
as obsolete, I fail to see why they aren't being handle as deprecated aliases.
Or, to pur this another way, why not simply list all 15 (!) aliases in the
registration for text/javascript and get rid of section 6.2 entirely?

				Ned