Re: [urn] [art] URNs and Last Call: <draft-nottingham-rfc7320bis-02.txt> (URI Design and Ownership) to Best Current Practice

Phillip Hallam-Baker <> Tue, 07 January 2020 19:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BAA81200FD; Tue, 7 Jan 2020 11:53:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VxQRab6X6ZKR; Tue, 7 Jan 2020 11:53:53 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2E27D1200B3; Tue, 7 Jan 2020 11:53:53 -0800 (PST)
Received: by with SMTP id p67so498786oib.13; Tue, 07 Jan 2020 11:53:53 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ibvo7OmV9+zNwjb1AHdIT1vKqOZQ/LoeRVExlz19n8A=; b=m1eKD0DimMFXqj4PPYNigVO2KLLhsOBcW3N5+HschzBt+d9XjpTKCZ/Pinkv2KhwI6 /729Vyj9Ypp8nKx39lxkkD7U/6zh2JzQMBRHfbhi1lQotksNohLdUoc7K88OuYM1pfV0 i/PcO0X9FqdyPGze2jdPj9SbTRie5igCxN5dikPihXBTVFxhXQXdkgTY9SW7cUZQeqs6 5VLE2ipuU/9W/b3KGvHBNje5cb4P27TSO7e0iXGJ32U8HsMcv73sgPPcgc+vGKgVclc6 lPDRz9EhRrdsL+2vGi21eDGUIlye82PLhiQi45GD/+YzRhhz2IUb5Vw8yWrGrD5nvXAg qz7Q==
X-Gm-Message-State: APjAAAVLkUtD/oWlIfGNatz89g9iIJD+2cQYUSWADx6ep60Oae18a7w9 1phCnNwm4cpfsmYDFX9ioIKNriKUYWtF/vQFNKzbQ38td/U=
X-Google-Smtp-Source: APXvYqxvdqhMzuAeUM4BwZOAH1pf43T/A6RUak2okFVC3rLZ+5z6tKjB5FKIzUkgspI3SuwGkc7UO64MnMwpg2rrT1s=
X-Received: by 2002:a54:4f04:: with SMTP id e4mr48512oiy.111.1578426832209; Tue, 07 Jan 2020 11:53:52 -0800 (PST)
MIME-Version: 1.0
References: <87E116C31DAF1434C3C3937F@PSB> <> <29803.1578413742@localhost>
In-Reply-To: <29803.1578413742@localhost>
From: Phillip Hallam-Baker <>
Date: Tue, 7 Jan 2020 14:53:43 -0500
Message-ID: <>
To: Michael Richardson <>
Cc: John C Klensin <>, "General Area Review Team (" <>,, The IESG <>, IETF Discussion Mailing List <>
Content-Type: multipart/alternative; boundary="000000000000a3494a059b922212"
Archived-At: <>
Subject: Re: [urn] [art] URNs and Last Call: <draft-nottingham-rfc7320bis-02.txt> (URI Design and Ownership) to Best Current Practice
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Revisions to URN RFCs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Jan 2020 19:53:55 -0000

On Tue, Jan 7, 2020 at 12:48 PM Barry Leiba <>

> For the other part of the issue, I'm not fully in agreement with
> Phillip and Michael, in that I do think there's a useful distinction
> between a URI that names something without specifying how to locate
> it... and one that is a locator.  There is, for example, a fundamental
> difference between, say, "http:" and "ni:" (see RFC 6920).

That is precisely what I was talking about when I said that ni: is
indexical. But that is no longer an essential distinction either.

We can distinguish names that are under IANA authority (DNS, IP) from those
that are not. But that is the limit of it.

Given that it was announced today that SHA-1 was broken, lets take another
look at a SIN:

That is a valid email address. It can be routed on the Internet (not the
best privacy choice but possible). But it is a name that can be bound to a
security policy.

So if  mb2gk-6duf5-ygyyl-jny5e-rwshz is the UDF (SHA-2-512) of Alice's
OpenPGP encryption key. We have an implicit semantic here: Encrypt all mail
sent to this address with the key that has fingerprint

The reason that I have hammered on the fact that the name/locator
distinction being bogus is precisely because the obsession with defining a
distinction where there is NO difference has caused the neglect of a
situation where there is a very real and important one.

A Strong Internet Name allows ANY URI with a DNS component to be turned

On Tue, Jan 7, 2020 at 11:15 AM Michael Richardson <>

> Phillip Hallam-Baker <> wrote:
>     > I remain of the view that the URN/URL distinction is unhelpful
> because it is
>     > meaningless. There are no sharp boundaries between categories of
> identifier
>     > as the distinction supposes.
>     > Before making this argument in more detail, I will make a plea for
> respect. I
>     > find that the biggest obstacle to getting clarity on naming is that
> when
>     > faced with an analysis that contradicts deeply held beliefs, the
> usual
>     > response is to tell people to 'do some research' or 'understand the
> issues'.
>     > The URN/URI distinction does not in fact represent an essential
> distinction
>     > between types identifiers as claimed. It describes a difference in
> source of
>     > authority at best, not an essential property.
> I agree with you.
> I think that we might have found new ways in which they are meaningfully
> distinct had to a uquitious way to resolve the more abstract URNs.
> That didn't happen, and I don't imagine that it is coming in the way
> envisioned.

HTTPs are names but they are a name that embodies a (fairly) unambiguous
means of location.

Having had the misfortune to engage in discussion with acolytes of a
prominent opponent of post-modernism, I have been writing a defense of
postmodernism today. One of the chief arguments made by the postmodernists
is that perfect knowledge is an illusion. And I think that is a profound
observation that is essential to understanding why the original concept of
URNs and for that matter most registration schemes are doomed to fail.

The Web succeeded because of 404 Not Found. The links are scruffy. And that
is fine if you are OK with the idea that knowledge can be scruffy, that it
will never be perfect. And that is why the Web came out of CERN because
(good) scientists understand that there is no absolute knowledge and that
what we are arriving at is a better approximation to the truth, not the
truth itself.

There have been plenty of people making that type of argument since ancient
times. But until the mid 80s, most scientists had a very rigid epistemology
that was essentially Victorian in its outlook. Scientists were serious
people who were finding out profound and universal truths and we had all be
very very careful not to make mistakes because that 'would be bad'.

I would encourage people to take a look at what research scientists in
their 20s and 30s are saying about their approach to science. They are
utterly rejecting that view.

What politicians now call 'Western values' and demand other countries
observe is a modern construct that is fifty years (racial tolerance) old at
most. In some areas, what is now the fixed consensus is less than a decade
old (evolve already). The reason we have the nonsense of .com, .org, .net
etc is because DNS was designed by people who had an essentially Victorian
view of epistemology in which taxonomy represents essential qualities.
(Whether the same is true of the extension TLDs I will leave aside)

The reason I and others received (and continue to receive from some) the
patronizing responses we do (do some research you ignorant baboon! you
don't understand) is that we have profoundly different and fundamentally
incompatible epistemologies and some people regard mine as heresy. Both are
capable of self examination. But mine is capable of examining theirs, they
can only reject mine. So its like me trying to explain complex numbers to
someone who insists that you can't take the square root of a negative
number and can't get past that.

The route out of formal methods to PoMo is that to solve the problems we
faced in the 1980s in formal methods, it was necessary to apply
meta-mathematics and understand the limitations of logic. And once you do
that you are in Post Modernism.

So the URN notion that we must carefully decide how to resolve before we
defined schemes was wrong. It was and is much more important to have a
catalog that is as *complete *as possible than for the entries to be

Resolution of many types of name is inherently ambiguous because the
context varies. We cannot resolve a barcode on a physical object like a can
of beans. But we can ask for information on the can of beans and we can
order an instance of the can of beans for delivery. And both forms of
'location' are going to be subjective and depend on the context in which
they are attempted.