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

[Ned Freed <[e-mail]>]

> 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