Re: [urn] [IANA #1275238] URN:NAN registration request Fri, 23 June 2023 20:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 86A08C169528 for <>; Fri, 23 Jun 2023 13:02:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.682
X-Spam-Status: No, score=-1.682 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_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_SOFTFAIL=0.665, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 eIC3riLTdwx1 for <>; Fri, 23 Jun 2023 13:02:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 00020C169527 for <>; Fri, 23 Jun 2023 13:02:12 -0700 (PDT)
Received: from ([]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by with ESMTP id CmuMqlEsmA0yXCmx1qjFR2; Fri, 23 Jun 2023 20:00:11 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20211018a; t=1687550411; bh=NN1zPDlgaJkEquI1Gf/tVhGErjJTZwAK/AZ1AC3czVg=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID:Xfinity-Spam-Result; b=Sq6A1J1dsLb25O+VjaOitBk2I2NqOKZYxOOXeyON2JORj7ZvrQ5T685lQTCGbFFgP j1fttrA2WxtqePQPTZLPKz5OmIpCPBPGAGfV3Xy77ESVgulTAjEiIrl9TxcqX5AUKr bksV+RRXXjJ9sBFdafdoyh6O/gjadVqC1HpPzCwuQU0DM/DXk/tS0xQy69aX7mjUTL 6HIx3hJ31XLUivilUB+XD1rCBOiFxEOuzYNrrwBkg6bisgH+ocQvsAqzN3BKjsS/mo DFeV/Ogjw1xZxDwIYriClxPNPOwGanxD9RruwG2IZFDOU1jGJTYC2PTAvsucGqun5x P6QFaDYmK8lWg==
Received: from ([IPv6:2601:192:4a00:430::9e5e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by with ESMTPA id CmwyqYcAwS2JUCmwzqcatJ; Fri, 23 Jun 2023 20:00:10 +0000
X-Xfinity-VMeta: sc=0.00;st=legit
Received: from (localhost []) by (8.16.1/8.16.1) with ESMTPS id 35NK07EZ015042 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 23 Jun 2023 16:00:07 -0400
Received: (from worley@localhost) by (8.16.1/8.16.1/Submit) id 35NK06F3015039; Fri, 23 Jun 2023 16:00:06 -0400
X-Authentication-Warning: worley set sender to using -f
In-Reply-To: <> (
Date: Fri, 23 Jun 2023 16:00:06 -0400
Message-ID: <>
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: Fri, 23 Jun 2023 20:02:18 -0000

Overall, I approve of this application.  There are a few details that I
think could be improved.

1. There are two uses of "SHOULD" in the text:

    A colon SHOULD be used within the prefix only as a delimiting
    character between the ISO 3166-1 country code and sub-namespace
    code(s), which splits the national namespace into smaller parts.

    A hyphen SHOULD be used as the delimiting character between the
    prefix and the NAN string.  Within the NAN string, a hyphen MAY be
    used for separating different sections of the identifier from one

However, both of these statements are implied by the BNF, and the BNF is
implicitly "MUST", so the meaning is better captured by changing

2. This statement is correct in its general meaning but I think the
wording is not quite correct:

    URN:NAN syntax is equivalent to the URN:NBN syntax.

"equivalent to" usually means that the two sets of BNF define exactly
the same thing.  "parallel to" or "similar to" might be better.

3. In regard to case handling, the following statements are made:

    prefix      = iso-cc *( ":" subspc )
                ; The entire prefix is case insensitive.

    The structure (if any) of the NAN_string is determined by the
    authority for the prefix. Whereas the prefix is regarded as case
    insensitive, NAN strings can be case sensitive at the preference of
    the assigning authority; parsers therefore MUST treat these as case
    sensitive, and any case mapping needed to introduce case
    insensitivity is the responsibility of the relevant resolution

    Note that because case mapping for ASCII letters is completely
    reversible and does not lose information, the case used in
    case-insensitive matching is a local matter.  Implementations can
    convert to lower or upper case as they see fit; they only need to do
    it consistently.

The first two statements are completely clear and appear to be exactly
correct.  But I think the third statement is inconsistent with the first
two.  And also, case mapping, in the form of mapping letters of both
cases to one case, *does* lose information.  I suspect that the third
statement is left over from an early version of the NBN template and
should be omitted.

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