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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 07 January 2020 16:16 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A5712011B; Tue, 7 Jan 2020 08:16:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awvczxoQv_1e; Tue, 7 Jan 2020 08:16:29 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E27512025D; Tue, 7 Jan 2020 08:15:43 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7B32B3897A; Tue, 7 Jan 2020 11:15:22 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9864060A; Tue, 7 Jan 2020 11:15:42 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Phillip Hallam-Baker <ietf@hallambaker.com>
cc: John C Klensin <john-ietf@jck.com>, "General Area Review Team (gen-art@ietf.org)" <art@ietf.org>, urn@ietf.org, The IESG <iesg@ietf.org>, IETF Discussion Mailing List <ietf@ietf.org>
In-Reply-To: <CAMm+Lwi5tWUNK5nO4d8qoum03fV-1bchfP_Qu3ktANgRDd-RVg@mail.gmail.com>
References: <87E116C31DAF1434C3C3937F@PSB> <CAMm+Lwi5tWUNK5nO4d8qoum03fV-1bchfP_Qu3ktANgRDd-RVg@mail.gmail.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Tue, 07 Jan 2020 11:15:42 -0500
Message-ID: <29803.1578413742@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/VUx-8-ltjX2PhIGkiWs6uE0wEsU>
Subject: Re: [urn] [art] URNs and Last Call: <draft-nottingham-rfc7320bis-02.txt> (URI Design and Ownership) to Best Current Practice
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jan 2020 16:16:42 -0000

Phillip Hallam-Baker <ietf@hallambaker.com> 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.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-