Re: [urn] gbs Name space identifier

Philip R Brenan <> Wed, 23 October 2019 17:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C949120C13 for <>; Wed, 23 Oct 2019 10:38:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PjgI6l2-C1Ok for <>; Wed, 23 Oct 2019 10:38:42 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1C54F120C72 for <>; Wed, 23 Oct 2019 10:38:42 -0700 (PDT)
Received: by with SMTP id f13so19693854ils.11 for <>; Wed, 23 Oct 2019 10:38:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5+vZwix6MbPCaYZodlRoITu9Ok86Yrh+zsmBuaORDWE=; b=vNtGRCJww5fbG++e2BlcQ4oDqg//6CsGGioZHGdsDxYpR2aq5ixUcbNQl5z/avLLi0 BgwTmBmsHRAshfNIeasy/m+BE8mHoxoyL+jp8iB0ozJcQQHWsYaWwZ2XsgtSSTjOq8Ba uEaZVyiq+7RPDOGYSaxd1WquUsbn/5eEJu/RSP+WUVbCD28TgEQ8De1uBdC0D5BagYfl 1nfvZwrbZBSQEQ1hYkvATJ5VUegVL6jI1pTw3SrmVaJ/FfeY8HbDI8DVwto+hiJSjGq9 1pR91Xi2CIMC7zs45ftvmqaWdC8mfvchNMhTNPDeMRIwEKOpUNx6JoS6ofNjf4GUoUDp kLOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5+vZwix6MbPCaYZodlRoITu9Ok86Yrh+zsmBuaORDWE=; b=P4c1eco7eMedVQpVVctlHlRHJ2sQNvszfQgBdvGq8No275IPOxMHUbN5ah9jIh4anW boBppcpohik6GGANrna0oIiSWurQCvqT36CawGD/pda6JmAhD6ZvBkoqd/KHo9Xu8gwZ fXqBuVfipWxc/Rp5lM3p9BQXZ9LPqBBKQHoB3XWdBSdQL3M7YhVj/Ubu+YFxShXu/xQK umSVefjDBwtI3gswKS765SBK8AbspAR1lNgpnW6ST9bm5CmFKPXi3YwIm2Ftm222DMRo bTYTueoTFm1kwSwoFmJNKt6gs/iFHdDtbpfSRSF8f/oykjlA41/O03oj2/niDQFqSqD0 B4Cg==
X-Gm-Message-State: APjAAAW0H3nSOUEtFfnDdL53zXgOGkdTqnn0S/W2o843UKkPqwBeBygX Tmjv18FYoc2g8T8a3Wv2q5bcLVI5meobDrDNUs67+6N/w8k=
X-Google-Smtp-Source: APXvYqw6djfLmUSIEmk1q1GjeObZxBs9uZ52yV0YfRSydNQc7uVuhyMAm2TZ9I8jRY7nUXBhMUGYgJbzCAHKbY9tfwE=
X-Received: by 2002:a92:865c:: with SMTP id g89mr22759121ild.291.1571852321309; Wed, 23 Oct 2019 10:38:41 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Philip R Brenan <>
Date: Wed, 23 Oct 2019 18:38:24 +0100
Message-ID: <>
To: "Dale R. Worley" <>
Cc: "Hakala, Juha E" <>,,
Content-Type: multipart/mixed; boundary="000000000000407be70595976355"
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: Wed, 23 Oct 2019 17:38:46 -0000

Hi *Dale*:

In the latest version (attached) I have adopted your suggestion that the
definition of the <B> component should not be restricted to lowercase.
the <B> component is defined, as you suggested, in a manner that makes it
insensitive. I have added a recommendation that the <B> component be
to humans in lowercase where possible as I believe that this makes the <B>
component less intimidating and thus more acceptable to people who are
on topics named using the proposed standard.  The relevant text now reads:

   <B> is the MD5 sum of the content being
   identified presented as a 32 character hexadecimal string represented by
   characters drawn from:


   with uppercase and lowercase versions of a character being considered

   Where possible, the <B> component should be presented to humans in
   as operational experience indicates that this makes it easier for humans
   both locate and ignore the <B> component and concentrate instead on the
   component, which is usually much easier for humans to remember, say out
   and thus reason about than the <B> component.

And again, under Inter-operability:

   For many computations, the case of the letters in the URN is immaterial
   can be safely ignored  because only the <B> component is authoritative:
   although the preferred presentation of the <B> component is in lowercase
   minimize its visual impact on human readers, the <B> component may be
   represented using letters of either case.

Please let me now if you have other suggestions which would enable me to
this proposal further?

On Thu, Oct 17, 2019 at 2:59 AM Dale R. Worley <> wrote:

> 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
> improved:
> 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
>    comparisons.
> 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..."
> Dale


Phil <>

Philip R Brenan <>