
Hi, I wanted to express my *strong* support for the recently published draft about the "dns" media type registration tree[1]. I think this is long overdue, and I thank Mark for devising such a straightforward mechanism for decentralizing the media type assignment process (you don't want to know what I was going to propose 8-). I would like to propose one substantive change to the document though. As I see it, there are two objectives that we'd really like to achieve; a decentralized namespace, and dereferenceable identifiers (for all the reasons in [2]). Mark's draft ably addresses the former, but doesn't seem to treat the latter as an objective, although the "doc" parameter is a step in that direction. I think a fairly small tweak can give us both. What I propose is that the doc parameter be replaced by a "base" parameter whose value is a URI that is intended to permit the media type name itself to be used as a relative URI. For example, if we had the media type "text/dns.foo.example.com", with a base parameter value of "http://example.com/mtype/" then the authoritative URI for the media type would be "http://example.com/mtype/text/dns.foo.example.com" (see the discussion[3] about the relative URI approach by the W3C TAG). The document should be clear that the resultant URI is the authoritative URI for the media type. It would still be optional, though I'd like to say that we recommend that it SHOULD be used, and SHOULD be dereferenceable using currently ubiquitous technologies. Thoughts? [1] http://www.ietf.org/internet-drafts/draft-nottingham-dns-media-tree-00.txt [2] http://www.ietf.org/internet-drafts/draft-connolly-w3c-accessible-registries... [3] http://www.w3.org/2003/12/15-tag-summary.html#uriMediaType-9 Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca

I'm wondering if we should consider a similar DNS-basis for "private" URI schemes. I've been late in producing a new version of http://www.ietf.org/internet-drafts/draft-king-vnd-urlscheme-03.txt partly because of my uneasiness with IANA getting into the business of registering organization names. Larry
-----Original Message----- From: ietf-types-bounces@alvestrand.no [mailto:ietf-types-bounces@alvestrand.no] On Behalf Of Mark Baker Sent: Tuesday, January 13, 2004 11:16 AM To: ietf-types@alvestrand.no Subject: dns media type registration tree
Hi,
I wanted to express my *strong* support for the recently published draft about the "dns" media type registration tree[1]. I think this is long overdue, and I thank Mark for devising such a straightforward mechanism for decentralizing the media type assignment process (you don't want to know what I was going to propose 8-).
I would like to propose one substantive change to the document though.
As I see it, there are two objectives that we'd really like to achieve; a decentralized namespace, and dereferenceable identifiers (for all the reasons in [2]). Mark's draft ably addresses the former, but doesn't seem to treat the latter as an objective, although the "doc" parameter is a step in that direction. I think a fairly small tweak can give us both.
What I propose is that the doc parameter be replaced by a "base" parameter whose value is a URI that is intended to permit the media type name itself to be used as a relative URI. For example, if we had the media type "text/dns.foo.example.com", with a base parameter value of "http://example.com/mtype/" then the authoritative URI for the media type would be "http://example.com/mtype/text/dns.foo.example.com" (see the discussion[3] about the relative URI approach by the W3C TAG). The document should be clear that the resultant URI is the authoritative URI for the media type. It would still be optional, though I'd like to say that we recommend that it SHOULD be used, and SHOULD be dereferenceable using currently ubiquitous technologies.
Thoughts?
[1] http://www.ietf.org/internet-drafts/draft-nottingham-dns-media -tree-00.txt [2] http://www.ietf.org/internet-drafts/draft-connolly-w3c-accessi ble-registries-00.txt [3] http://www.w3.org/2003/12/15-tag-summary.html#uriMediaType-9
Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca

At 2pm on 13/01/04 you (Mark Baker) wrote:
I wanted to express my *strong* support for the recently published draft about the "dns" media type registration tree[1]. I think this is long overdue, and I thank Mark for devising such a straightforward mechanism for decentralizing the media type assignment process (you don't want to know what I was going to propose 8-).
I would like to propose one substantive change to the document though.
I would agree, both with your support for the system in general and with your modification. Ben -- Heracles: Vulture! Here's a titbit for you / A few dried molecules of the gall From the liver of a friend of yours. / Excuse the arrow but I have no spoon. (Ted Hughes, [ Heracles shoots Vulture with arrow. Vulture bursts into ] /Alcestis/) [ flame, and falls out of sight. ] ben@morrow.me.uk

Let me play Devil's advocate here. I'm not sure why people assume that just because they are familiar with how to allocate names in a particular name space, that that name space should then be adapted to every purpose that comes to mind. There is value in having semantics associated with a name space - a value which is diluted by using that name space for a wide variety of purposes. DNS is too overloaded as it is. Beyond that, DNS is not well-suited for media types. DNS assignments are ephemeral. They are subject to change as their assignees (e.g. the organizations whose names they reflect) merge, split, go bankrupt, fail to renew their registrations, or sell off trademarks. They are subject to reassignment for arbitrary reasons. We discovered long ego that URIs based on DNS names are not suitable for long-term (archival) use precisely because those names change; that's why URNs and DOIs were invented. And the utility of URNs has been nearly destroyed by misuse and overloading of that name space. It must be questioned whether it is beneficial to the public to define new media types on a whim anyway. The failure to pay proper attention to the design of media types, the failure to do security analysis of media types, and the failure to respect those analyses even when they are done is the reason why email- and web-borne viruses and worms cost billions of dollars to consumers. If there really is a compelling need (meaning that it serves the greater good) to define new media types at a whim, a much better set of names already exists, one which was more-or-less designed for that purpose. It's called OIDs. They are easy to obtain. They are recursively extensible just like DNS names (actually moreso). It is relatively well-established that once assigned, the meanings of OIDs do not change. They don't contain human-readable content that invites disputes over ownership. The argument for DNS media types reminds me of countless other arguments for why protocol X should be used for everything (or at least, every instance of some large class of problem). In the past X has taken on values such as SOAP, XML, HTTP, SNMP, LDAP, URLs, SSL, ASN.1, RPC, and even TELNET. Most of those arguments look pretty naive now, but people took them seriously when they were in fashion. Now it's essentially being argued that since DNS is a widely-deployed namespace and query protocol, that it should be used for yet one more thing that could be looked up. Keith p.s. gratuitous analogy to a famous quote: Abraham Maslow is supposed to have said "It is tempting if the only tool you have is a hammer, to treat everything as if it were a nail." I like Mike O'Dell's version better, which I'll parphrase since I didn't manage to write it down at the time: "If you need to drive a nail, the fact that you have your forehead with you doesn't make it a good tool for the job."

On Sat, Feb 21, 2004 at 02:44:12PM -0500, Keith Moore wrote:
Let me play Devil's advocate here.
Good stuff Keith, thanks.
I'm not sure why people assume that just because they are familiar with how to allocate names in a particular name space, that that name space should then be adapted to every purpose that comes to mind. There is value in having semantics associated with a name space - a value which is diluted by using that name space for a wide variety of purposes. DNS is too overloaded as it is.
Agreed. The dns tree doesn't remove the need for the IETF tree, nor the need for review. IMO, it just does two very useful things; - it's a better form of x/vnd/prs tree, especially when combined with my proposed URI extension - it enables new authorities to establish their own review policies over their part of the media tree namespace
Beyond that, DNS is not well-suited for media types. DNS assignments are ephemeral. They are subject to change as their assignees (e.g. the organizations whose names they reflect) merge, split, go bankrupt, fail to renew their registrations, or sell off trademarks. They are subject to reassignment for arbitrary reasons. We discovered long ego that URIs based on DNS names are not suitable for long-term (archival) use precisely because those names change; that's why URNs and DOIs were invented. And the utility of URNs has been nearly destroyed by misuse and overloading of that name space.
Gotta disagree there. There is *far* too much depending upon the DNS->authority mapping to have it ripped out from under us. If something eventually replaces DNS (while still being centrally administered), there will be *enormous* and IMO, unescapable pressure to have that system be an extension of DNS so that existing DNS name->authority mappings persist. P.S. Dan Connolly and I talked about this; http://www.ietf.org/internet-drafts/draft-connolly-w3c-accessible-registries... (... which we should really do something with)
It must be questioned whether it is beneficial to the public to define new media types on a whim anyway. The failure to pay proper attention to the design of media types, the failure to do security analysis of media types, and the failure to respect those analyses even when they are done is the reason why email- and web-borne viruses and worms cost billions of dollars to consumers.
Agreed. See my first response above. I expect that I disagree with MarkN on this too; I don't think that the use of XML necessarily requires a multitude of media types (and I'm not talking about using "application/xml" for everything). Personally, my money's on description frameworks like RDF to moderate the need for new media types. So while I agree with you that a myriad of media types is bad, I don't believe that the DNS tree either encourages this (any more than do existing extensibility processes and mechanisms), nor do I believe that the tree is only useful in that case.
If there really is a compelling need (meaning that it serves the greater good) to define new media types at a whim, a much better set of names already exists, one which was more-or-less designed for that purpose. It's called OIDs. They are easy to obtain. They are recursively extensible just like DNS names (actually moreso). It is relatively well-established that once assigned, the meanings of OIDs do not change. They don't contain human-readable content that invites disputes over ownership.
They're also not derefenceable. I think that's a huge loss. See the draft mentioned above for more on that subject.
The argument for DNS media types reminds me of countless other arguments for why protocol X should be used for everything (or at least, every instance of some large class of problem). In the past X has taken on values such as SOAP, XML, HTTP, SNMP, LDAP, URLs, SSL, ASN.1, RPC, and even TELNET. Most of those arguments look pretty naive now, but people took them seriously when they were in fashion. Now it's essentially being argued that since DNS is a widely-deployed namespace and query protocol, that it should be used for yet one more thing that could be looked up.
AFAIK, it's the only universally deployed means of mapping strings to authorities on the Internet. I'd also prefer a better solution, but I'm not aware of any.
p.s. gratuitous analogy to a famous quote:
Abraham Maslow is supposed to have said "It is tempting if the only tool you have is a hammer, to treat everything as if it were a nail."
I like Mike O'Dell's version better, which I'll parphrase since I didn't manage to write it down at the time:
"If you need to drive a nail, the fact that you have your forehead with you doesn't make it a good tool for the job."
8-) Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca

I'm not sure why people assume that just because they are familiar with how to allocate names in a particular name space, that that name space should then be adapted to every purpose that comes to mind. There is value in having semantics associated with a name space - a value which is diluted by using that name space for a wide variety of purposes. DNS is too overloaded as it is.
Agreed. The dns tree doesn't remove the need for the IETF tree, nor the need for review. IMO, it just does two very useful things;
- it's a better form of x/vnd/prs tree, especially when combined with my proposed URI extension
How does making it easier to create new types equate to "better"?
- it enables new authorities to establish their own review policies over their part of the media tree namespace
This is NOT inherently a good thing. There aren't many restrictions in the current IETF policy, and relaxing these few restrictions is probably not in the best interests of the network. Sure enough, some other organizations would also do due diligence in reviewing new types; some would do a better job than IETF. But encouraging anybody with a domain name to register new types will certainly result in less review overall.
Beyond that, DNS is not well-suited for media types. DNS assignments are ephemeral. They are subject to change as their assignees (e.g. the organizations whose names they reflect) merge, split, go bankrupt, fail to renew their registrations, or sell off trademarks. They are subject to reassignment for arbitrary reasons. We discovered long ego that URIs based on DNS names are not suitable for long-term (archival) use precisely because those names change; that's why URNs and DOIs were invented. And the utility of URNs has been nearly destroyed by misuse and overloading of that name space.
Gotta disagree there.
There is *far* too much depending upon the DNS->authority mapping to have it ripped out from under us. If something eventually replaces DNS(while still being centrally administered), there will be *enormous* and IMO, unescapable pressure to have that system be an extension of DNS so that existing DNS name->authority mappings persist.
You're talking about the DNS namespace as a whole; I'm talking about individual DNS names. I agree that there will be tremendous pressure to maintain the DNS name space even if (say) the DNS protocol changes. But we've seen numerous examples where DNS names were allowed to expire and were then reassigned; we've also seen a few examples where DNS names were taken away from their original owners and reassigned for apparently arbitrary reasons.
I expect that I disagree with MarkN on this too; I don't think that the use of XML necessarily requires a multitude of media types (and I'm not talking about using "application/xml" for everything). Personally, my money's on description frameworks like RDF to moderate the need for new media types.
Mumble. Multi-layer dispatching seems like something to avoid; or at least, to be wary of.
So while I agree with you that a myriad of media types is bad, I don't believe that the DNS tree either encourages this (any more than do existing extensibility processes and mechanisms), nor do I believe that the tree is only useful in that case.
The existing mechanisms for defining new names try to strike a balance between the need for registration and the fact that people will define their own types without registering them - if they don't understand how to register new types or they believe it's too difficult to do so. This proposal would upset that balance and tip it in the wrong direction.
If there really is a compelling need (meaning that it serves the greater good) to define new media types at a whim, a much better set of names already exists, one which was more-or-less designed for that purpose. It's called OIDs. They are easy to obtain. They are
recursively extensible just like DNS names (actually moreso). It is
relatively well-established that once assigned, the meanings of OIDs do not change. They don't contain human-readable content that invites disputes over ownership.
They're also not derefenceable. I think that's a huge loss. See the draft mentioned above for more on that subject.
That's a feature, not a bug.
The argument for DNS media types reminds me of countless other arguments for why protocol X should be used for everything (or at least, every instance of some large class of problem). In the past X has taken on values such as SOAP, XML, HTTP, SNMP, LDAP, URLs, SSL, ASN.1, RPC, and even TELNET. Most of those arguments look pretty naive now, but people took them seriously when they were in fashion. Now it's essentially being argued that since DNS is a widely-deployed namespace and query protocol, that it should be used for yet one more thing that could be looked up.
AFAIK, it's the only universally deployed means of mapping strings to authorities on the Internet.
In fact, that's not what DNS is. It's a protocol for finding the network addresses associated with hosts and services. -- He not busy being born, is busy dying. - Bob Dylan

Hi Keith, On Mon, Mar 01, 2004 at 12:41:33PM -0500, Keith Moore wrote:
- it's a better form of x/vnd/prs tree, especially when combined with my proposed URI extension
How does making it easier to create new types equate to "better"?
It only necessarily makes it easier by avoiding registration, but I believe that your concern is with the implicit avoidance of the review process. I think you can have the best of both worlds by revising Mark's draft to have more draft-freed-mime-p4 -like semantics. Something like; While public exposure and review of media types using the DNS tree is not required, using the ietf-types@iana.org mailing list for review is strongly encouraged to improve the quality of those specifications. Would that address your concern?
- it enables new authorities to establish their own review policies over their part of the media tree namespace
This is NOT inherently a good thing. There aren't many restrictions in the current IETF policy, and relaxing these few restrictions is probably not in the best interests of the network. Sure enough, some other organizations would also do due diligence in reviewing new types; some would do a better job than IETF. But encouraging anybody with a domain name to register new types will certainly result in less review overall.
After thinking about it some more, I'd like to retract my previous claim; the DNS tree does not enable this, because it's *already* enabled. Consider the WAPforum and some of their media types such as vnd.wap-wbxml, vnd-wap-wmlc, and vnd.wap.wmlscriptc. These were all run through the WAPforum and its processes. They were also reviewed by the IETF as part of the registration procedure.
You're talking about the DNS namespace as a whole; I'm talking about individual DNS names. I agree that there will be tremendous pressure to maintain the DNS name space even if (say) the DNS protocol changes. But we've seen numerous examples where DNS names were allowed to expire and were then reassigned; we've also seen a few examples where DNS names were taken away from their original owners and reassigned for apparently arbitrary reasons.
Yep. Nothing's perfect. If you can do any better while permitting decentralized dereferencing, I'm all ears.
I expect that I disagree with MarkN on this too; I don't think that the use of XML necessarily requires a multitude of media types (and I'm not talking about using "application/xml" for everything). Personally, my money's on description frameworks like RDF to moderate the need for new media types.
Mumble. Multi-layer dispatching seems like something to avoid; or at least, to be wary of.
It's not multi-layer; the URI and the media type remain the only dispatch points for requests. They're just dispatching a very generic application.
AFAIK, it's the only universally deployed means of mapping strings to authorities on the Internet.
In fact, that's not what DNS is. It's a protocol for finding the network addresses associated with hosts and services.
Sure, but as a consequence of doing that, it also provides the string to authority mapping. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca

While public exposure and review of media types using the DNS tree is not required, using the ietf-types@iana.org mailing list for review is strongly encouraged to improve the quality of those specifications.
Would that address your concern?
not really. I have yet to see why using DNS names, or the DNS itself, for type registration is a good idea.
- it enables new authorities to establish their own review policies over their part of the media tree namespace
This is NOT inherently a good thing. There aren't many restrictions in the current IETF policy, and relaxing these few restrictions is probably not in the best interests of the network. Sure enough, some other organizations would also do due diligence in reviewing new types; some would do a better job than IETF. But encouraging anybody with a domain name to register new types will certainly result in less review overall.
After thinking about it some more, I'd like to retract my previous claim; the DNS tree does not enable this, because it's *already* enabled. Consider the WAPforum and some of their media types such as vnd.wap-wbxml, vnd-wap-wmlc, and vnd.wap.wmlscriptc. These were all run through the WAPforum and its processes. They were also reviewed by the IETF as part of the registration procedure.
additional review is of course not the same thing as circumventing IETF review.
You're talking about the DNS namespace as a whole; I'm talking about individual DNS names. I agree that there will be tremendous pressure to maintain the DNS name space even if (say) the DNS protocol changes. But we've seen numerous examples where DNS names were allowed to expire and were then reassigned; we've also seen a few examples where DNS names were taken away from their original owners and reassigned for apparently arbitrary reasons.
Yep. Nothing's perfect. If you can do any better while permitting decentralized dereferencing, I'm all ears.
that's the problem in a nutshell - it's not clear to me that "decentralized dereferencing" (much less "decentralized review" or "decentralized assignment") is a good idea.
Mumble. Multi-layer dispatching seems like something to avoid; or at least, to be wary of.
It's not multi-layer; the URI and the media type remain the only dispatch points for requests. They're just dispatching a very generic application.
and you don't think there is ever a need for further dispatching at the XML level? in other words, all XML documents are going to the same application?
AFAIK, it's the only universally deployed means of mapping strings to authorities on the Internet.
In fact, that's not what DNS is. It's a protocol for finding the network addresses associated with hosts and services.
Sure, but as a consequence of doing that, it also provides the string to authority mapping.
It's not designed for that, and it's not well-suited for that.

Ok, I think we've done a good job boiling the disagreement down to its essence. Thanks. It would be good if other folks could chime in with their views, so we know where we stand. Also, I should add that I've not been coordinating with Mark Nottingham during this discussion, and I don't claim to speak for him. But I think our positions are very closely aligned. And, just to quickly answer this question (we can take it offline if you like) ... On Tue, Mar 02, 2004 at 10:51:51AM -0500, Keith Moore wrote:
It's not multi-layer; the URI and the media type remain the only dispatch points for requests. They're just dispatching a very generic application.
and you don't think there is ever a need for further dispatching at the XML level? in other words, all XML documents are going to the same application?
Almost; the URI becomes the sole dispatch point. It's very similar to tuple space based systems (e.g. Linda), where the identifier for the space is all that's used for dispatch. In my experience, it's a really nice way to build a wide variety of applications. I'm also not saying that non-RDF uses of XML (and therefore other */*+xml media types) won't be needed, only that in my experience, RDF/XML is a decent 95% solution. Hence my comment about RDF/XML "moderating" the need for an explosion of XML media types. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca

It's not multi-layer; the URI and the media type remain the only dispatch points for requests. They're just dispatching a very generic application.
and you don't think there is ever a need for further dispatching at the XML level? in other words, all XML documents are going to the same application?
Almost; the URI becomes the sole dispatch point.
only if all documents are XML. Personally I think XML is a passing fad :) (well, not really. but I don't see envision data formats migrating to XML, or at least I think it would be a really Bad Idea for that to happen.)

earlier today I wrote:
but I don't see envision data formats migrating to XML, or at least I think it would be a really Bad Idea for that to happen.)
sorry, that was a thinko. what I really meant to say was but I don't envision all data formats migrating to XML, or at least I think it would be a really Bad Thing for that to happen. -- He not busy being born, is busy dying. - Bob Dylan

While public exposure and review of media types using the DNS tree is not required, using the ietf-types@iana.org mailing list for review is strongly encouraged to improve the quality of those specifications.
Would that address your concern?
not really. I have yet to see why using DNS names, or the DNS itself, for type registration is a good idea.
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.
- it enables new authorities to establish their own review policies over their part of the media tree namespace
This is NOT inherently a good thing. There aren't many restrictions in the current IETF policy, and relaxing these few restrictions is probably not in the best interests of the network. Sure enough, some other organizations would also do due diligence in reviewing new types; some would do a better job than IETF. But encouraging anybody with a domain name to register new types will certainly result in less review overall.
After thinking about it some more, I'd like to retract my previous claim; the DNS tree does not enable this, because it's *already* enabled. Consider the WAPforum and some of their media types such as vnd.wap-wbxml, vnd-wap-wmlc, and vnd.wap.wmlscriptc. These were all run through the WAPforum and its processes. They were also reviewed by the IETF as part of the registration procedure.
additional review is of course not the same thing as circumventing IETF review.
Right. The WAP forum went through the process and registered their types. The requirements the process imposed were minimal, but not nonexistant.
You're talking about the DNS namespace as a whole; I'm talking about individual DNS names. I agree that there will be tremendous pressure to maintain the DNS name space even if (say) the DNS protocol changes. But we've seen numerous examples where DNS names were allowed to expire and were then reassigned; we've also seen a few examples where DNS names were taken away from their original owners and reassigned for apparently arbitrary reasons.
Yep. Nothing's perfect. If you can do any better while permitting decentralized dereferencing, I'm all ears.
that's the problem in a nutshell - it's not clear to me that "decentralized dereferencing" (much less "decentralized review" or "decentralized assignment") is a good idea.
Exactly. 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. Ned
participants (5)
-
ben@morrow.me.uk
-
Keith Moore
-
Larry Masinter
-
Mark Baker
-
ned.freed@mrochek.com