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

Ned Freed <ned.freed@mrochek.com> Tue, 15 November 2011 04:48 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 95B2321F8D12 for <apps-discuss@ietfa.amsl.com>; Mon, 14 Nov 2011 20:48:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.577
X-Spam-Level:
X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 zztCE1jOGEoB for <apps-discuss@ietfa.amsl.com>; Mon, 14 Nov 2011 20:48:44 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0720B21F8CFC for <apps-discuss@ietf.org>; Mon, 14 Nov 2011 20:48:44 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O8F9SD7W1S00KTFO@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 14 Nov 2011 20:48:39 -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 20:48:35 -0800 (PST)
Message-id: <01O8F9SALNSQ00RCTX@mauve.mrochek.com>
Date: Mon, 14 Nov 2011 20:38:44 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Tue, 15 Nov 2011 02:08:38 +0000" <4EC1C9A6.6080201@isode.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <C68CB012D9182D408CED7B884F441D4D0611DABF22@nambxv01a.corp.adobe.com> <4EC0BE9E.8020702@it.aoyama.ac.jp> <01O8ETBP3QY400RCTX@mauve.mrochek.com> <4EC1C9A6.6080201@isode.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Cc: Ned Freed <ned.freed@mrochek.com>, 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: Tue, 15 Nov 2011 04:48:44 -0000

> Hi Ned,

> On 14/11/2011 19:33, Ned Freed wrote:
> >> > * 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)
> If by "throw out (1)-(3)" you mean just have 1 type of registration,
> then yes, I think this is what Roy proposed.

No, that's not what I meant. The ad-hoc, incomplete, duplicates allowed
approach being proposed bears a strong resemblance to our current comment and
revision process (4) - you know, the one nobody has ever seen any value in
using.

> I would personally like to better understand the thinking behind having
> a separate standards tree registration. What would be disadvanteges of
> dropping (3)? What was the original purpose for having a separate
> registration from vendor types?

The original reason was that people weren't registering their types under the
standards-tree-only rules we originally set up. When we looked at the problem
we didn't see a need for there to be publicly available documentation and
change control associated with a standards body for a format to be useful.  So
we created a means by which formats used by commercial products could be
registered with comparative simplicity and ease.

And the result was people started registering stuff. Of course it wasn't as
many as we hoped, and by this point a large number of unregistered types had
gotten deployed as a result of our original choice to set the bar too high.
We're still paying for that.

				Ned