dns media type registration tree

[Mark Nottingham]

On Mar 3, 2004, at 11:33 AM, ned.freed at mrochek.com wrote:

>>> I agree these are the biggest -- and serious -- concerns with the
>>> proposal. However, the status quo doesn't seem to be working too 
>>> well;
>>> rather than discouraging frivolous or poorly-considered media types, 
>>> it
>>> encourages people into the "x-" space.
>
> I'm afraid this superficial analysis is fundamentally flawed, in that
> it ignores the fact that the rules have changed significantly over 
> time.

That's quite a sweeping statement, but thanks for considering my 
thoughts.

I'd agree that the current registration system has largely solved the 
problems you describe. Mark, I and others are seeing new problems in 
systems that don't leverage media types, and therefore don't integrate 
well with existing infrastructure. The most obvious example is that of 
Web services, which use QNames rather than media types to identify 
formats. This kind of approach may spread, because of its ease of use.

My perception -- which admittedly may be wrong -- is that one of the 
reasons this is happening is the overhead to registration; hence this 
proposal.

In a nutshell, the requirement is to achieve the same ease of use 
promised by other components of the Web; to be able to avoid central 
registration as much as possible when describing your data and its 
format. I'm open to any reasonable proposal that does that.

Leveraging the DNS seems appropriate in this light, mostly because 
other components of the Web (i.e., Namespaces in XML, which is the 
basis for much of the rest) also leverage it; therefore, they will not 
be made any more fragile if they use media types based upon the DNS.

Perhaps we need an approach that allows formats that already depend 
upon DNS for identification internally (e.g., those that use Namespaces 
in XML) to use it for format identification, without making other 
formats more fragile. Would a more URI-based approach (one that allowed 
URNs as well as dns-based URLs) be more palatable?

> We're going to go down that path we might as well use OIDs.

The problem with OIDs is that they're not human-readable, a property 
that has proven useful in protocols like HTTP. They also require 
central co-ordination separate from mechanisms commonly in use (i.e., 
domain names).


--
Mark Nottingham     http://www.mnot.net/