Re: [apps-discuss] A modest proposal for MIME types (and URI schemes)

Nico Williams <> Mon, 14 November 2011 19:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5FEC711E834F for <>; Mon, 14 Nov 2011 11:06:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.778
X-Spam-Status: No, score=-1.778 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BCVFxKB6zdms for <>; Mon, 14 Nov 2011 11:06:10 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D831E11E834C for <>; Mon, 14 Nov 2011 11:06:10 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id C35C8428075 for <>; Mon, 14 Nov 2011 11:06:09 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 9EAA0428072 for <>; Mon, 14 Nov 2011 11:06:09 -0800 (PST)
Received: by ggnr5 with SMTP id r5so1383202ggn.31 for <>; Mon, 14 Nov 2011 11:06:09 -0800 (PST)
MIME-Version: 1.0
Received: by with SMTP id x9mr52179834pbb.109.1321297568729; Mon, 14 Nov 2011 11:06:08 -0800 (PST)
Received: by with HTTP; Mon, 14 Nov 2011 11:06:08 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Mon, 14 Nov 2011 13:06:08 -0600
Message-ID: <>
From: Nico Williams <>
To: "Martin J. Dürst" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Roy Fielding <>, "" <>
Subject: Re: [apps-discuss] A modest proposal for MIME types (and URI schemes)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Nov 2011 19:06:11 -0000

On Mon, Nov 14, 2011 at 1:09 AM, "Martin J. Dürst"
<> wrote:
> On 2011/11/14 3:59, Larry Masinter wrote:
>> * Eliminate standards, vendor, personal trees distinction for MIME types
>> (For URI schemes, eliminate distinction between provisional and permanent
>> schemes)
>> * ENCOURAGE vendors to ship with vendor-neutral short-named types
>> regardless of whether they have been registered yet or not;
> I think that makes sense for something widely known and used (e.g.
> application/pdf), but not necessarily for some really company-specific type.
> (Of course, we don't know in advance which way something may go in the end,
> but we could use this rule at least for when the company e.g. wants to
> express that a type is NOT intended for general use).

I'm not sure what "really company-specific type" means.  Not to be
leaked on the public Internet?  Even so, and even assuming there's an
enormous number of private-use-only media types (I doubt it), what's
the reason to not encourage registration of them?

>> * DO NOT try to avoid duplicates
> I'm not sure this makes sense. I think it would make sense if it read "give
> up on trying to avoid duplicates at all cost". But it almost reads like
> "let's have many duplicates, this will be fun".

I think we should discourage collisions, but the very existence of the
registry does that.  If a collision arose from registry avoidance, and
implementations have been deployed widely, then what more can we do
but accept it?

>> * EXPERT REVIEW for updates to existing registrations
>> * Eliminate any IESG or consensus review requirement
>> "There is absolutely no need to prevent name collisions in the registry
>> itself because those collisions are irrelevant -- what matters is how the
>> names are interpreted by recipients of messages."

If two implementations interpret the same media type name to mean
different things and thus fail to interop, *that* is a collision.
Collisions are bad, but I don't think it's necessary to avoid them at
all costs, since collisions are hardly fatal (the market will pick a
winner, or implementors will disambiguate in some other manner, such
as by content sniffing).

> Well, but isn't one goal of the effort to get the registry to (more closely)
> reflect reality? In this case, if there are two application/foo, and
> applications recognize one and not the other, then there's a disconnect.

If the collision has been deployed, not allowing it to be documented
hardly makes the collision go away.