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

Ned Freed <ned.freed@mrochek.com> Mon, 14 November 2011 20:57 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 767811F0D07 for <apps-discuss@ietfa.amsl.com>; Mon, 14 Nov 2011 12:57:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.434
X-Spam-Level:
X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, 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 esE9XQzbC1E6 for <apps-discuss@ietfa.amsl.com>; Mon, 14 Nov 2011 12:57:32 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id C099B1F0CF6 for <apps-discuss@ietf.org>; Mon, 14 Nov 2011 12:57:31 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8ETBRYZGG00033H@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 14 Nov 2011 12:57:09 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8DV7Q11A800RCTX@mauve.mrochek.com>; Mon, 14 Nov 2011 12:57:04 -0800 (PST)
Message-id: <01O8ETBP3QY400RCTX@mauve.mrochek.com>
Date: Mon, 14 Nov 2011 11:33:47 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Mon, 14 Nov 2011 16:09:18 +0900" <4EC0BE9E.8020702@it.aoyama.ac.jp>
MIME-version: 1.0
Content-type: TEXT/PLAIN; Format=flowed
References: <C68CB012D9182D408CED7B884F441D4D0611DABF22@nambxv01a.corp.adobe.com> <4EC0BE9E.8020702@it.aoyama.ac.jp>
To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
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 20:57:33 -0000

> > * Eliminate standards, vendor, personal trees distinction for MIME types
> > (For URI schemes, eliminate distinction between provisional and permanent
> > schemes)

OK, so let's see if I have this straight. There are four subprocesses involved:

(1) Personal type registrations. Rarely used.
(2) Vendor type registration. Commonly and successfully used.
(3) Standards tree registration. Used but has issues with timely processing
    of requests that we're supposed to be tryhing to fix.
(4) Third party revisions and comments process. Essentially never used.

And the proposal is to throw out (1)-(3) and depend on (4) happening because
... well, because.. This seems ... unlikely.

> > * ENCOURAGE vendors to ship with vendor-neutral short-named types
> > regardless of whether they have been registered yet or not;

I think encouraging vendor-neutral registrations would be great. The
question is how we'd actually do it.

> 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).

> >     ENCOURAGE the public to register any names that they have seen in
> > deployed software. (same for URI schemes)

> I think third-party registration is indeed something we should encourage
> more.

How do you propose we do that?

> > * 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".

Agreed.

> > * 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."

> 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.

Indeed there is, but not as big as the disconnect in thinking there's a magical
cure here that's going to solve all the problems.

				Ned