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

> -----Original Message-----
> From: ext hardie@qualcomm.com [mailto:hardie@qualcomm.com]
> Sent: 07 July, 2003 19:32
> To: Stickler Patrick (NMP/Tampere); uri@w3.org
> Subject: Re: Proposal: new top level domain '.urn' alleviates all need
> for urn: URIs
> 
> 
> 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.

I agree. That occurred to me after my original post, and after
some prodding from Graham Klyne.

In fact, the mapping from urn: URI to HTTP-URN could be
generalized to

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

where

  X is the URN subscheme name
  Y is the URN subscheme specific part
  D is the root domain for HTTP-URN management

so, whether D equates to .urn, .urn.org, .urn.iana.org, etc.
is a secondary issue, where the guideline "shorter is better"
should nevertheless be taken to heart.

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

I don't see there being any confusion. Let's take an example:

   http://issn.urn.iana.org/1560-1560 denotes some resource

That resource is owned/managed by Example Inc. and is synonymously
denoted by the URI

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

Now, both of those URIs denote the same thing. I.e.

   <http://issn.urn.iana.org/1560-1560> 
      owl:sameAs
         <http://example.com/issn/1560-1560>

Either of those URIs could be used to obtain representations or
(ideally) descriptions of the resource denoted. And, in fact,
the resolution of both URIs, not just the first, might involve
redirection.

But nowhere is there any ambiguity regarding the denotation of
the URIs.

As for https: URIs, well https: is an oddball URI scheme that
has inherent in it (IMO) an equivalence assertion. I.e. for
any two URIs

   http://X
and
   https://X

the following can be presumed

   <http://X> owl:sameAs <https://X>

and the extra 's' in the URI scheme is simply a processing 
instruction to the server, not a semantically significant
component of the lexical form of the URI.

http: and https: URIs are in free variation with one another,
with no change to meaning.

Ultimately, when resolving an HTTP-URN to a representation,
a server somewhere will return an entity in
its response corresponding to a representation of the
resource denoted by the URI provided in the original
request; and if it is a well behavied server, will specify
in the response a URI denoting the representation itself,
if it is an entity distinct from that denoted by the
original URI.

I see no problems with ambiguity here. 

If you still think I've missed something, please try again.

> 	3) If you really believe this isn't a hack, but 
a solution
> that would work and scale to the size of the Internet, 

Firstly, it does not have to scale to the size of the internet,
only to the scale that managed URNs are deployed.

Secondly, this approach can be done now, with no particular
steps taken whatsoever by any of the central organizations
managing internet and web standards. I could found a company
today, grab some domain such as .urn.org and begin charging
money for subdomains such as issn.urn.org and also sell
the software needed to manage the namespaces and redirection
mappings. This requires no action on the part of the IETF,
IANA, W3C, etc.

The only part of my proposal that concerns organizations
such as IETF, IANA, W3C, etc. is the present, existing
management and control of urn: subschemes -- presuming that
it is better to have that same organization manage any
subdomain registrations of a .urn(.*) root domain rather
than creating a competing organization.

Thirdly, I see the scalability complexity of my proposal
and that of DDDS to be roughly the same, and both define
machinery that can be employed to deal with scalability
and non-centralized management -- the key difference being
that the machinery used by my proposal is already in place.
 
> writing
> it up as an ID with a full specification is a good first step.

Well, I think putting it on the table for informal discussion
is a good first step.

An ID is certainly an expected subsequent 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.

I keep puzzling about what those common pitfalls might be.

You mentioned a couple potentials above, but I'm not 
convinced of those.

This really is a proposal for a change in management
practice, not a change in web architecture. The technology
and solutions outlined are already widely deployed. So
forgive me for being rather skeptical about claims that
this approach is technically flawed. I see the only real
threat to its adoption being politics, not technology.

Cheers,

Patrick

 
> 		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 Tuesday, 8 July 2003 02:52:46 UTC