Re: [urn] gbs Name space identifier (Dale R. Worley) Thu, 17 October 2019 01:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8CD8B1201CE for <>; Wed, 16 Oct 2019 18:59:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.684
X-Spam-Status: No, score=-1.684 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, 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 Ib-OrfpLan-W for <>; Wed, 16 Oct 2019 18:59:37 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0FA7912011B for <>; Wed, 16 Oct 2019 18:59:36 -0700 (PDT)
Received: from ([]) by with ESMTP id KtXLiWb7JkltDKv4iivFhg; Thu, 17 Oct 2019 01:59:36 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20180828_2048; t=1571277576; bh=vTtkUXreaA9PJfpJufSFLB0xzeCa/nNKk23qmSQT88Y=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=QfFz46DGLMWaQrWXsuoKfcUSypX8NRXLjyMjo81PXnHLqGhVgx8OdN/Yqijw5iVpt jTEu9LkrnrIhtHQSIsx76d8PilaPPJy7eghlY62Z9DqgxRUzJPW19Z+RauC8GlU+LS duBuyrxc68y4AIWyA6ei4b1a4PL5tyXx6JcCQaoeO7FIimiOY6MBRg/WNP484L2n0H 6NB69nlDuYgGfkn7ypuDReiZAO9jd7aJ9IjAJvM7/QoXXvrphjEIo1+leZyRdzmna3 B3NBs3OY/7SXyeSdUpXWGKb+N0B7EN4wKf6qdpKzgxk4oqR7Jna+mbFT77Om/Hz2L1 JtwagfPO964Zg==
Received: from ([IPv6:2601:192:4600:1e00:222:fbff:fe91:d396]) by with ESMTPA id Kv4fictS8anXQKv4gi2f7S; Thu, 17 Oct 2019 01:59:35 +0000
X-Xfinity-VMeta: sc=-100;st=legit
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id x9H1xXf8013651; Wed, 16 Oct 2019 21:59:33 -0400
Received: (from worley@localhost) by (8.14.7/8.14.7/Submit) id x9H1xWRM013648; Wed, 16 Oct 2019 21:59:32 -0400
X-Authentication-Warning: worley set sender to using -f
From: (Dale R. Worley)
To: Philip R Brenan <>
In-Reply-To: <> (
Sender: (Dale R. Worley)
Date: Wed, 16 Oct 2019 21:59:32 -0400
Message-ID: <>
Archived-At: <>
Subject: Re: [urn] gbs Name space identifier
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: Thu, 17 Oct 2019 01:59:39 -0000

I see the new version as an enormous improvement.  One aspect that
you've made clear is that for any given <B> value, there can be only one
<G> value (although you cannot compute <G> from <B> unless you happen to
have a copy of the topic to hand).

As has been noted, URNs are *names* while URLs are *locators*, and URNs
do not require a resolution process to locate the named resource.

However, I think there are some aspects of the exposition that should be

Under "Resolution", it says:

    Equivalence is determined by comparing (ignoring case) the <B> components
    of the two topics to be compared.  If they are equal the two topics are
    considered to be equal. Otherwise they are considered to be unequal even if
    the underlying content is in fact identical. The characteristics of the MD5
    sum ensure that only a small number of topics will be unnecessarily
    duplicated as a result of such false positive equivalences.

I do not see how "the underlying content is in fact identical" without
generating the same <G> and <B>.  I suspect you mean that there can be
two topics that have no *meaningful* difference but nonetheless have
different <B> or <G>.

Under "Security and Privacy", it says:

   The validity of the URN can be checked as follows:

However, these actions can only be done if one possesses not just the
URN but also the content it refers to.  Usually "validity checking"
names a procedure that only requires the URN as input.  So it would help
if you expanded this sentence.  Perhaps, "The validity of the URN for a
topic can be checked as follows:"

Under "Inter-operability", it says:

   The case of the letters chosen is immaterial and can be safely ignored in
   all computations on the proposed URN as only the <B> component is used for

The case of letters can be ignored for comparing URNs, but when copying
or transmitting URNs, case has to be preserved, because only lower-case
letters are valid in the <B> part of the URN, and the case of the
letters in the <G> part must match that of the text from which it was
derived -- so if you send the URN to another process, you have to get
the case right.  So you want to narrow this statement.  Perhaps, "For
many computations, the case of the letters in the URN is immaterial and
can be safely ignored..."