Re: [urn] gbs Name space identifier (Dale R. Worley) Tue, 22 October 2019 02:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B46EE120AE6 for <>; Mon, 21 Oct 2019 19:12:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.685
X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 jo5n-61Y7TON for <>; Mon, 21 Oct 2019 19:12:25 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 79475120AE2 for <>; Mon, 21 Oct 2019 19:12:25 -0700 (PDT)
Received: from ([]) by with ESMTP id Mhu9iqkridlvIMjeqiSY6H; Tue, 22 Oct 2019 02:12:24 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20180828_2048; t=1571710344; bh=i3OL/5TRjFcjRpKx04yVFzxe7aNWu9GKveGNRaZVwj8=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=ayTy/j4V3jTff0pC5A3XZJi2BXsdCQrPiyJfbkFieLIHK1AKRgvDgYmuT9COVrvty k05fXpDMhy5G7hk2M8AaJ5ny+211fLB0ysBClSZF5WIW6Of9WFgl+Z/JDHJLTvczps Ylurwl9H38BrOfnOpSNlomc38P+5jsg7iEgnfmou96JQxCUvvDIBuDPzmxA5MMvH5e ymoZ4c7l5x5VVAYJRWhLounRBG6rMw2Soo4fe1CX3dTC967ViQ5ST32uikHgCK3XZf 2+0jrnx1Jg4J7J96sdHNfCTik/reFMygD/b0nrXMw3LIyCQN+pSpfoOISLY3/8vvM9 mcCJndE3yC40Q==
Received: from ([]) by with ESMTPA id MjeoiIGsVuX5xMjepi4xmY; Tue, 22 Oct 2019 02:12:24 +0000
X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedufedrkeeigdehhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucevohhmtggrshhtqdftvghsihdpqfgfvfdppffquffrtefokffrnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffujghssedttddttddttddtnecuhfhrohhmpeifohhrlhgvhiesrghrihgrughnvgdrtghomhculdffrghlvgcutfdrucghohhrlhgvhidmnecukfhppeeiiedrfedurdduvdejrdehudenucfrrghrrghmpehhvghlohephhhosghgohgslhhinhdrrghrihgrughnvgdrtghomhdpihhnvghtpeeiiedrfedurdduvdejrdehuddpmhgrihhlfhhrohhmpeifohhrlhgvhiesrghluhhmrdhmihhtrdgvughupdhrtghpthhtohepphhhihhlihhprhgsrhgvnhgrnhesghhmrghilhdrtghomhdprhgtphhtthhopehlrghrshdrshhvvghnshhsohhnseifvggsrdguvgdprhgtphhtthhopehurhhnsehivghtfhdrohhrghdprhgtphhtthhopehjuhhhrgdrhhgrkhgrlhgrsehhvghlshhinhhkihdrfhhinecuvehluhhsthgvrhfuihiivgeptd
X-Xfinity-VMeta: sc=-100;st=legit
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id x9M2CLsa012370; Mon, 21 Oct 2019 22:12:21 -0400
Received: (from worley@localhost) by (8.14.7/8.14.7/Submit) id x9M2CKCR012365; Mon, 21 Oct 2019 22:12:20 -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: Mon, 21 Oct 2019 22:12:20 -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: Tue, 22 Oct 2019 02:12:27 -0000

Philip R Brenan <> writes:
> 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?

I have no complaint against the use of MD5.  If I commeneted on it, I
expect that the cause was that some part of the text was unclear or

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

I have no concern about whether the URN can be validated.  But it's
common when a "validation" procedure is given, that it does not require
access to the designated resource itself.  So it is useful to the reader
to note that this procedure involves checking the URN against the

> On Inter-operability, following your suggestion, I have clarified why
> case is often immaterial in anticipated operations on this name space
> as follows:
>    For many computations, the case of the letters in the URN is immaterial and
>    can be safely ignored  because only the <B> component is authoritative:
>    although the preferred representation of the <B> component is in lowercase
>    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.

True ... but you're avoiding looking at the fact that you've *defined*
these URNs to use lower-case MD5.  If that field contains upper-case
letters, the whole URN is invalid.  Of course, if you see what *looks*
like a gbs URN with upper-case letters there, you might convert them to
lower-case to see if you get a valid URN, but that's like a computer
program with typos in it, a human might be able to get useful
information out of it, but you wouldn't want to depend on a computer
doing so.

OTOH, you could *define* that the MD5 portion is case-insensitive.  It's
your choice.