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

Ned Freed <ned.freed@mrochek.com> Mon, 14 November 2011 21:14 UTC

Return-Path: <ned.freed@mrochek.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 BE2FC11E818E for <apps-discuss@ietfa.amsl.com>; Mon, 14 Nov 2011 13:14:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.581
X-Spam-Level:
X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599]
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 EAVsbBYh30J0 for <apps-discuss@ietfa.amsl.com>; Mon, 14 Nov 2011 13:14:27 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2C44E11E812F for <apps-discuss@ietf.org>; Mon, 14 Nov 2011 13:14:27 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8ETX488PS0025DU@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 14 Nov 2011 13:14:21 -0800 (PST)
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=utf-8
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8DV7Q11A800RCTX@mauve.mrochek.com>; Mon, 14 Nov 2011 13:14:15 -0800 (PST)
Message-id: <01O8ETX0DJ4U00RCTX@mauve.mrochek.com>
Date: Mon, 14 Nov 2011 13:06:16 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Mon, 14 Nov 2011 13:06:08 -0600" <CAK3OfOiEfX3duaWSAZZ9T+pb9UofceH_xXW2SCBnyjLHeHHe4Q@mail.gmail.com>
References: <C68CB012D9182D408CED7B884F441D4D0611DABF22@nambxv01a.corp.adobe.com> <4EC0BE9E.8020702@it.aoyama.ac.jp> <CAK3OfOiEfX3duaWSAZZ9T+pb9UofceH_xXW2SCBnyjLHeHHe4Q@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
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 21:14:27 -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?

There actually a fairly large number of company-specific types, which is why we
allow the company name to be included in the type name. But as you say, the
majority of types aren't of this sort, which is why we don't require the
company name be present.

> >> * 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?

Agreed, but in practice it doesn't seem like outright collisions have
been much of an issue.

				Ned