Re: dns media type registration tree
Hi Ned,
I've been following this discussion for a while now, and while it pains me to object to something that would lessen my own workload, I find that I have to agree with Keith about this. The stability problems associated with DNS names are just too great. [...] Given the huge amount of damage that's been inflicted on the world by badly designed media types, I am forced to see further reduction of the barriers as a reckless step in the wrong direction.
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. This is borne out when you examine mime.types files and Web browser configurations; deployed software and formats are ignoring the process quite freely. The other effect is that it encourages people to avoid media types altogether, so that formats don't have well-known identifiers, or if they do, ones that aren't usable in current systems like MIME or the Web (QNames in WSDL come to mind especially). A DNS-based type does indeed have a chance of the authority changing, but I believe this possibility is preferable to the lack of a usable identifier. So, I'd put forth that the current system doesn't discourage badly designed media types (or formats); every incentive is for people to use the "x-" space, though it is officially discouraged, leading to confusion. It does discourage well-designed media types and formats from actually being registered, which hurts software and systems that leverage them. If there's another solution to this, I'm all ears. Cheers, -- Mark Nottingham http://www.mnot.net/
At 6pm on 3/03/04 you (Mark Nottingham) wrote:
Hi Ned,
I've been following this discussion for a while now, and while it pains me to object to something that would lessen my own workload, I find that I have to agree with Keith about this. The stability problems associated with DNS names are just too great. [...] Given the huge amount of damage that's been inflicted on the world by badly designed media types, I am forced to see further reduction of the barriers as a reckless step in the wrong direction.
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. This is borne out when you examine mime.types files and Web browser configurations; deployed software and formats are ignoring the process quite freely.
I would strongly second this. Even very well-known types such as Macromedia Flash still universally go by names like application/x-shockwave-flash, which helps noone. There is no review of these names, and no means to prevent them clashing. If using the DNS for providing unique names is seen as a bad idea, both because the names are volatile and because it is misusing a system that was never designed to provide GUIDs, then how about creating a separate registry of 'organisations' which can then manage their own trees? So, e.g., Macromedia could register */org.macromedia.* with the IETF, and then manage that namespace themselves. The idea of each MIME type carrying a parameter giving a URL with a human-readable description of the format is also well worth preserving. Ben -- Every twenty-four hours about 34k children die from the effects of poverty. Meanwhile, the latest estimate is that 2800 people died on 9/11, so it's like that image, that ghastly, grey-billowing, double-barrelled fall, repeated twelve times every day. Full of children. [Iain Banks] ben@morrow.me.uk
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. Back when MIME was first standardized the registration system was a total mess. The requirements were unclear, and even in the places where the require=ments were clear they were too hard to meet. Add to this the fact that IANA didn't have its act together at all, there was no web form, registrations submitted by email sometimes sat in a queue for up to a year before being acted on. All this has changed. The rules were substantially rewritten, the position of a MIME registration reviewer was created, IANA got new people in, reorganized the web site, and started dealing with requests in a far more expeditious fashion. These days it is simple to submit a request and responses often come back in a few days. But this cleanup took years to implement. And by then considerable damage had been done. The widespread use of of many if not most of the x- types you are complaining about was established almost a decade back under the old rules. In any case, now that the rules are what they are it is far from clear to me that there is a problem here that is worth solving. Are new x- types being invented today? The answer is probably yes, but my guess is that the rate has dropped considerably. And the people who are still doing it are likely ones who haven't caught on to the rule changes and are no more likely to switch to using a DNS tree than the existing vendor tree.
This is borne out when you examine mime.types files and Web browser configurations; deployed software and formats are ignoring the process quite freely.
And if you check the history you'll find that many if not most of these are very old.
I would strongly second this. Even very well-known types such as Macromedia Flash still universally go by names like application/x-shockwave-flash, which helps noone. There is no review of these names, and no means to prevent them clashing.
A situation which the instability inherent in domain names does little to help.
If using the DNS for providing unique names is seen as a bad idea, both because the names are volatile and because it is misusing a system that was never designed to provide GUIDs, then how about creating a separate registry of 'organisations' which can then manage their own trees? So, e.g., Macromedia could register */org.macromedia.* with the IETF, and then manage that namespace themselves. The idea of each MIME type carrying a parameter giving a URL with a human-readable description of the format is also well worth preserving.
We're going to go down that path we might as well use OIDs. Ned
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/
My personal observation is that most of the reasons why people deploy software that uses unregistered MIME types won't be adding a DNS-based tree. Things like: * Don't want to bother telling anyone else about the MIME type, they'll find out soon enough * Don't want to reveal product information before product ships * Can't figure out what the forms or terms mean, hard to figure out what a good example might be. * Confusion about registration of file extensions and MIME types While the current form for submitting a MIME type registration is a great improvement on what we had before, the registration process is still pretty mysterious, not particularly well advertised, etc., hard to figure out... I don't think adding a DNS tree will do more to address these problems.... it just makes the situation more complicated, precedents less reliable, and confuse people even more. What do engineers who are developing new file formats need? Probably some way of registering a MIME type and file extension and Macintosh format/creator IDs at the same time, and some questionaire that leads them through development of the answers, let's them get reviews from their management, etc. Look at the process from the point of view of the people who we want to use it. Larry
Hi Larry, On Mar 4, 2004, at 4:27 AM, Larry Masinter wrote:
My personal observation is that most of the reasons why people deploy software that uses unregistered MIME types won't be adding a DNS-based tree. Things like:
* Don't want to bother telling anyone else about the MIME type, they'll find out soon enough
This is a reason why they don't register; don't know why it would stop them from using a dns tree.
* Don't want to reveal product information before product ships
Very much the same as above; a dns tree approach would allow them to keep it secret until ship time.
* Can't figure out what the forms or terms mean, hard to figure out what a good example might be.
No forms for the dns tree.
* Confusion about registration of file extensions and MIME types
You win there, if we figure this one out I'd be very happy.
While the current form for submitting a MIME type registration is a great improvement on what we had before, the registration process is still pretty mysterious, not particularly well advertised, etc., hard to figure out...
+1. The nice thing about the dns tree approach is that it's obvious what to do once you see one or two. [...]
Look at the process from the point of view of the people who we want to use it.
+1; that's what led me in this direction. -- Mark Nottingham http://www.mnot.net/
On Mar 4, 2004, at 4:27 AM, Larry Masinter wrote:
What do engineers who are developing new file formats need? Probably some way of registering a MIME type and file extension and Macintosh format/creator IDs at the same time, and some questionaire that leads them through development of the answers, let's them get reviews from their management, etc.
Look at the process from the point of view of the people who we want to use it.
I'd also point out that in some cases, those developing a format are ignorant of or unconcerned with the utility of a media type, and aren't motivated to engage the process. As a result, the people who want to leverage existing systems using media types -- and not those who author new formats --are the ones who pay the highest price. The popular (but unidentified, as far as media types are concerned) RSS format is a good example of this. -- Mark Nottingham http://www.mnot.net/
participants (4)
-
ben＠morrow.me.uk -
Larry Masinter -
Mark Nottingham -
ned.freed＠mrochek.com