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

> -----Original Message-----
> From: ext Michael Mealling [mailto:michael@neonym.net]
> Sent: 09 July, 2003 16:51
> To: Stickler Patrick (NMP/Tampere)
> Cc: hardie@qualcomm.com; uri@w3.org
> Subject: 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.

I disagree.

It comes down to intension versus denotation.

Different URIs do, in fact, have different intensions. And the
statements made about a given resource using oen URI versus another
reflect the intension of the URI.

But two URIs can certainly have the same denotation.

Two URIs can both denote the city of Paris, even if the
representations provided, and the intensions expressed
in statements using one or the other URI differ.
 
> 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.

That is completely beside the point.

Or, perhaps, that is the very point. The only real difference
between http: and https: URI variants is in the nature of
the interaction with those representations, such that one
is more secure than the other. Not in any difference in
denotation.

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

I stress again: Insofar as denotation is concerned...

(qualifying clauses are very important to understanding the
full meaning of an English sentence...)

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

Precisely how does it violate 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.

If, for you, resource = intension, then I agree. But I'm talking
here about denotations of URIs, not intensions of URIs.

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

And I keep waiting for specific references or examples
as to its insufficiency.

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

No. I've already clarified that
I'm not talking about a single server.

Perhaps you have another fault to point out?

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

And yet, the only real-world applications I've seen argued for
the use of URNs was to make representations of resources available
using minimally mnemmonic identifiers.

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

I'll have a look at that. Feel free to suggest any particular
pointers.

> Do you think we rejected HTTP due to some inherent 'not invented here'
> syndrome? 

Certainly not. In the many years that I've been following the
developments relating to URNs and DDDS, the only arguments that
have repeated stood out is that http: URIs aren't acceptable
because (a) server names change and (b) server names typically
contain too much mnemmonic/trademark related content.

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

While a PURL approach with an official, persistent root domain
certainly does not have the capabilities of the more generalized
DDDS approach, I wonder whether, given the removal of the two
objections mentioned immediately above, is nevertheless sufficient
for nearly all real-world use cases of URNs.

Any pointers to documents or other materials summarizing the
rational of your rejection of HTTP, apart from those two above
objections, are appreciated.

Regards,

Patrick

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

Received on Thursday, 10 July 2003 08:52:48 UTC