- From: Graham Klyne <GK@ninebynine.org>
- Date: Mon, 07 Jul 2003 12:18:25 +0100
- To: <Patrick.Stickler@nokia.com>, <uri@w3.org>
- Cc: <www-rdf-interest@w3.org>
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