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

Patrick.Stickler@nokia.com wrote:

>>But if you insist on going forward, then:
>>
>>  http://urn.X.Y/
>>
>>is a sufficient hack. 
> 
> 
> I think it's a rather elegant solution, not really a hack. 

Of course you do. I think DDDS is the elegant solution.


> It
> simply uses the existing domain and subdomain name registration
> infrastructure, guidelines, and general practices to partition
> the URI space

That's eactly what's wrong with it.


> But it does so in a manner that exploits the deployed HTTP
> infrastructure 

That's what it doesn't do. It exploits a server in the infrastructure.


> Had someone thought of this approach back when URNs were first
> being concieved, we'd probably have countless such HTTP-URNs
> in use today.

And that's what the problem would be - doubtless we'd be busy 
replacing it as a victim of its own success.


>>It also doesn't require inventing new points 
>>of failure in the web architecture*, doing DDDS badly, or the costs 
>>of dealing with ICANN and whoever provides this service.
> 
> 
> Quite.

Yes, quite.


>>* As for the full richness of the web archiecture, think about how 
>>the provider would scale this service. - I suspect purl works 
>>because not many people use it.
> 
> 
> Well, the worst case scenario would be that an organization
> would obtain a .urn subdomain (in the same manner as they would
> register an urn: subscheme) and would not provide any services
> whatsoever relating to URIs minted in that subdomain. That's
> no worse than the present situation with urn: URIs.

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


> However, in the best case scenario, and one which I expect will
> be the norm, the managing organization will provide an effective
> PURL or PURL like service for their customers.

Being the entire web.  PURL like services are effective in inverse 
proportion to the number of people or machines that use them.


> Granted, there will surely be a middle ground, which will have
> partial or even sporadic support for URIs minted in those
> namespaces, but at least the general architecture will not be to
> blame for that, and customers wanting HTTP-URNs will make their
> choices according to cost versus benefit.

Of course the 'general architecture' will be at blame for that. That 
tt doesn't cater for it, knowingly, is no excuse.

As for business/social - the economics of your architecture punish 
the provider of resolution the popular URIs. Now the web is like 
that already to some degree, but this is the first proposal I've 
seen that willfully encourages the problem.

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.

Bill de hÓra

Received on Monday, 7 July 2003 07:39:05 UTC