Re: [media-types] Templates for basic MIME types

Ned Freed <ned.freed@mrochek.com> Tue, 05 January 2021 13:29 UTC

Return-Path: <ned.freed@mrochek.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 6178E3A0EB3 for <media-types@ietfa.amsl.com>; Tue, 5 Jan 2021 05:29:08 -0800 (PST)
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=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 BuwzZ5BemN50 for <media-types@ietfa.amsl.com>; Tue, 5 Jan 2021 05:29:07 -0800 (PST)
Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (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 4767A3A0EAD for <media-types@ietf.org>; Tue, 5 Jan 2021 05:29:06 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTZ895LTEO00EF5Z@mauve.mrochek.com> for media-types@ietf.org; Mon, 4 Jan 2021 10:58:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1609786724; bh=cpryfsO/xRby9MDBXmx/Ycl1jFhSdkOF0QAgCVHBQSk=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=AMHNIYOd4pTJJCQW6mpTd1aqy/8x58XBfZbfJQqGUJlS8dbK51xz0wVM3l13OlbF2 b6z6pmOERp6gmH7udKhu7jvu15ZcWJjkRP0y0GdwdDPgmutBmyQydWxI5VHteVWFUy OZIt9hBVPvBWORNiPE67F1qSIlkd6nzAUqi63Lb4=
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; CHARSET="US-ASCII"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTUUND7D1S004QVR@mauve.mrochek.com>; Mon, 4 Jan 2021 10:58:41 -0800 (PST)
Cc: Mark Nottingham <mnot@mnot.net>, media-types@ietf.org, Chris Lilley <chris@w3.org>, Eric Prud'hommeaux <eric@w3.org>
Message-id: <01RTZ893PI0A004QVR@mauve.mrochek.com>
Date: Mon, 04 Jan 2021 10:37:18 -0800
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Mon, 04 Jan 2021 09:51:40 -0800" <CAL0qLwadaoZPvXYS-USfH_q3d7xWOgPZFYpYOdP-D4kBj7RvxQ@mail.gmail.com>
References: <CAL0qLwYbJXKzYEvYWH9ijXpH27eRqgZU78ThLd81cCecJ_E0Wg@mail.gmail.com> <544915d5-37a9-cc73-065c-bd1e694dfee2@w3.org> <20201225161703.GB34854@w3.org> <E4131F62-74B2-4368-B41D-840C3CA5D77D@mnot.net> <CAL0qLwadaoZPvXYS-USfH_q3d7xWOgPZFYpYOdP-D4kBj7RvxQ@mail.gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/media-types/dcG8ax6KPy_mEY1aEfU7GbnOauY>
Subject: Re: [media-types] Templates for basic MIME types
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: Tue, 05 Jan 2021 13:29:08 -0000

> On Fri, Dec 25, 2020 at 7:03 PM Mark Nottingham <mnot@mnot.net> wrote:

> > My understanding has always been that the registration template is a
> > transient artefact, and is not required to be published. Why is there a
> > need for this?
> >

> IANA approached me to point out these various templates for key media types
> are absent from the registry.  I took their request to be identifying a
> problem that needed to be fixed, but maybe I misunderstood their intent.
> I'll get clarification.

IANA is mistaken in their understanding of what's formally required for
registration of a media type. There is no, repeat NO, requirement that there be
a template.

Templates are a convenient way of gathering and structuring registration
information, nothing more.

If you disagree feel free to point out the text that says a template is
required in RFC 6838.

The fact that IANA currently only accepts registrations in template form -
either via a web form or a template in an IETF document - is a processing
choice, one they are entitled to make. (It is also one that a fair number of
people find to be a significant PITA, but that's another matter.)

What IANA is not allowed to do is impose requirements retroactively on media
types that were registered without templates - indeed, we're talking here about
media types that were registered before the template even existed.

In case you haven't guessed by now, I have a really big problem with
retroactive imposition of requirements. Just as one exmaple amony many, are we
now going to review all the media types that don't have fragment identifier
sections and demand the people who registered them before that section even
existed figure out what to put there? I don't think so.

I will again point out that there are lots of real problems with the
media type registry - the obvious one being that there are many many many
unregistered types in wide use. If you want to do something that's actually,
you know, productive, there's plenty of work to do there.

Finally, as for the types registered in the MIME documents, since those
documents are soon to be revised, and that revision will necessarily mean
adding templates for the types they contain in order to meet current IANA
requirements, which will in turn obsolete any work done to create templates for
those types, what's being proposed here is not only unnecessary, but a waste of
time.

				Ned