Re: [urn] gbs Name space identifier

"Hakala, Juha E" <> Wed, 25 September 2019 04:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 48D33120041 for <>; Tue, 24 Sep 2019 21:52:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cI0kOGWvyO2w for <>; Tue, 24 Sep 2019 21:52:18 -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 40BB6120086 for <>; Tue, 24 Sep 2019 21:52:16 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=ngPk/+WSYYSTFHPRvcCAw3vyTbbfmoHKqhFapgeiyugd8yjCuYklYwrgm11pc+WGGLcyydnjJHKhpQYpvYUMZG7ZKO2AXHNSE7ES6GnS3hVX6JlNqrLsXNDmi5M5h6+whE/zVOdDiFUYgA6ytSRlra1ruOlVRdwh1xZ1jm9MAHbYAO7GyY077TraDwzTCfabthSLKgrDV7r+ttNpNLWPCIesB5t3GDOUTx0dNdSmwmG9KQ2dwJGUAPPn5BTtHKljyv2VjARPstNXip84aEWHaCBElf3dGfo3XnSi34Gp/3JWD9OpYhVCQyACnuJ4B08FUZlyT5toqlyVsFNZHPDRMQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v3RWHBnXbDkd6NLDZBANP1vcsSe0JFWBNA+j9rtCWKQ=; b=E/dYgx+doTEN0dQJWHllY/DkmKHGzkL7gDVQheh4dA5hWN/oZrulSj8aaqyY0CgCC0FL9OdSBTFj0rXAEIgDAe2lCLlWTU4qmFCugKO5MdQew9maiY69om6ASTAJICGFQg3FHl4JSI2oL7zSmcRYVnhunyYeshnd6hJvqbFtjJ3vnZu0ziZ4Nbd7wzCE9Xf42AsvMxctFrHFcIE8ghBcZEEVpwFMauTaVxQUUIXdhL0NpzIiKZ7EBLyUdYUubSvlwAyXmgSPeirv5D7B5lrBhuavRayQphiZwkanSMgJmTCYziksMhCdTDg9LSVCqAZSD4oaoDwchApvF7P/k35mBg==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2-HelsinkiFI-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v3RWHBnXbDkd6NLDZBANP1vcsSe0JFWBNA+j9rtCWKQ=; b=JbvaUQhsr/cFja12jnxsDUqynEKsNXrk5N5b05h/K4XnXkM/4zWLL4BZY/vgGHV1pjRNuUe3FZX7M9Y3xmiA44kZKa9MFpFcdDu12QxnaYqjFx2csEcGY3NYk7jwwNO+idtHVUk4poY5bBbYMWJXDFdLe1EyTARGgmp8oPEuldk=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.15; Wed, 25 Sep 2019 04:52:13 +0000
Received: from ([fe80::c0c6:337b:4ea5:1ba]) by ([fe80::c0c6:337b:4ea5:1ba%7]) with mapi id 15.20.2305.013; Wed, 25 Sep 2019 04:52:13 +0000
From: "Hakala, Juha E" <>
To: "Dale R. Worley" <>, Philip R Brenan <>
CC: "" <>
Thread-Topic: [urn] gbs Name space identifier
Thread-Index: AQHVaQ+bR34HLN0muUyz1prz3YP+Wqc74m0A
Date: Wed, 25 Sep 2019 04:52:13 +0000
Message-ID: <>
References: <> ( <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: fi-FI
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6135c6e1-712b-4e4e-0ab1-08d7417421cc
x-ms-traffictypediagnostic: HE1PR07MB3433:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01713B2841
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39850400004)(396003)(136003)(346002)(376002)(366004)(189003)(199004)(14444005)(256004)(25786009)(8676002)(476003)(81156014)(6436002)(11346002)(486006)(33656002)(81166006)(71200400001)(478600001)(74316002)(186003)(6506007)(446003)(71190400001)(26005)(102836004)(2906002)(966005)(7696005)(8936002)(7736002)(76176011)(66946007)(66556008)(316002)(76116006)(86362001)(110136005)(99286004)(305945005)(561944003)(66066001)(66446008)(64756008)(55016002)(14454004)(6116002)(66574012)(4326008)(9686003)(786003)(3846002)(5660300002)(52536014)(66476007)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB3433;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: H1cGKKfpkCOQwY+psGe0/fVfPlFBvhzRPker7MCZBpATFGefssEo2zT1vE3U5YD12jPcvJ2fWhkDTRp+WkowZt+ffNkbav8Z4b07bjjHv386kGxRu7xDVo+VKPSQ6H1KgE/l78aVp4+p9yFewIcuCr3pIgCQJTiJg8BxEkppFNqCdbYlVjhXmgnJ2AYhv9owVPjpbzcMjARwr5XDhZMjrLSzW2q66EuEl9Kh32FI+rTrnb9Z2barkX8gxPrI4N0Om0r27Lk7gMxbVd9PwJW0XxRKfiX9m+swfgYcGEBm/dT2LDG+kSoFv0qCNAgkzBQE3kQv4RXbdrRtDYmSqdF/A/OWzU0Qd2P2/j8BdzMuzJ+qocbh/G5R0DGbn39LqZWCXGXmuzCL+89M+fBqMWM9inIwlZCjg8LuI9vtEUBmW+VeJ8IN5uO4F9KuAbCr+V2MIi/4B1PXW3P93I2+aLLDYQ==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6135c6e1-712b-4e4e-0ab1-08d7417421cc
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2019 04:52:13.3097 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 6F2nFQq5TlYETYDsEOFdhyg5XLfxXcIoywM7IJEIBhwzHfcVh/q7pbccbZKC2vR1lbZ7UcBgxJY/vcZvLvAPNA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3433
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, 25 Sep 2019 04:52:23 -0000


DITA is an OASIS standard which was first approved in 2005. GB standard for naming DITA topic files seems to be a recent extension to DITA version 1.3. in order to " enable global collaboration (especially within the meta::cpan platform) through uncoordinated content sharing". 

The scope of this proposal looks clear to me in general (if I have understood DITA correctly) and registering a URN namespace for this purpose is OK. 

Please add a list of types to the specification of DITA GB standard at, and specify how the list will be maintained.  

 As Dale writes below, the registration should provide more information about how <G> is constructed. A link to the appropriate algorithm is OK, but some background information about these algorithms is IMO required, so that the users will be well informed about how these URNs are constructed. 

Best regards, 

Juha Hakala 

-----Alkuperäinen viesti-----
Lähettäjä: urn <> Puolesta Dale R. Worley
Lähetetty: torstai 12. syyskuuta 2019 5.12
Vastaanottaja: Philip R Brenan <>
Aihe: Re: [urn] gbs Name space identifier

Certainly an interesing idea, but there are some things that need to be

One thing you want to clarify is what sort of resources the URNs specify.  >From the way you write, I believe that they are intended to be what are called BLOBs, finite sequences of octets, or files as a Unix user thinks of them, with no metadata.  But that should be stated explicitly.

>    <T> is a string of one or more characters drawn from: [a-zA-Z0-9_] which
>    identifies the type of content from a list of types published by the
>    registrant at .

I attempted to obtain the list of valid types at the given URL, but was unsuccessful.  That page seemed to be a very top-level discussion of "The GB Standard".

>    <G> is a string of one or more characters: [a-zA-Z0-9_] chosen
>    algorithmically depending on the value of the <T> component. The possible
>    algorithms will be published on by the registrant. The
>    user is directed to the appropriate algorithm by a link published beside the
>    description of type <T> at:

As written, this provides no real constraint on the <G> value, other than its character set, because there seems to be no constraint on the algorithms involved.

I think the approach you want to take is to state that for each type <T> there will be a published algorithm, and <G> has to conform to the algorithm for <T>.

>    Identifier persistence considerations:
>        Persistence is guaranteed by the immutability over time of the MD5 sum
>        of the <B> component.

Because of <B>, there is a guarantee that if a URN refers to a resource at a time, and at another time refers to a resource, then the two resources are identical.  And that is the minimum needed for a URN definition.

But there are no statements that types will not be removed from the list of types, or that users might decide to use a different type for the same resource, leaving two URNs referring to the same resource.
Similarly, what guarantees are there regarding the <G> algorithms over time?

None of these questions are critical, but it would be much better if you declared your intentions.

>     Equivalence is determined by comparing the <G> components of the two items
>     to be compared.  If they are equal the two items are considered to be equal.
>     Otherwise they are considered to be unequal even if the underlying content
>     is in fact identical.

If equivalence is determined solely by the <G> values, why are the <T> and <B> values present in the URN?

>    The validity of the urn can be checked as follows:
>    Check that the <T> component is on the published list of possibilities.
>    Check that the <G> component is computed correctly when the algorithm named
>    by the <T> component is applied to the content.
>    Check the the <B> component matches the MD5 sum of the content.

That last item is ill-defined, as it requires one has the resource for the URN, but there is no algorithm for constructing the resource from the URN.


urn mailing list