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

John C Klensin <john-ietf@jck.com> Sun, 09 January 2022 02:00 UTC

Return-Path: <john-ietf@jck.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 F35623A1490; Sat, 8 Jan 2022 18:00:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham 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 eh5MQakY9mFp; Sat, 8 Jan 2022 18:00:43 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7370E3A148F; Sat, 8 Jan 2022 18:00:42 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1n6NVe-000IsA-QS; Sat, 08 Jan 2022 21:00:38 -0500
Date: Sat, 08 Jan 2022 21:00:31 -0500
From: John C Klensin <john-ietf@jck.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>, Mathias Bynens <mths@google.com>
cc: 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: <22997B1E50714D0AE9F59239@PSB>
In-Reply-To: <CAL0qLwYgc13KXriZNPcB-XqC7i_ORDw01C5h2x93U22R3VCnSg@mail.gmail.com>
References: <164144481153.28700.9521326921012553920@ietfa.amsl.com> <CADizRgYZhzFrNsoFP0M845zK9DgGi5Ci6pgVGVfcNzPkT31JyQ@mail.gmail.c om> <CAL0qLwYgc13KXriZNPcB-XqC7i_ORDw01C5h2x93U22R3VCnSg@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/TY6PFmINOsllt-bm1zMfRv70uBU>
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: Sun, 09 Jan 2022 02:00:45 -0000


--On Saturday, January 8, 2022 17:37 -0800 "Murray S. Kucherawy"
<superuser@gmail.com> wrote:

>>> This document is registering media subtypes starting with
>>> "x-" even though BCP
>>> 178 says not to do that.  If the working group intends to do
>>> this for historical reasons, I suggest including a sentence
>>> explaining that this is being done intentionally, perhaps
>>> under Appendix A of RFC 6838.  (See, for example, Section 6
>>> of RFC 8894.)
>>> 
>> 
>> This is not new content / a new registration, but rather
>> content inherited from RFC4329, which our draft iaims to
>> supersede. The draft already explains that it updates
>> RFC4329. Is that sufficient?
>> 
> 
> 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.

Mathias,

Let me say that a little more strongly.  BCP 178, which probably
should have been written a decade earlier (in retrospect, we
probably should have prohibited them in RFC 4288/BCP 13),
reflects many years of experience, pain, and suffering.  If you
want to make a new registration now that uses one of those "X-"
prefixes, you need to explain why they should be an exception --
not only in terms of why BCP 178 is not applicable (as Murray
suggests) but even why it is not possible to change the media
types now and going forward to ones without the "X-".

Murray, consider this early warning of an appeal is this
document is approved without that text appearing in some
reasonable form.

best,
  john