- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Mon, 14 Feb 2005 11:16:23 -0800
- To: martind@netfolder.com
- Cc: "'Michael Mealling'" <michael@neonym.net>, "'W3C TAG'" <www-tag@w3.org>, colin.wallis@ssc.govt.nz, ferry.hendrikx@ssc.govt.nz
On Feb 14, 2005, at 6:34 AM, Didier PH Martin wrote: > It could be rigorously the same if we want to as it is often the case > with > technical solutions. This said, here are the differences if well done: > > a) The URN schema could be resolved with a DNS entry. This latter > contains > both the location and the name. In fact, this is what is really > happening > today with a URL being transformed into an IP. Its only that in the > case of > a URN both entries are of higher level not directly related to an IP > address but more to a URL. It could be, if the URN is tied to DNS and the people who mint the URNs also have control over the associated DNS zone file. If that system were deployed, it would make a URN a locator with DNS as its resolution mechanism. I see no difference between that and existing URI schemes aside from deployment. > B) in the case you illustrated, there is a URL to URL locator. This is > basically what we have today with indirections. However, the drawback > is > that the real thing is hidden; your front end is a single place and > therefore has a single point of failure, a bad name resolution > mechanism > indeed. On the other hand, a URN, if resolved with a DNS do not share > the > same flaw of a single point of failure. I don't follow that reasoning at all. An http URI based on a DNS hostname will indirect via common-place DNS address records and depend on the addresses returned (any modern CDN can remove the single points of failure for you). A URN resolved with DNS depends on specially-crafted zone files and extended record caching, such that it is dependent on each name server contacted. To remove the single points of failure from that system requires every local name server to be upgraded in addition to special-purpose DNS load balancing (caching the entire DNS response instead of just the addresses+TTL). > C) The information conveyed by the URN is as follow: the namespace is > owned > or is part of a name space identifier. Then all the names after that > can > follow different conventions as stated by the name space provider. It > could > be as well urn:nzl:registration(dogs)-1.0 Likewise for http URIs. > D) Social factor: They increased their chances that people won't > associate > the URN to a document located on the web. That is true, and I consider it to be a negative difference. > Bottom line: a name has nothing to do with a > location. It could be resolved to a location if the named thing is > locatable > on the net but this is not a necessity. It's a name. In contrast, a > locator > tells me _where_ (i.e. the location) is located something. It's all a > matter > of semantics. Sure, but if the thing being named is information that will be used in an information system, isn't it natural to conclude that it will be used as more than just a name? Isn't it easier to simply use an existing information system with names that are every bit as persistent as any system based on URNs-as-locators? >> Feel free to repeat yourself as often as you like -- deployment >> experience has so far proven you wrong. > > Roy, this is social factor, not technology. In the 90s people invested > in > stock really overvalued. They did that in the past with cars, tulips, > electricity, radio, etc... A winning technology is not necessarily the > best > one, only the one accepted by most of the people. It may change > overtime as > people learn; it may change because of a paradigm shift or any other > social > reason. Some people may find themselves in a minority when they use a > superior technology at first like, for instance, using a car instead > of a > horse. Even if the horses are at that moment the best deployment > experience > doesn't necessarily means that it's the best technology answering a > particular need. Bad example Roy, you use the argument of social > acceptance, > not a sound scientific argument. I did not intend it to be scientific. There were many naming systems that predated the Web and many that have been defined since the Web, but none of them have succeeded beyond the scope of a limited group of people who either were not given a choice or who whose grant money was tied to their use. Metcalfe's Law is at best a principle of economics, not a scientific argument, yet we have all seen it in practice. I didn't say that the Web is perfect -- I said that the Web is already deployed and already performs the only service that they need. > This is not a problem >> that technology can solve, and so far the most persistent names >> on the Internet are the ones that have the most usefulness. >> Personally, I think my 12 years studying this particular problem >> is more than sufficient to reach a conclusion, but you are free >> to disagree with any of my conclusions. > > Roy, this time you use the authority argument. I merely responded to your ridiculous suggestion that I should look at the problem again, completely ignoring the fact that I just spent three years revising the URI specification and working on Webarch (not to mention all of the other times I've written about it going all the way back to MOMspider). I am just trying to save them from the same costly mistake made by dozens of others. ....Roy
Received on Monday, 14 February 2005 19:16:35 UTC