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

Hi folks,

The following is a proposal for an alternative solution
meeting the goals of urn: URIs but with http: URIs so
that the full richness of the web architecture can be
exploited.

(sincerest apologies to all the folks who have worked long
 and hard on DDDS... perhaps now to no avail)

The combination of HTTP, PURLs, URIQA and a new top level 
domain make for a powerful solution that completely eliminates 
any need for the urn: URI scheme, or anything similar, as
well as provides an immediate migratory path for all urn:
schemes to http: URIs.

The long term integrity of URN schemes are dependent on the longevity
of the managing authority, though one would also hope that URNs
would remain valid long after a given managing authority has ceased
to exist and mint new URNs for that scheme.

The greatest argument for urn: URIs over http: URIs is that
(a) domain names do not last forever and and if the managing
authority changes, the function and meaning of URIs grounded
in that domain might change or become ambiguous; and 
(b) domain names reflect legal entities that one may not wish 
reflected in ones URI, if the denote resources that can be
transferred to new owners.

Well, this can be addressed with a very simple solution.

I propose that a new top level domain .urn should be defined,
managed by the same folks that manage the registration of urn:
subschemes, whereby for any URN subscheme urn:X: there would rather 
be issued a subdomain X.urn. Then, the managing authority of that
subdomain can mint http: URIs (URNs) based on that subdomain 
(regardless as to any services that might be offered by any web 
server operating in that subdomain). 

Thus rather than, e.g.

   urn:issn:1560-1560 

you'd have something like

   http://issn.urn/1560-1560

and the need for solutions such as DDDS disappears, since
HTTP now does the job quite nicely.

The managing authority for the ISSN URN scheme could then host
a server at http://issn.urn to provide access to representations
and descriptions of the resources, or simply information about
the owner of the URI -- or even nothing, which is no worse than
present urn: URIs now.

And since domains can be subdivided, and subpaths of URIs
redirected to entirely different servers, the managing authority
has a tremendous amount of flexibility in how it organizes its
namespace and services provided for accessing representations
and descriptions of the resources denoted by the URNs in question.

A given managing authority could simply maintain a PURL like
redirection service to customer-specific URIs, providing a 
consistent, opaque point of access to the resource that is
nevertheless managed by the resource owner.

E.g. if Example Inc. was issued ISSN 1560-1560, then an HTTP
request to

   http://issn.urn/1560-1560

could be automatically redirected to

   http://example.com/issn/1560-1560

providing exactly the functionality that DDDS promises, but using
the existing and proven web infrastructure.

If Example Inc. later transferred ownership of that resource to
e.g. Wombat Inc. then the redirection could be redefined to something
like

   http://issn.wombat.org/1560-1560

etc. and agents would continue to interact with the resource
in terms of its HTTP-URN transparently, with no manditory impact from the
change in ownership.

This solution also allows URIQA to be used for obtaining descriptions
of such HTTP-URN denoted resources in a standardized manner, since
in the same way as requests for representations would be redirected
to the customer-specific servers, likewise, requests for descriptions
would also be redirected.

Note that the creation of the .urn top level domain is based 
purely on practical considerations, not technical ones, as this
HTTP+PURL+URIQA approach will work equally well regardless of the
domain name. 

Creating the top level domain .urn also allows for every
URN subscheme now in existence to immediately be provided an HTTP
resolvable namespace which has a regular transformation from
the URN structure, allowing agents to work effectively with
legacy content containing urn: URIs. 

Thus, the mapping

   urn:X:Y -> http://X.urn/Y 

becomes a poor-man's DDDS.

And this approach likely has application to a number of other URI
schemes as well...

Simple. Eh?

Cheers,

Patrick

--
Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Monday, 7 July 2003 03:34:03 UTC