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

Nico Williams <nico@cryptonector.com> Mon, 14 November 2011 19:06 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEC711E834F for <apps-discuss@ietfa.amsl.com>; Mon, 14 Nov 2011 11:06:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.778
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCVFxKB6zdms for <apps-discuss@ietfa.amsl.com>; Mon, 14 Nov 2011 11:06:10 -0800 (PST)
Received: from homiemail-a71.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id D831E11E834C for <apps-discuss@ietf.org>; Mon, 14 Nov 2011 11:06:10 -0800 (PST)
Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id C35C8428075 for <apps-discuss@ietf.org>; Mon, 14 Nov 2011 11:06:09 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id 9EAA0428072 for <apps-discuss@ietf.org>; Mon, 14 Nov 2011 11:06:09 -0800 (PST)
Received: by ggnr5 with SMTP id r5so1383202ggn.31 for <apps-discuss@ietf.org>; Mon, 14 Nov 2011 11:06:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.12.105 with SMTP id x9mr52179834pbb.109.1321297568729; Mon, 14 Nov 2011 11:06:08 -0800 (PST)
Received: by 10.68.40.162 with HTTP; Mon, 14 Nov 2011 11:06:08 -0800 (PST)
In-Reply-To: <4EC0BE9E.8020702@it.aoyama.ac.jp>
References: <C68CB012D9182D408CED7B884F441D4D0611DABF22@nambxv01a.corp.adobe.com> <4EC0BE9E.8020702@it.aoyama.ac.jp>
Date: Mon, 14 Nov 2011 13:06:08 -0600
Message-ID: <CAK3OfOiEfX3duaWSAZZ9T+pb9UofceH_xXW2SCBnyjLHeHHe4Q@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Roy Fielding <fielding@adobe.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] A modest proposal for MIME types (and URI schemes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=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"
<duerst@it.aoyama.ac.jp> 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.

Nico
--