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
- [dispatch] Murray Kucherawy's No Objection on dra… Murray Kucherawy via Datatracker
- Re: [dispatch] Murray Kucherawy's No Objection on… Mathias Bynens
- Re: [dispatch] Murray Kucherawy's No Objection on… Murray S. Kucherawy
- Re: [dispatch] Murray Kucherawy's No Objection on… John C Klensin
- Re: [dispatch] Murray Kucherawy's No Objection on… Mathias Bynens
- Re: [dispatch] Murray Kucherawy's No Objection on… Murray S. Kucherawy
- Re: [dispatch] Murray Kucherawy's No Objection on… Mathias Bynens
- Re: [dispatch] Murray Kucherawy's No Objection on… Murray S. Kucherawy
- Re: [dispatch] Murray Kucherawy's No Objection on… ned+dispatch
- Re: [dispatch] Murray Kucherawy's No Objection on… John C Klensin
- Re: [dispatch] Murray Kucherawy's No Objection on… Mathias Bynens
- Re: [dispatch] Murray Kucherawy's No Objection on… Mathias Bynens
- Re: [dispatch] Murray Kucherawy's No Objection on… Mathias Bynens
- Re: [dispatch] Murray Kucherawy's No Objection on… John C Klensin