Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)

[Phillip Hallam-Baker <[e-mail]>]

On Tue, Apr 15, 2014 at 9:40 PM, John C Klensin <[e-mail]> wrote:
> Actually, we don't disagree on anything but language and tactics.

I understood that. It is a specification so language is rather important.

I don't like the suggestion that the URI slot in the existing
protocols no longer includes URNs. But I am more than happy to toss
virtually the entire URI syntax out.

I am also rather suspicious of the idea that the difference between
URNs and URLs is that one is a name and the other is an index. Both
are both.

The real difference is that a URL must contains a DNS name and a URN
probably does not.

I don't believe in the 'persistent identifier' notion except for the
limited case involving SHA-256 and the like


> Specifically, the underlying problem is that there are semantic
> (and maybe syntax) constraints in RFC 3986 that make it, and its
> definition of "URI" unsuitable for some plausible and important
> class of identifiers (especially those, or a subset of them,
> whose "methods" are not tied to a particular retrieval or
> processing protocol (note that "SIP:" and "Mailto" are really no
> different from "http" in that regard).

Then replace RFC 3986 with one that says 'this is the URI syntax and
the semantics are defined by the scheme'.

I agree that tying http: to the HTTP protocol seems rather antiquated
now. Unfortunately NAPTR is also unhelpful.


> One can avoid recognizing that it is problem and try to force
> all identifiers into the Procrustean bed defined by 3986.  That
> isn't working well.  Its ultimate result is almost certain to be
> the development of object identifier standards away from the
> IETF and W3C and the need to adapt to that bed.   Indeed, that
> has already occurred; note the Handle System and the
> closely-related DOIs.
>
> Or one can recognize the problem and try to deal with it.  It
> seems to me that there are several ways that problem can be
> addressed, in more or less decreasing order of drasticness.
>
> (1) Discard RFC 3986 entirely, adopt the syntax convention you
> suggest (URI = label ':' anything), and leave each method
> definition to its own devices.

That would be my choice if it meant less argument.

> (2) Revise and replace 3986 in a way that removes all of the
> semantic definitions and constraints, leaving only the generic
> syntax.  I think that the result would be workable but, unlike
> the "every method defines its own syntax within 'anything'"
> model above, I can't prove it.  And, having explored that
> option, it turns out that removing the subtle semantic
> constraints from 3986 is not easy.  (See the thread in the URN
> mailing list for more about this.)

I would be fine with URLs being a syntactic subset of URIs.

Possibly we could define the method://<domain>/<stuff> and
method:<account>@<domain><stuff> patterns as the 'URL patterns and
declare all else to be a URN.


> (3) Redefine 3986 as applying only to URLs.  If you have a URI
> type (i.e., a method) and define it as a URL, you get to
> incorporate 3986 by reference and use its syntax and semantics
> without repeating them.  If you don't make that declaration, you
> are on your own, much as in (1) above.

OK

> (4) Come up with a new typology of URIs and then remove one or
> more of types from the scope of 3986.  Of course, as Larry's
> insistence that there is really no such things as a persistent
> identifier shows, coming up with such a typology and reaching
> agreement about it is not straightforward.

I don't think that the persistent identifier problem is insoluble. I
just haven't seen a convincing solution yet.

And in the real world any persistent identifier scheme has to cope
with copyright and kiddie porn takedown issues. I have an interesting
attack on the BitCoin blockchain. The attacker encrypts some kiddie
porn and dumps it into the blockchain. Then a little while later they
drop the key into the blockchain. Then when the chain is final they
call the cops, anyone with a bitcoin wallet is now carrying kiddie
porn.

Hows that for a DoS attack?


> (5) Remove URNs from the scope of 3986, leaving everything that
> doesn't use the pseudo-method "urn:" within the scope of 3986
> until and unless they demonstrate why they should be removed too.
>
> Approach (5) is the one suggested in the draft, not because I
> think it would be optimal in the best of all possible worlds,
> but because it appears to be something that the URNBIS WG can do
> and that would allow it to move forward.

Removing URNs from scope is not quite the same thing as saying that
they are not URIs.



> FWIW, the practical difference among some of those approaches is
> ultimately the old issue about the difference between
> inclusion-based and exclusion-based models.  RFC 3986
> effectively says "all identifiers are URIs and should (or must)
> conform to this model.  As soon as we get to "except those that
> don't", one can either identify those that don't or those that
> do.  Of course, if we were to shift to the much more generic
> model of (1), number of things that would need to be excluded
> would presumably be far fewer.

We split specs apart all the time. Just present this as a piecemeal
rollout of URI/2.0 doing the URN space now and the locators 'at a
later time'.

I don't want to deal with the locators at the moment because the only
way to fix locators properly is to make use of DNS in ways that people
tell me are currently impossible due to the infrastructure constraints
right up to the point when I suggest changes when they tell me that
the protocol is perfect[1].

And of course for those of us who built an Internet scale PKI twenty
years ago that is working pretty well all things considered[2], the
whole point of deploying DNSSEC was always to enable security policy
information to be deployed through the DNS. So I would not want to
open up discussion of URL/2.0 right now.


[1] Fortunately fixing the last mile issue of DNSSEC forces us to fix
the client-resolver loop and so does Edward Snowden.

[2] Folk who disagree need to sign the DNS root with a key longer than
RSA1024 before throwing stones at others.


-- 
Website: http://hallambaker.com/