[urn] Request to register urn:glue - Additional Observations from Affected Ecosystems

All,

I appreciate the thoughtful responses since my earlier email, and I
recognise that Michael's frustration is understandable. My intent remains
constructive. I write again only because a few additional points have come
to light that may be useful to the designated experts as they work toward a
decision.

Since my earlier message, I have spoken with Chris Day, one of the lead
architects of ISO 20022 (SWIFT messaging), who now works with GS1. With his
permission, I can share that GS1 would not support this registration. This
is significant given that GS1 identifiers including the GLN are among the
authority registrations proposed in Section 7.1.2.1 of the draft.
Introducing a parallel urn:glue: path for those identifiers, without the
knowledge or support of the organisations that govern them, risks
undermining an infrastructure that has taken years and considerable
investment to build.

On the question of resolution, I want to offer a practical perspective from
our own experience. In the SDMX community, where I am a technical working
group member, we made a deliberate decision to build a resolver service
https://urn.sdmx.io ahead of our URN registration because we understood the
operational value resolution provides to our members: the BIS, ECB,
Eurostat, IMF, OECD, the UN, and the World Bank, among others. Resolution
is not a theoretical nicety; it is what makes an identifier operationally
useful within a governed ecosystem.

This brings me to what I believe is a substantive tension in the GLUE
draft. Section 7.2.1 states that GLUE URNs provide "a globally unique
equivalent to identifiers within those local namespaces," yet the same
section states that resolution is not performed. To be clear, the concern
is not that URNs are obligated to resolve, RFC 8141 is clear on that point.
The concern is that GLUE claims equivalence to identifiers from systems
that may operate resolution infrastructure, while providing none of its
own. GLEIF, for example, provides resolution services for Legal Entity
Identifiers through the Global LEI Index, a public platform offering
web-based lookup, API access, and data mappings that support verification,
KYC, and compliance workflows worldwide. Introducing a parallel identifier
that claims equivalence to an LEI but offers no comparable resolution path
creates genuine ambiguity for implementers operating in those ecosystems.

Ted Hardie's suggestion of a glue: URI scheme rather than urn:glue: is
worth serious consideration, and I note that Orie has expressed a similar
view. I do not hold a strong technical opinion on that path, but it appears
to address several of the concerns raised here without abandoning the
underlying goals of the work.

I defer entirely to the designated experts on the appropriate outcome, but
I respectfully suggest that reaching out to the originating authorities,
GLEIF, GS1 and the relevant ISO technical committees before proceeding
would serve everyone's interests. Not as a formal condition, but as a
matter of professional courtesy and practical prudence.

Best regards from Prague,


<http://smartxdata.com/>

*Tom Roberts*

*Chief Data Officer / Founder*

*ISO 17369 TWG Member*

*Eurofiling Member*

*Mobile **CZ: +420 773 532 216*

*Mobile US: +1 689-837-7529*

*Email: [email protected] <[email protected]>*




 CONFIDENTIAL COMMUNICATION: This email message and any attachment may
contain privileged and confidential information intended only for the use
of the individual or entity to which the email is addressed. If the reader
of this message is not the intended recipient or the employee or agent
responsible to deliver it to the intended recipient, that person is hereby
notified that any dissemination, distribution or copying of this
communication is prohibited. If you have received this communication in
error, please notify us as soon as possible by telephone (collect calls
will be accepted). Thank you for your cooperation and assistance.

<https://twitter.com/macktony>





On Fri, Mar 27, 2026 at 6:32 PM Ted Hardie <[email protected]> wrote:

> Hi Michael,
>
> I understand your frustration at this late intervention, and it is
> regrettable that the review was not solicited much earlier in the life of
> the development of the GLUE proposal.  When there isn't an active working
> group, it can be hard to ensure that this kind of cross-working group
> review occurs.  Despite the timing, however, the concerns Dale and others
> have raised are significant.  If you review RFC 8141, will you see that a
> core principle is that the combination of NID and NSS must result in an
> identifier that is globally unique:
>
>    The NSS is a string, unique within a URN namespace, that is assigned
>    and managed in a consistent way and that conforms to the definition
>    of the relevant URN namespace.  The combination of the NID (unique
>    across the entire "urn" scheme) and the NSS (unique within the URN
>    namespace) ensures that the resulting URN is globally unique.
>
> Historically, that assurance has been derived from the registrant of the
> NID being the authority which issues the namespace specific strings
> associated with that NID.  In any proposal where that is not the case,
> there is a risk that the actual issuing authority's approach to uniqueness
> may change over time, resulting in a combination that does not meet the
> goals of a URN.
>
> In your proposal, the registration of "GLUE Authority Identifier URN"s is
> meant to replace the normal relationship between the NID registrant and NSS
> by providing for registration of external authorities, who the designated
> experts believe will behave in a way consistent with the URN guidelines.
>  The guidelines in the document do not contain advice to the experts on how
> to evaluate that, nor does it contain any guidelines on how to invalidate a
> GLUE Authority Identifier if the authority ceases to issue identifiers that
> would conform (imagine for a moment that Dun and Bradstreet decided to
> reuse DUNS numbers after the original entity had been defunct for 50
> years--this would be rational for some use cases, but would invalidate
> their use as URNs).
>
> In a lot of ways your proposal echos the approach taken by the DOI
> foundation (see http://www.doi.org/registration_agencies.htm for a list
> of their registration agencies).  That suggests to me that one way forward
> here might be to shift this registration from a URN NID registration to a
> URI scheme registration, which would parallel how the DOI foundation moved
> forward when faced with similar concerns.  You can see the details of their
> scheme registration here:
> https://www.doi.org/resources/DOI_URI_Scheme.pdf.
>
> The change in your document would be to shift from urn:glue to glue: as
> the start of the identifier; you could otherwise maintain the same syntax
> and the same approach to registering subsidiary GLUE Authority
> Identifiers.  The difference would be that the document would need to
> describe how the glue URI achieved uniqueness and over what scope, but it
> could echo those statements from the URN documents which matched your
> intent.
>
> Just a suggestion, of course, but it does seem to me like the quickest way
> to move forward, even if it does mean a trip back to the working group to
> approve the change and a review by the URI scheme registration list and
> designated experts.  I am not one of the designated experts, but I am on
> that list and I believe that with a pointer to the doi scheme registration
> and an explanation of the issue that this could move forward as a URI
> scheme.
>
> regards,
>
> Ted Hardie
>
> On Fri, Mar 27, 2026 at 2:54 PM Michael Jones <[email protected]>
> wrote:
>
>> Hi Dale,
>>
>> Thanks for letting me the know the status of this application, Dale.  The
>> whole point of the GLUE draft is to "incorporate ... identifiers controlled
>> by other organizations" into the URN namespace.  This enables URNs to be
>> used in protocols to refer to organizations, whether the identifiers
>> controlled by other organizations already have a URN representation or
>> not.  That's exactly why the working group took on this work.
>>
>> This isn't academic.  There's intent to use it in multiple independent
>> use cases.  For instance, ISO/IEC 6523 identifiers were included in the
>> GLUE URN space because of a desire to use it for Swedish government use
>> cases, per
>> https://github.com/ietf-wg-spice/draft-ietf-spice-glue-id/issues/51.
>> GLUE was originally motivated by cross-border trade use cases.
>>
>> Indeed, the description of URNs in
>> https://www.rfc-editor.org/rfc/rfc8141#section-6.3 seems to anticipate
>> uses of URNs incorporating identifiers from other standards:
>>    The IETF recognizes that situations will arise in which URN
>>    namespaces will be created to either embed existing and established
>>    standards, particularly identifier standards
>> That's exactly what GLUE does - so that URNs can be used for those
>> namespaces that previously were not represented as URNs.
>>
>> This is an aside, but the parts of GLUE that one could reasonably say are
>> unnecessary are where URNs already exist for the identifiers.  LEI URNs are
>> such a case, per
>> https://www.ietf.org/archive/id/draft-ietf-spice-glue-id-08.html#name-lei-urns.
>> The authors could consider dropping registrations of the arguably
>> unnecessary duplicative GLUE URNs if that would address the Designated
>> Expert's concerns.
>>
>> Having every organizational identifier from any source be referenceable
>> as a URN is the point.  Please let's get that done.
>>
>> This note is written in the spirit of
>> https://www.rfc-editor.org/rfc/rfc8141#section-6.2:
>>    Because naming can be difficult and contentious, URN namespace
>>    registrants and the Designated Experts are strongly encouraged to
>>    work together in a spirit of good faith and mutual understanding to
>>    achieve rough consensus (see [RFC7282]) on handling registration
>>    requests.
>>
>> Please work with us to meet the need for URNs to be usable to refer to
>> organizational identifiers from any source.
>>
>>                                 Thank you,
>>                                 -- Mike
>>
>> -----Original Message-----
>> From: Dale R. Worley <[email protected]>
>> Sent: Thursday, March 26, 2026 6:58 PM
>> To: Michael Jones <[email protected]>
>> Cc: [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]
>> Subject: Re: [urn] Request to register urn:glue
>>
>> Michael Jones <[email protected]> writes:
>> > Touching base on this.  The authors addressed the review comments from
>> > the designated experts.  The spec has completed working group, IETF,
>> > and IESG review.  Publication as an RFC is currently blocked until the
>> > state changes to "IANA OK".  Can one of you please approve the
>> > registration so it changes to "IANA OK"?
>>
>> Currently the URN expert group is running into the problem that we
>> disagree with -- or at least, have unresolved concerns with -- the
>> *concept* of the GLUE namespace, specifically, that it incorporates a
>> number of identifiers controlled by other organizations.
>>
>> The more generalized discussion is in the thread
>>
>> https://mailarchive.ietf.org/arch/browse/urn/?gbt=1&index=KjzL-lRp3zCYw51AATq993ifAmo
>>
>> Dale
>>
>> _______________________________________________
>> urn mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>>
> _______________________________________________
> urn mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

_______________________________________________
urn mailing list -- [email protected]
To unsubscribe send an email to [email protected]