Re: [happiana] Reviews of draft-freed-media-type-regs-01 needed

[Ned Freed <ned.freed at mrochek.com>]

> The reality that I deal with, as the maintainer of the Apache types
> file, is that any review whatsoever is far more harmful than inaccurate
> information in the registry.  The inaccurate information can be fixed
> if we allow people other than the registrant to file corrections.

Which we have always allowed. RFC 4288, section 6.

> Failing to register (and then insisting that only the owner can register)
> makes the registry worse than useless.

Then it is a good thing it has never operated that way. We have always allowed
registrations by any interested party. Just as one example, quite a few 
of the Microsoft-related types weren't registered by anyone connected with
Microsoft.

> It actively interferes with my work.

Given it doen't work and has never worked the way you claim, I'm curious to
hear how that's possible.

> Likewise, splitting the registry into standards and vendors and personal
> types was an utter and complete failure that made the situation worse.

The evidence says otherwise. Past comments on this list say otherwise.

> There is no *need* for them. The only thing that it has accomplished is
> the further prevalence of x-types for vendor-neutral data formats, and
> we can never change those type names because there is no way for us to
> change the deployed client software that expects them.

You appear to be deeply confused about the essential nature of vnd. types.
Vendor types can be associated with a particular vendor if you want them to
be, but there is no requirement that this be the case - you can include
the vendor name in the type name if you want to or omit it if that makes
more sense.

The only thing the vnd. says is that the type is associated in some way with
one or more commercial products. That's it.

> People deploy with x-types because they mistakenly think that is what
> we want them to do if a type has not yet been registered.  They do not
> register their types before deployment because they are either in stealth
> mode (no pre-release about the product before it is announced) or because
> it is perceived to be a waste of time during the last minute struggles to
> ship a new product.  And once the product ships, that x-type is etched in
> stone because the servers can only send types that all deployed clients
> will understand.

Sounds like a documentation problem to me. Please suggest text.

> We should be *encouraging* vendors to ship with vendor-neutral short-named
> types regardless of whether they have been registered yet or not, and then
> we should be *encouraging* the public to register any names that they have
> seen in deployed software.

All this just to avoid the vnd. in front? Wow, I'm impressed by the branding
power we have here.

> There is absolutely no need to prevent people who are not the owners of
> a media type from registering that type without any prefixes.  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.  So let's stop wasting our
> time with silly roadblocks that discourage folks from registering a
> type before using it on the Internet, because we know damn well that
> none of these software companies (including my $work) will register a
> type before using it on the Internet.  That review serves no purpose.

> What we do need a review for is changes requested to existing types
> after they have been registered, just to avoid abuse of popular types,
> but that can be accomplished by expert review.

A process we already have now and which is for all intents and purposes unused.
Banking on this fixing our registration issues does NOT seem like a good idea.

				Ned