W3C home > Mailing lists > Public > uri@w3.org > July 2003

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

From: <hardie@qualcomm.com>
Date: Mon, 7 Jul 2003 09:32:17 -0700
Message-Id: <p06001202bb2f4cde8fd8@[129.46.227.161]>
To: <Patrick.Stickler@nokia.com>, <uri@w3.org>

Hi,
	I took the www-rdf-interest group off the
reply list since I don't know the list charter and can't tell
whether my reply is relevant.

	1) There is zero reason for a new TLD for
this; if you want this hack, you could do it at urn.iana.org
with no change to the rest of the hack.

	2) This hack runs into the typical confusion
between the infrastructure required for retrieval and
for identification.  As a trivial example, note that
http://www.ietf.org/ and https://www.ietf.org/
are both commonly used retrieval mechanisms for
the same resource, but they are not the same identifier.  The
same would be true of https://issn.urn.iana.org/1560-1560;
if it redirects to the same as http://issn.urn.iana.org/1560-1560
is it the same or isn't it? There are quite a few non-trivial examples  of
problems re-using DNS records that already have a purpose in mapping
to IP address records; the potential for getting both AAAA and A 
records back is one
example.   When you are trying to layer retrieval and identification over
each other using the existing redirection services, you are pretty
much bound to get confusion.  This is avoidable in small scale services
with well-known conventions, but it gets a lot harder as it scales.

	3) If you really believe this isn't a hack, but a solution
that would work and scale to the size of the Internet, writing
it up as an ID with a full specification is a good first step.
This is pretty well-trodden ground, and getting folks to see
how your proposal avoids the common pitfalls requires a
full specification to be convincing.

		regards,
			Ted Hardie


At 10:33 AM +0300 7/7/03, <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
Received on Monday, 7 July 2003 12:32:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:31 GMT