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: 08 July, 2003 20:33
> To: Stickler Patrick (NMP/Tampere); uri@w3.org
> Subject: RE: Proposal: new top level domain '.urn' alleviates all need
> for urn: URIs
> 
> 
> At 9:52 AM +0300 7/8/03, <Patrick.Stickler@nokia.com> wrote:
> >
> >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>
> 
> No, it really cannot.  I know of several cases where they
> point to different resources, and many cases where one points
> to a resource and the other does not.  

Perhaps actually different representations, rather than
different resources.

I.e. both URIs denote the same resource, but there may
be a different set of representations accessible via
one than the other.

> Further, they
> are clearly functionally different as protocol elements; the
> difference between them makes a fundamental assertion
> about how to engage in protocol processing.

Er. Right. Like I said, the 's' in https: is a processing
instruction that results in different behavior from the server.

Insofar as denotation is concerned, that 's' is semantically
(though not lexically) transparent.

Insofar as resolution of that URI by an HTTP server, that 's'
has semantics relevant to the resolution protocol, just
as most of the other structural components of a URI do.

One can denote the same resource with an http: URI, an
https: URI, a urn: URI, an ftp: URN, etc. and insofar
as the denotation is concerned, those URIs are opaque.

However, http: and https: URIs have IMO a special relation
in that whereas other lexical distinctions between two
URIs might correspond to a difference in denotation, alternation
between the http: and https: schemes for the otherwise
lexically equivalent URIs cannot and does not result
in any difference in denotation.

Any URI https://X denotes the very same resource as
the URI http://X, even if there may be representations
that might be accessible via https://X that are not
accessible via http://X, or visa versa.

In that way, https: is a pretty odd fish.

> >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.
> 
> You seem to be working from the assumption that if two
> identifiers resolve to the same resource at the end of
> this processing, they were the same identifier.  

No. I don't assert that. Not for arbitrary pairs of URIs.

Only for pairs of URIs which differ only in the alternation
of the http: and https: schemes.

> That's
> not true, and it has been discussed to death.  If that's
> not what you mean, I don't think you're being clear
> (and, again, I think the way to be clear here is to
> write a draft specifying the mechanisms in full)

Well, I can try to be clearer. It may also be the case that
you are not reading my posts carefully enough.


> >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. T
> 
> Sure, and if you want to found one,  go ahead.  You'll need to build
> the trust of your customers that your resolution mechanisms
> work better than and will return the same answers as the
> mechanisms already specified, but that's up to you and
> your marketing department.

I agree. My point was simply that there is no *technical*
obsticle or flaw in my proposal, insofar as a common base
domain for the management of the URN namespace is concerned.

It's simply political/practical/organizational/beaurocratic.

For the sake of assurred perpetuity of URNs, it would be best
all around if the base domain were owned/managed by the same
organization now managing registration of urn: subschemes,
and that the registration of subdomains would follow the
same process as for urn: subschemes, with no cost incurred,
no chance of losing ownership of the subdomain due to e.g.
failed payment, etc. and no risk of reuse of a subdomain
if a subdomain owner ceases to function/exist.

> >>  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.
> 
> My informal response is "this has no obvious advantages over the
> DDDS proposal, 

Eh? You don't consider the possiblity of immediate access
to representations using existing HTTP machinery an advantage?!

> has strong flavors of things that have
> been discussed and rejected, 

You appear to be reading those things into my posts (and
I'm not sure an ID would alleviate that problem. It might.

> and isn't well specified."
>
> 
> >An ID is certainly an expected subsequent step.
> 
> That would help, thanks.


To be honest, given the simplicity of the idea, I'm not
sure how its specification could be expanded upon to
any great extent.

Granted, I've not taken a historical tour and related it
to every possible alternative...

I do, though, plan to work up an ID in the coming weeks.

Patrick

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

Received on Wednesday, 9 July 2003 05:03:38 UTC