Re: [media-types] WG: Still need an editor....

"Murray S. Kucherawy" <superuser@gmail.com> Thu, 03 March 2022 16:30 UTC

Return-Path: <superuser@gmail.com>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241F23A0E12 for <media-types@ietfa.amsl.com>; Thu, 3 Mar 2022 08:30:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 xK3fKqLrHiyn for <media-types@ietfa.amsl.com>; Thu, 3 Mar 2022 08:30:28 -0800 (PST)
Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 00D993A0E11 for <media-types@ietf.org>; Thu, 3 Mar 2022 08:30:27 -0800 (PST)
Received: by mail-vs1-xe2c.google.com with SMTP id d64so494820vsd.12 for <media-types@ietf.org>; Thu, 03 Mar 2022 08:30:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OhQfsgBfckk3A8s9EEsAVt0H1WcDAFe0xfPBH4yIM/Q=; b=mCVvwQylv7raeNLaHck1jn0bKjVBaS/Xql9RlOys2xMnXLsO14vdADUjYq7QZdSZh+ VwDIC9MP35l5/w2CBff5tkijRllUR1BfSNqUpvpgm8jKxnfo2jgp7uZo/n0WzCkuTly7 7Iva5hN7aSjxZZOfrXyR02jHGSSoRISvn2+0K1mimtcAj6Id7QcuPzqcQVWktvQU3jvt Q+ExaQNLb9NH6NVijzmSbgFNduSHKov8UXB6pLjs2ro6u5GnusdBk4G3Vyj53nPcAIi6 eLxnWH8CfyIDwPRbLHnZ9AOyJgNJl/oUjOld1uRhU1WMKZSYN2tEBnM4vlkA1rI+tfde z8HA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OhQfsgBfckk3A8s9EEsAVt0H1WcDAFe0xfPBH4yIM/Q=; b=2JScEi2yAkh85btwZ2YJ6By8ixo6aL0OmxD6vikbSCK2fhT8ovAZUP0WgEJdYd/Gn9 +EWpYUMHfNZzNipCu2nqHjYt35i4axW0/slVvs47lssII+RVfwKyg9FDvkRH9K9bC0cb fa18yKgj60ynSvMBdxxbuDh41Ea5l98M9tkh1EIR6lH9NKvA3yt3Ugn0K0VORQNjWaHF J1teCdJuQIJqPrTt88FSjijiCKIPGjSKrku4qAQ60DSaLEgT0+qHmvMh8OhNo19ope09 4peSAbxHg2fRMqV5VNxVxYxom+c08n+S0rHUlZrDDJGYXa2vW/vWU97L6WEN06CMrsl+ vxJQ==
X-Gm-Message-State: AOAM532ujRkaeGdRjZNavJsKR4MbBrwCcJZKXouyKwK8iM1aAdJLxi0E LmrB5tzhFI4QybMXeU+7eg0NXip1IZEeW8DlKnOEDGpj
X-Google-Smtp-Source: ABdhPJzj4jRQXFWe0EAHrqnWY+mCtvffWBgA1AmRPQxmJIkhgspDwyKmwURvrMAAxFlpeMZhm1ypgcrZNUxS/zf94jQ=
X-Received: by 2002:a67:c09d:0:b0:320:646b:9000 with SMTP id x29-20020a67c09d000000b00320646b9000mr1425354vsi.66.1646325026577; Thu, 03 Mar 2022 08:30:26 -0800 (PST)
MIME-Version: 1.0
References: <b9a47886-9fed-10cd-6f98-ba5c8d18ec0e@alvestrand.no> <SN4PR16MB4879003CF7E2FAE6F1736F2ADE339@SN4PR16MB4879.namprd16.prod.outlook.com> <5afced3e-2a09-afea-6cca-307f5b875b25@it.aoyama.ac.jp> <c835f248-9415-cb5a-e10d-cdfc6837e1b7@alvestrand.no> <3fe5c498-450f-0dbe-5021-16b7da04eca1@it.aoyama.ac.jp>
In-Reply-To: <3fe5c498-450f-0dbe-5021-16b7da04eca1@it.aoyama.ac.jp>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Thu, 03 Mar 2022 08:30:15 -0800
Message-ID: <CAL0qLwY=7VNfOviSOfW3sGP3-Gv4yRTLfHuMFXRYRMAKk+bnWA@mail.gmail.com>
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
Cc: Harald Alvestrand <harald@alvestrand.no>, "media-types@ietf.org" <media-types@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000064e1c805d952eae1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/media-types/bU0ISRNQHOfp0j4VxbbUQ-bo7aM>
Subject: Re: [media-types] WG: Still need an editor....
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Mar 2022 16:30:35 -0000

On Wed, Feb 23, 2022 at 6:20 PM Martin J. Dürst <duerst@it.aoyama.ac.jp>
wrote:

> I have started working on such a draft, mostly on getting up to speed
> with the newest version of xml2rfc and related tooling.
>
> When I started looking for status, update relationships, and references
> that I might have to include, I found
> https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.7, which says:
>
> 4.2.7.  Additional Top-Level Types
>
>     In some cases, a new media type may not "fit" under any currently
>     defined top-level type names.  Such cases are expected to be quite
>     rare.  However, if such a case does arise, a new type name can be
>     defined to accommodate it.  Definition of a new top-level type name
>     MUST be done via a Standards Track RFC; no other mechanism can be
>     used to define additional type names.
>
> If you compare this text with what Harald and I wrote above and below,
> there's really not much (if indeed anything) that isn't already said.
>
> So before I continue working on this draft (which I can do this
> weekend), I really want to make sure that we need such a draft.
>

Hi Martin, thanks for taking this up.

RFC 6838 Sections 4.2.5 and 4.2.7 are mushy in that the former says we
should use "application" as the top-level type for anything that doesn't
clearly fit into some other top-level type, while the latter says you can
also make new top-level types in the rare case that it's necessary.  When
the "haptics" application appeared, the community had that discussion, and
it was noted that there's little guidance (only what you cited) about when
one should do one or the other.  The only other example is RFC 8081, where
a top-level type was indeed registered.

What I think we were hoping for is an update to RFC 6838 that provides some
consensus guidance about (a) when it's appropriate to make a new top-level
type versus using "application" (and/or maybe some examples of when doing
so is not appropriate); and (b) what a document declaring a new top-level
type should be required to contain.  It's fine to use RFC 8081 as a model
if people think that worked out well, or well enough to serve as a basis
for something going forward.

-MSK