Re: [urn] gbs Name space identifier

Philip R Brenan <> Mon, 21 October 2019 16:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2986E120108 for <>; Mon, 21 Oct 2019 09:35:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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] 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 d213wwu_kXSB for <>; Mon, 21 Oct 2019 09:35:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0DF82120110 for <>; Mon, 21 Oct 2019 09:35:29 -0700 (PDT)
Received: by with SMTP id y5so12608336ilb.5 for <>; Mon, 21 Oct 2019 09:35:29 -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; bh=3ZOHuprTzqKhXpwMN3JR8TFs2g87JwM3MQawjIHlXus=; b=E7Rh+eKHiILvguD/yuy1sryolMgXFEUR4qrLBUxKqBFKYJafPr1vz44xZvfi9xmqwq UNZ9PFWNMnybrnnCXhNpMKPjvfTwUQWNufHKjpG1JXiGfO9GvwpwnhahqkNfCIoIB7kh fG2J2YOWwT37jjTinZlxgmweOV7k3/8ww3Q7/uH6zZnr+Y93U6ZqAtgaabT36wH0b1nx fkob0CWQ70uIn2+FBXXTHOfCqOF1K1jrt0apZ70ycK6+DyYfsTZJng6yEPSr1CAQD4DL 88WyoXbg6CHomgVew3429rt2X/Wj9CJQv0YGb0wvzz/4JOqg6BS/iXhyxDpyjxzz8u56 gtsQ==
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; bh=3ZOHuprTzqKhXpwMN3JR8TFs2g87JwM3MQawjIHlXus=; b=BdNdCGXWeoy0JLiB+nFukeCKmrwpyqvq2u8qAKS7J8UOR6pAjessMVH+VXrn4DkzYb D120zOqzOctwx/owvBpho/3jMyRGVY1qQijVlFBq7BNKpBGYdoqLgd3Q1/CHpM6N9yxx VoKkIA05lV7+SmYpNZcCqTyYCgAZ0O7LeCz98WelzG9GIM0Y6krbusjikZNwJdysWN9h /Q8HUfycKhPl5LxqnqcHijnqA160famP/w0ArK9687kqri7GdS/FnN1LfSzvXeZjwp5Z hYNTddFJdRjmrx1sIQQBdDODpu+PznqOv+vW5OoJOOQNjZBjBqKhc+F+s8vAix2udcR3 plcQ==
X-Gm-Message-State: APjAAAWJs5nQkjiVZRDQJ4Zx7gGdIG9bvzlamJ1WIemnkYkwjdY+NztY iwsEHOe2PYdYcZPk2nuLjOv4DwenyeR8v+w5u1U=
X-Google-Smtp-Source: APXvYqypMXKok10mafi09m8p2yD4gxKi761NJN4eEvT7FVNyixDQ5XhAuG6KX9bFydY9+nLx80mA0fj02DCDO+gnt80=
X-Received: by 2002:a92:865c:: with SMTP id g89mr9163366ild.291.1571675727882; Mon, 21 Oct 2019 09:35:27 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Philip R Brenan <>
Date: Mon, 21 Oct 2019 17:35:11 +0100
Message-ID: <>
To: "Dale R. Worley" <>, "Hakala, Juha E" <>,,
Content-Type: multipart/mixed; boundary="00000000000078fd5105956e45bc"
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: Mon, 21 Oct 2019 16:35:33 -0000

Hi *Dale*:

Thank you for raising these important issues.  I have updated the text of
proposal (attached) in light of your helpful comments.

I have corrected the error made on my part regarding MD5 collisions that you
kindly noted. It now reads:

    Equivalence is determined by comparing (ignoring case) just the <B>
    components of the two topics to be compared.  If they are equal the two
    topics are considered to be equal, even if, as a result of an MD5
    the content of the underlying documents is in fact different. The
    characteristics of the MD5 sum make such an occurrence extremely
    see for example Mead:

    "Unique File Identification in the National Software
     Reference Library"


    Authors who have concerns over the possible impact of an MD5 collision
    on their work should not use this name space.

My rationale for this change is as follows:

All URN name spaces that do not contain the content of the actual topic in
question are, in effect, digests that seek to use a finite string to name
topic drawn from a potentially uncountable set of topics. For each such
there must then be an uncountable number of other topics that could also
that digest.  Consequently, in theory, all such name spaces suffer from
collisions. In practice, only a finite number of topics need to be named, so
the design of a URN name space becomes one of engineering: is the collision
rate sufficiently low to be acceptable in the proposed application?

In developing this proposal I initially considered various incremental
numbering schemes. These schemes were deemed failures as they required
collections of documents to communicate in real time to avoid name

I then considered the CRC-32, MD4, MD5 and SHA-2 series of hash functions.
these, MD5 was the shortest digest that appeared to offer an acceptable
collision rate, following the study done by Mead:

As the URN identifying a document is likely to be frequently embedded in XML
and to appear in reports, presentations, program stack trace backs, spread
sheets, web pages, database indices etc. a shorter digest is preferable to a
longer one as long as the collision rate is acceptable.

MD5 is a useful compromise between the need to produce names that can be
in a variety of applications and contexts by both humans and computers while
maintaining a low enough collision rate. CRC-32 and MD4 were deemed too
unreliable.  SHA-2 was rejected on the grounds that the minimal improvement
reliability obtained in the proposed application space failed to justify the
extra overhead induced by the longer digests.

Consequently MD5 was chosen as the appropriate digest based on operational
experience obtained after trying a number of other possibilities.  If in the
light of further operational experience it becomes apparent that some other
digest would be more appropriate the <T> component provides space within
to adopt the new digest over time.

May I therefore urge that MD5 is an appropriate choice for now and that
adoption of this particular proposal should not be made dependent on finding
a perfect digest?

In Security and Privacy, following your suggestion, I have clarified that
access to the content named by the URN is required to check the validity of
URN as follows:

   Access to the content of the topic named by the URN is required to check
   validity of the URN. The validity of the URN for a topic can be checked
   follows: ...

May I propose that the need to access the content of a URL or URN to fully
validate the URI is a common feature of all name spaces as evinced by the
existence of HTTP code 404 and thus should not, in of itself, impede the
adoption of this particular proposal?

On Inter-operability, following your suggestion, I have clarified why case
often immaterial in anticipated operations on this name space as follows:

   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 representation of the <B> component is in
   to minimize its visual impact on human readers, the lower case form can
   easily be recovered from a mixed case form making the <B> component, in
   effect, insensitive to case.

   The MD5 sum represented by the <B> component can undergo degradation in,
   copying, storage or transmission yet still be recoverable by querying
   significant collections of topics for topics with similar <B> components
   given that the anticipated size of the topic space is of order 1e10
   an MD5 space size of order 1e38.

   Ideally, the <G> component should be presented in the case designated by
   original author of the topic.  In cases where this is not possible, the
   component can undergo degradation and still remain useful, for example:
   degradation rates in the <G> component have been noticed when the <G>
   component is spoken out loud by people collaborating in a shared work
   on less than 1e2 topics. The <G> component has a space size of at least
   as evinced by the number of Wikipedia articles in English:

   Operational experience has confirmed, so far, that the <G> component is
   capable of tolerating the significant degradation of case and spelling
   normally occurs in human speech.

   If the <G> component of two topics is intentionally identical or
   after degradation then the identity of a specific topic can be confirmed
   saying the first few characters of its <B> component using a phonetic
   alphabet, such as the one used by NATO:

   It is anticipated that names from the proposed name space will be
   in XML topic references, file names, URL queries and commands entered
via the
   command line.  XML is sensitive to spaces and the following characters:


   File systems are often sensitive to file names containing:


   The query portion of a URL is sensitive to:


   The command line is sensitive to spaces and:


   The <T>, <G>, <B> components avoid these characters to facilitate
   inter-operability between these systems.

   To facilitate the construction of file names and URLs containing
   to topics named by this proposed name space, the formal name assigned by
   this proposal may be intentionally degraded by omitting the words 'urn'
   'gbs', omitting the <T> component, replacing the colon between the <G>
   <B> components with an underscore and adding a file name extension if the
   formal URN can be reliably recovered from the degraded version in the
   context within which the degraded version is being used. In such a
   a formal URN:


   may be intentionally degraded to:


   Other acceptable degradation will be published as updates to this

   Dita topics that do not contain ASCII characters suitable for
   the <G> component will be accommodated by adding a new value to the list
   values accepted by the <T> component and specifying the corresponding
   algorithm for computing the <G> component in an update to this document.

During the development of the proposed name space I experimented with
alternative representations of the <B> component, specifically:
representing it
in base64 and in decimal.  Base64 had the disadvantage that the
predominance of
letters over numbers made it harder for humans to separate it from the <G>
component.  The decimal representation overcame this problem but at the
of a longer <B> component.  Just as MD5 seems to offer a useful balance
length and collision rate in computations on the <B> component,
of the <B> component in lowercase hexadecimal seems to offer a useful
between length and the speed at which humans can separate it from the <G>
component.  If, as a result of further operational experience, it becomes
apparent that a better representation of the <B> component is available then
the <T> component allows names withing the proposed name space to be
over time.

May I therefore represent that the proposed name space is usefully
resilient to
changes in case and the other degradations likely to occur during usage
maintaining a usable balance between the needs of humans versus computers?

In summary: may I urge that the combination of the <G> and <B> components in
the proposed name space represents a useful advance in the art of naming
topics and that consequently the proposed name space can be safely approved?

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 <>