Re: Proposal: new top level domain '.urn' alleviates all need for urn: URIs

Patrick.Stickler@nokia.com wrote:

> Well, I consider both to be elegant solutions. I just consider
> a new top level domain to be more optimal, all things considered.
> 
> DDDS may be your preferred solution, but I would hope you
> could see the domain based solution as something a bit more
> refined than a hack.

You lost me here. I said using http://urn.X.Y was a hack, a 
sufficient one.


> But, hey, feel free to think what you like. I won't argue
> the point.

Thank you. Feel free to follow the thread.



>>How do you come to that conclusion? I can see at least two added 
>>cost burdens.
> 
> 
> Which are..... 

Oh come on! Buying into a new tld instead of regsitering a urn 
scheme. Providing  the resolution service (when they copuld jsut 
provide HTTP UTIs).


> You're going to have to provide some hard cold facts
> to convince me of that.

I don't need to convince you of anything. Your convictions don't 
chnage how the web functions.



> Sorry. No. That's like saying a car's design is responsible for a
> lousy taxi driver, who is rude, drives to fast and is shamelessly 
> flatulant. Since there exist many acceptable and even some execellent
> taxi drivers using the same technology and working within the 
> same constraints, we can fairly attribute failure for a satisfactory
> taxi experience to the driver, not the vehicle.

Irrelevancy objection.


> My point was that organizations managing URN minting services
> will be expected to provide certain basic services and if 
> one particular organization fails to do so, or does so in an
> unsatisfactory manner as compared to other organizations
> providing the same services with the same architecture, 
> then the failures or shortcomings of one organization have little 
> to nothing to do with the architecture.

It has everything to do with the architecture. The web wasn't 
designed to route such traffic through a single server. Which is why 
   I cite the purl idea working insofar as not too many people use 
the service.


> ???
> 
> Precisely how does it punish them?

Type 'slashdot effect' or 'google cluster architecture' into a 
search engine.


>>Look, the basic idea is probably ok given the absence of DDDS, but 
>>rolling this out, ie making it 'general architecture' as opposed to 
>>some quick fix is non-tenable given what we know about building web 
>>systems that we didn't know 10 years ago. But It might be worth 
>>doing just to force some action on the urn/http thing.
> 
> 
> You seem to see specific flaws in the proposal, but I've yet
> to get any clear picture what they are.

Routing urn resolution traffic through a single management 
infrastructure acting as a front controller to content providers 
will be problematic, at best. Even DNS isn't that centralized.  Why 
would you want to spec that?



> In either scenario, we have
> 
> 1. A hierarchy of organizations that control URI allocation.
> 2. A means to reflect that hierarchy in URI structure.
> 3. A mapping from more-opaque name to less-opaque name.
> 4. A mapping from less-opaque name to representation.
> 
> Both my proposal as well as the urn: URI scheme and DDDS
> provide solutions for the above. But applying Occam's Razor,
> my proposal does so with less machinery, and particularly,
> with already deployed technology.

So does my urn.X.Y hack, but at a fraction of the cost to the 
provider. heck you could just define a urn.txt at the server root 
and allow people to GET urns.

Bill de hÓra

Received on Monday, 7 July 2003 15:50:17 UTC