On Mar 3, 2004, at 11:33 AM, ned.freed@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/