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

> -----Original Message-----
> From: ext Bill de hÓra [mailto:dehora@eircom.net]
> Sent: 07 July, 2003 22:46
> To: Stickler Patrick (NMP/Tampere)
> Cc: uri@w3.org; www-rdf-interest@w3.org
> Subject: 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.

I was simply taking issue with the word "hack" which typically
denotes a lack of quality or integrity of design, which I don't
see as applying to my proposal.

Perhaps in your lexicon "sufficient hack" == "elegant solution"? ;-)

> >>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).

Firstly, a new top level domain is not a cost burden. It's a
political and/or organizational hurdle, but once past that,
constitutes no added cost for those adopting this solution.

Secondly, as has been pointed out by several, including myself,
a top level domain is not actually necessary. Only a consistent
root domain. 

Surely you don't consider obtaining a new .org or other domain
a substantial cost burden.

> 
> > 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.

Nor do yours, with all due respect.

And no, you don't have to convince me of anything.

> > 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. 

What in my proposal suggests that there would be a single
server for all URN resolution?!

In fact, I particularly stated that there was a great deal
of flexibility in dealing with scalability issues. 

I think you should go back and re-read my original post, as
your comments seem to be motivated by some misunderstandings.

Each managing agency of a URN subdomain is free to further
partition and organize that namespace as they like, including
the specification of additional subdomains, each with their
own server, as a means of load balancing. 

And please don't tell me that a single URN subdomain agency
such as ISSN, or DOI, or the like could not set up an efficient
server cluster to handle any reasonably concievable load when 
all that service is doing is issuing redirects.

> Which is why 
>    I cite the purl idea working insofar as not too many people use 
> the service.

Your argument fails to serve as convincing evidence
that PURL would *not* work if it scaled up several
orders of magnitude.

Your argument equates to "X works with Y users,
therefore X will not work with Y^2 users" which
I don't find very persuasive.

> 
> > ???
> > 
> > Precisely how does it punish them?
> 
> Type 'slashdot effect' or 'google cluster architecture' into a 
> search engine.

Sorry. No. I see now where our communication may be breaking down.

The above referenced problems are due to a single point of service.

Yet what I am proposing provides for (theoretically) an infinite
number of servers, organized independently by each level of the 
management hierarchy, and is just as scalable as the web, because
it is just as flexible and distributable as DNS.

There is no single mother-of-all master server that is managing
all redirects for all HTTP-URNs in use. If you understood me 
as proposing one, then I ask that you go back and re-read my
proposal more carefully.

There are at least as many servers as there are HTTP-URN subdomains,
and likely far more than that, organized as subsubdomains under
each HTTP-URN subdomain, particularly for subschemes that
are very popular and have a large customer base.

If my proposal is not scalable, then neither is the web.

> >>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?

OK. It's clear you have misunderstood my proposal.

Insofar as what you misunderstood me to say, I fully agree, that would
be a pretty stupid design, and garunteed not to scale.

Though, since I was not proposing any such thing...

To clarify, consider a top level management domain .urn.org which 
is owned by the same organization responsible for registering urn:
subschemes. 

That top level management organization will probably have a server
located at urn.org which provides all kinds of useful information
about the organization and the process of getting a URN subdomain.

Each registered URN scheme subdomain will have their own server.
Thus each of

   ietf.urn.org
   oid.urn.org
   issn.urn.org
   nbn.urn.org
   pin.urn.org
   isbn.urn.org
   newml.urn.org
   oasis.urn.org
   ...
   etc.

would each be a different server, each constrained to the
management of each particular URN scheme.

Now, it may be that none of those servers actually are used
to mint URNs within those schemes. Rather, each URN subdomain
is further partitioned, in the interest of scalability, into
arbitrary segments:

   x001.issn.urn.org
   x002.issn.urn.org
   x003.issn.urn.org
   ...
   etc.

where each of the above might be managed by separate servers.

Then, URNs are minted according to whatever organizational
structure the URN agency employs:

   http://x287.issn.urn.org/...

Thus, each URN scheme agency is free to organize their own
server space as they see fit. 

Whether or not there is one single server or thousands
of servers is up to each level of the management hierarchy,
*exactly* as it is for web servers in general.

Again, if my proposal won't scale, then neither will the web.

(since we know the latter is not true...)

> > 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. 

I think you need to reassess that in light of your
apparent misunderstanding of what I was proposing.

In either case, managing organizations must manage mapping
information. Since they already deal with web servers, having
them learn/apply yet another technology (DDDS) seems far
more costly to me.

Not to mention the fact that all web clients would immediately
benefit from my proposed solution with zero change to any of
the actual web infrastructure, including client software,
operating system drivers, web servers, ...  *nothing* needs to
change to put my proposal into use.

Patrick

Received on Tuesday, 8 July 2003 03:37:19 UTC