Re: [urn] [IANA #1275238] URN:NAN registration request

John C Klensin <> Sat, 24 June 2023 00:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D5A02C151547 for <>; Fri, 23 Jun 2023 17:18:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 823Oe86aJ5X1 for <>; Fri, 23 Jun 2023 17:18:42 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 747EFC151527 for <>; Fri, 23 Jun 2023 17:18:41 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1qCqz0-000I0P-Ko; Fri, 23 Jun 2023 20:18:30 -0400
Date: Fri, 23 Jun 2023 20:18:07 -0400
From: John C Klensin <>
To: "Dale R. Worley" <>,
Message-ID: <10759F364A928EECB8146851@PSB>
In-Reply-To: <>
References: <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Subject: Re: [urn] [IANA #1275238] URN:NAN registration request
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Revisions to URN RFCs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 24 Jun 2023 00:18:46 -0000

--On Friday, June 23, 2023 16:00 -0400 "Dale R. Worley"
<> wrote:

> 4. John asks "What is the difference between an NBN and an
> NAN?"  It may be that librarians and archivists conceptualize
> a difference between the two sets of objects even if from an
> informatics point of view they are identical.  In any case,
> this is a matter for "Community Considerations".


That wasn't quite the question, so let me try again.

In general, if these things are resource identifiers, having two
identifier types that point to overlapping sets of resources is
a good way to cause confusion and other bad things.  That
doesn't mean it does not happen or that people cannot work
around it; we do so all the time.   However, it would seem
reasonable to expect that, if a new identifier type is to be
created and used where another one might exist that overlaps it,
the document should say that.  This is more than pointing out
the similarity in syntax, it is a suggestion that, if there are
going to be registration authorities for NBNs and NANs in the
same country, they could (SHOULD?) either be the same authority
and define where each is appropriate or should have a
sufficiently good relationship to definite categories and
boundaries.   No suggestion of a requirement, only that the spec
identify the issue and suggest that either avoiding overlaps or
being clear about differences in usage and application would be
a good idea.