Re: [urn] URN:META namespace registration request (Dale R. Worley) Sat, 08 February 2020 04:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 523D312003F for <>; Fri, 7 Feb 2020 20:04:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.984
X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ie5xcZuw45Tg for <>; Fri, 7 Feb 2020 20:04:15 -0800 (PST)
Received: from ( [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1F5DE12001E for <>; Fri, 7 Feb 2020 20:04:14 -0800 (PST)
Received: from ([]) by with ESMTP id 0HGEjvgBQtdfM0HLpj342j; Sat, 08 Feb 2020 04:04:13 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20180828_2048; t=1581134653; bh=PWginPvdeWc7b0Ywz77H1q1xhd9Ct+ATTsAbPeCuCqE=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=b3uN4DlJ2spO4l5LEt5zqXI/p/TeEJm74OhSrwLk1uNqvCYy7MiSIkZgVaecQQqlY lTFhKKwpZ6JPj7CKdRYnSMlklLH/hQ+2mI5mnBMN1ChZP0SKZy6jLepIB3o/4WwiNM 93nCF35hOyhzemrh08HpdIEdr6lCD0Ox6Oefc2q1bAJp1O/jWoQYV9p10cazLFpOYD SZXzCKmo1RKHsguXzLoKu+ZlT7kpR4K7WzYGXQtRNxzXmLJLdIdLQxP+p15hAnfD8q BhXrVJMMK3mSbZvg6+mh6nx+2RXbwQQEAlqWG4cgPII0zsZzwWj+FPApg9C2qpVV6U Bfkv2s2vakJJg==
Received: from ([IPv6:2601:192:4600:c190:222:fbff:fe91:d396]) by with ESMTPA id 0HLmjwq9gfW050HLnjXpyb; Sat, 08 Feb 2020 04:04:12 +0000
X-Xfinity-VMeta: sc=-100.00;st=legit
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id 018449gx030064; Fri, 7 Feb 2020 23:04:09 -0500
Received: (from worley@localhost) by (8.14.7/8.14.7/Submit) id 0184473X030046; Fri, 7 Feb 2020 23:04:07 -0500
X-Authentication-Warning: worley set sender to using -f
From: (Dale R. Worley)
To: "Hakala\, Juha E" <>
In-Reply-To: <> (
Sender: (Dale R. Worley)
Date: Fri, 07 Feb 2020 23:04:07 -0500
Message-ID: <>
Archived-At: <>
Subject: Re: [urn] URN:META namespace registration request
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: Sat, 08 Feb 2020 04:04:17 -0000

Comments on URN:META registration request, version 1, 2020-02-07

This document seems to be an outline or advocacy proposal for the use
of URNs.  And it seems to be directed entirely to the library
bibliographic community.  As such, it doesn't seem to be designed to
be understandable by the IETF community.  And it isn't organized as a
namespace registration but rather as an exposition or advocacy.  It
really needs to be revised carefully.

Some specific issues are:

The term "metadata" is used without definition.  If I understand
correctly, this is used to mean "metadata in library bibliographic
records", which is a small subset of the information in the world
described as "metadata".  It would help if this was clarified.

The phrase "cool URI" is used a number of times.  Is this a technical
term or some sort of commentary?

"PURL" seems to be a technical reference to a specific system.  It
would help if this was properly footnoted.

"DCMI community" is used without definition.

The ABNF rule for meta-nss has a component nbn-string, which is not
defined.  It appears to be intended to be meta-string (or vice-versa).

There is this text:

    However, URNs should replace "cool" URIs, since using them as
    identifiers for metadata elements is not ideal. There are several
    reasons for this:

    1. It is not possible to provide links to alternative versions
    (e.g. human readable / machine readable) versions of element
    descriptions with one URL.

However, given that "URN" and "URL" are disjoint, and "URL" is a
strict subset of "URI", it's difficult to figure out what this might
mean, as e.g. it seems to imply that "cool URIs" are all URLs, and
that somehow URNs would replace the cool URIs as URLs...

There is this text:

    Rules for lexical equivalence:


However, defining lexical equivalance is a requirement.  And indeed,
the ABNF is annotated with rules for lexical equivalence, "; The
entire prefix is case insensitive."

There is a long discussion of resolution processes without giving
anywhere near enough information that one could write a resolver
client.  I suspect that the document is implicitly referring to a
style of resolution system that is common in the library bibliographic
world.  But if this document is truly to define resolution for a
namespace, it has to actually define it.

The format-code part of the URN is actually a sub-namespace
identifier, and it references a particular metadata system which is
maintained by a particular maintenance organization.  The text says
"As assigned by the respective format maintenance agency", but that
implies that codes are self-assigned (a recipe for chaos), whereas the
text later explains "New codes are added by the National Library of
Finland on request."