[urn] Re: Request to register urn:glue

Hi All,

> The change in your document would be to shift from urn:glue to glue: as
the start of the identifier;

I like this proposal, we discussed a variant of it previously here:

https://mailarchive.ietf.org/arch/msg/spice/dzGzd6yBXiP-cQfMxkq4QFWuehk/

TLDR, I personally think `glue:` is better than `urn:glue:` for the use
cases glue is meant to address.

I think asking all entity identifier systems to register directly under
`urn:` would be a mistake, but that's the only alternative I see given the
feedback I've reviewed so far, and given that `urn:lei:` is already a thing.

Regards,

OS

On Fri, Mar 27, 2026 at 12: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]