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

[Ned Freed <[e-mail]>]

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