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

I rather think these are the wrong forums in which to promote a new top 
level domain.  And given the state of Internet politics, I don't expect to 
see this happen anytime soon.

#g
--

At 10:33 07/07/03 +0300, Patrick.Stickler@nokia.com wrote:


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

-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E

Received on Monday, 7 July 2003 07:36:43 UTC