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

I've been on vacation and blissfully ignoring this thread but this had
to be corrected....

On Wed, 2003-07-09 at 05:03, Patrick.Stickler@nokia.com wrote:
> 
> > -----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.

You are simply and flatly wrong here. By using the term 'resource' in
this context without clarification most will assume you are using the
term in its RFC 2396 sense. If you aren't then please say so since its a
very important distinction. If you have two URIs then you, by
definition, have two distinctly different Resources. You personally may
have some knowledge outside the web or within some particular
application of it that suggests these two Resources may be considered
equivalent according to that _other_ set of rules, but in so far as the
web and URIs are concerned, there really are two separate resources.

Especially since one is included in an SSL session that is signed by a
certificate. In today's world there are many communities that would
consider the unsigned one to be downright dangerous.

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

Wrong. Very very very wrong. In a security minded world it is most
definitely _NOT_ 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.

This last paragraph is so wrong as to be very dangerous to even post on
a official list for the discussion of URIs. Please clarify your
statement and reconcile it with RFC 2396 because on its face it violates
the standard.

> > >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 was never defined for 'https' and in practice is not the case. The
fact that access to one Resource is signed and one isn't means that no
matter the claims to the contrary, those are two different Resources.

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

Nope. We've read 'em carefully. You're not the first to suggest this
approach. It's been suggested at least three times going back to '92.

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

For your simplistic view of it, yes. But those that manage namespaces
with much wider deployments than your needs have already determined that
it is insufficient.

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

All you're doing is encoding the first rule of the DDDS for the URI
Resolution Application. And many have determined that there is a need to
go beyond it due to the fact that while the namespace may be unchanged,
the delegation rules may change over time. You are requiring that those
delegation rules only be expressible within one single (aggregate) HTTP
server, using the mechanisms found only within HTTP 1.1 and that simply
isn't workable.

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

Obviously not! If all anyone ever wanted to do with URNs was to make a
webpage available we could've done that a decade ago. We've already made
the determination many many times that the 'HTTP machinery' is
insufficient and actually the wrong model. There was even a proposal
many years ago called WIRE that attempted to use 30x redirects to do a
style of DDDS resolution that ended up being extremely convoluted. 
Do you think we rejected HTTP due to some inherent 'not invented here'
syndrome? Many of the folks involved with URNs were also involved with
the HTTP protocol development. We knew its limitations and rejected it
with many good reasons (most of which is the redirection model).

-MM


-MM

Received on Wednesday, 9 July 2003 09:52:30 UTC