[urn] Re: [EXTERNAL] Re: [Uri-review] Request to register the glue URI scheme

["Lars G. Svensson" <[e-mail]>]

Michael,

> GLUE creates a mechanism for establishing URIs for identifiers in organizations that have not taken it upon themselves to do what GS1 is doing.

This is an interesting perspective. I'd say that the best way forward would be to work with those organisations and try to persuade them to perform exactly that work. Yes, it's heavy lifting but it will increase the stability of the system immensly.

My €0.02,

Lars

-----Ursprüngliche Nachricht-----
Von: Michael Jones [mailto:[e-mail]] 
Gesendet: Mittwoch, 24. Juni 2026 19:35
An: Peter Saint-Andre <[e-mail]>; Pamela Dingle <[e-mail]>; Roy T. Fielding <[e-mail]>; Ted Hardie <[e-mail]>; [e-mail]; [e-mail]
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; Chris Inacio <[e-mail]>; Anish Karmarkar <[e-mail]>; Apoorav Trehan <[e-mail]>; Babak Jahromi (CELA) <[e-mail]>
Betreff: [urn] Re: [EXTERNAL] Re: [Uri-review] Request to register the glue URI scheme

Thanks Peter,

To your point about GS1, it's fine for GLUE to not re-register GS1 identifiers because they have already taken it upon themselves to establish a GS1 URN namespace.  Applications needing URIs for GS1 values can use those URNs.

GLUE creates a mechanism for establishing URIs for identifiers in organizations that have not taken it upon themselves to do what GS1 is doing.

If you think that the identifier space is too messy for URNs, then I think that brings us back to creating a glue: URI scheme - which is what the draft currently does.  I would therefore ask the URN designated experts to approve the registration of the glue: URN scheme.

				Thanks all,
				-- Mike

-----Original Message-----
From: Peter Saint-Andre <[e-mail]>
Sent: Tuesday, June 23, 2026 1:07 PM
To: Michael Jones <[e-mail]>; Pamela Dingle <[e-mail]>; Roy T. Fielding <[e-mail]>; Ted Hardie <[e-mail]>; [e-mail]
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; Chris Inacio <[e-mail]>; Anish Karmarkar <[e-mail]>; Apoorav Trehan <[e-mail]>; Babak Jahromi (CELA) <[e-mail]>
Subject: Re: [EXTERNAL] Re: [Uri-review] Request to register the glue URI scheme

Thanks to Pam for the further explanation.

I'm struggling to see in clear specifics how a URN namespace or URI scheme will help clean up the messy world of supply chain traceability in a way that, say, a shared industry database couldn't do (e.g., a flexible open-source project that attempts to put some measure of order on the chaos). How does prepending identifiers with urn:glue or glue: 
help solve the problem of unknown and in many cases unknowable manufacturers, compounded by apparently incompetent authorities for tracking such manufacturers? Can we even use the term 'identifier' if the data really are as dirty as Pam describes, with some of these alphanumeric strings being mere hints and guesses?

With regard to URNs specifically, Pam's description might make me even less sanguine that a URN namespace is the right approach. Per RFC 8141, a URN namespace is supposed to provide "persistent identification of resources and unique assignment of names in accordance with a common definition". However, in this case the data are so dirty that resources (i.e., manufacturers) might move from one URN "sub-namespace" to another in a somewhat random fashion as the traceability experts determine that, say, errors were made by an authority for tracking businesses in a particular industry or locale. Although when working on RFC 8141 (and RFC 2141 before that) the URN WG envisioned that the same resource could be identified by different URNs (e.g., an ISBN URN and an NBN URN might identify the same object in a library or archive), the problem space here feels almost inherently unmanageable.

Furthermore, those of you advocating for a GLUE URN namespace have already received feedback from at least the GS1 authority (with advance warning that the same might be received from the LEI authority and perhaps others that have had no reason to pay attention to these IETF
discussions) that they want no part of GLUE and do not want their identifiers to be re-assigned without their authorization within a GLUE namespace.

Although I realize that there's a compelling and difficult business problem to be solved here, I ask that you please think outside the box and consider other approaches, such as an open-source database as adumbrated above, because business urgency is not a good argument for (from my perspective) violating the well-established principles of URN assignment specified in RFC 2141 and RFC 8141.

Peter

On 6/23/26 11:45 AM, Michael Jones wrote:
> Thanks, Pam and Microsoft, for sharing this real-world perspective. 
> Let me reinforce your point that GLUE is intended to bring order to 
> identifiers used in global supply chains in which we practically won’t 
> see local country-specific or reginal identifier authorities ever 
> creating a URN namespace on their own.
> 
> For these practical reasons, I would ask that the URN experts 
> reconsider approving registering the urn:glue: namespace.  (I ask for 
> URN registration rather than URI scheme registration because I believe 
> Roy’s arguments for URN registration over URI scheme registration were
> compelling.)
> 
>                                                                  Thank 
> you,
> 
>                                                                  -- 
> Mike
> 
> *From:*Pamela Dingle <[e-mail]>
> *Sent:* Monday, June 22, 2026 4:05 PM
> *To:* Peter Saint-Andre <[e-mail]>; Roy T. Fielding 
> <[e-mail]>; Ted Hardie <[e-mail]>
> *Cc:* The IESG <[e-mail]>; [e-mail]; draft-ietf-spice- 
> [e-mail]; [e-mail]; Chris Inacio 
> <[e-mail]>; Anish Karmarkar <[e-mail]>; 
> Apoorav Trehan <[e-mail]>; Babak Jahromi (CELA) 
> <[e-mail]>
> *Subject:* Re: [EXTERNAL] Re: [Uri-review] Request to register the 
> glue URI scheme
> 
> Hi all,
> 
> I understand why you all have given us the advice that you have - it 
> makes sense from a technical perspective.  Unfortunately what we are 
> trying to implement using Glue is not a clean thing.  I am hoping it 
> would help to talk about what our real world goals are, in case you 
> can see a path that we cannot, and also just to be sure everyone knows 
> that we are not trying to be difficult or to drag everyone through a 
> shaggy dog story for no good reason.  Any thoughts you have are very 
> welcome, and if anyone is interested in getting together to 
> brainstorm, that would be amazing.
> 
> In the same way that I'm not an expert in URI/URN formats, I'm not an 
> expert in supply chain traceability, so I have copied my coworkers 
> Anish Karmarkar and Apoorav Trehan in case they can correct any errors 
> I introduce here.  Apoorav did give some comments on what I've 
> written; those comments from the actual supply chain expert are 
> annotated at the end.
> 
> We have a long-standing problem in the physical supply chain world.  
> Over periods of decades, the many businesses that form the many tiers 
> of a given supply chain are incorporating, operating, merging, 
> acquiring, dying.  This happens globally, across multiple legal 
> jurisdictions, and potentially multiple regimes.  Paperwork quality 
> varies, and the authorities that validate the businesses (which are 
> businesses
> themselves) go through their own business lifecycles of growing, 
> merging, dying.   A given business may register and be vetted with 
> numerous authorities, accumulate numerous authority identifiers, and 
> cease using numerous identifiers.  But those identifiers may appear in 
> the supply chain manifests and in multi-tier audit logs, internal 
> siloed tracking databases and physical paperwork of many of the 
> businesses in the supply chain ecosystem.  The people notating the 
> identifiers are not the owners of the identifiers, they are low level 
> workers who are not validating identifiers, they are simply moving and copying strings.
> Decades later, when investigations might occur or traceability efforts 
> might be undergone to decide what product could be affected by an 
> investigation, those investigators deal with exceptionally dirty data; 
> they may not even know that a given authority existed 30 years ago let 
> alone that the column of the corrolating identifier is labeled in a 
> way that was implicitly known to from that authority but not 
> explicitly included.   Our primary issue here is that different 
> storage of different identifiers, implicitly namespaced rather than 
> explicitly namespaced and spreading through various data structures 
> creates extremely difficult conditions to find evidence.
> 
> What I am hoping to get done with the glue identifier, is to create an 
> identifier that is intended to sit for decades and expected to be 
> mistyped sometimes, to end up in some column of some database 
> somewhere that could have lost the original context over multiple 
> upgrades.  A glue identifier is not (at least in this usage) intended 
> to be resolvable, it is intended to encapsulate just enough 
> information that no matter where that identifier drifts to, it retains 
> at least a hint of its purpose and provenance.  Enough that a person 
> or process digging through the rubble of a 30-year-old data backup of 
> a corporation might have a chance to find the information that matches 
> an old manifest.   If a data entry clerk can't be bothered to check 
> that the IANA registry identifier of the chinese subsidiary of an 
> authority should have a c appended to it and they label it as auth 
> instead of authc, the auth encoding is still valuable, because whoever 
> is doing the forensic work knows that it is a glue identifier to start 
> with and that these mistakes can happen.
> 
> These identifiers will not exist in a perfect world of perfect labels.  
> This is a way for an attribute contract to ask for a business 
> identifier to be encoded in the payload of attestations as informative 
> attributes, without requiring an attribute for every possible business 
> authority, but retaining an identifier that means later validation is possible.
>   The scheme for a 10-years-dead business authority will never be 
> registered; having an admin make up something approximate in a glue 
> identifier could be the best possible outcome even if a different 
> admin in a different place makes up something different.  It is a 
> hint, and that's what we want.
> 
> None of this should be in the spec obviously.  But we are trying to do 
> something for a meaningful reason, I believe.   I know it doesn't 
> match the goals of your important work.  But I cannot imagine that 
> there is no place at IETF for a logical and standardized data format 
> to contain this kind of imperfect information.  Anything you can do to 
> help us resolve this would be appreciated.
> 
> Additional notes from Apoorav:
> 
> @Pamela, I agree with your framing and echo that GLUEID is not trying 
> to replace existing identifiers, nor is it trying to create a new 
> authoritative namespace. It is trying to preserve context across 
> fragmented, long-lived, and imperfect supply chain records. I feel 
> that current URN schemes assume well governed durable namespaces (like
> urn:gln: or urn:gs1) The issue in the physical supply chain that the 
> many identities we encounter, specifically in other countries and that 
> are historical (old – like khsra# (land) in India or municipality 
> identifier in Vietnam) might not have a name space at all. Also over 
> time as companies, countries and authorities change we see many 
> identifiers becoming ‘relics’ that loose original meaning over time 
> (or can be misused). GlueID helps us to encode those anyway and 
> maintain some hint of original purpose over time.
> 
> Also, not sure if how to word this, but pushing the URN definition to 
> individual organizations does not help solve the issue since (a) I 
> don’t see local country specific identifiers ever getting a namespace
> (b) physical supply chains have long histories and need to retain some 
> context over time as things change
> 
> ----------------------------------------------------------------------
> --
> 
> *From:*Peter Saint-Andre <[e-mail] 
> <mailto:[e-mail]>>
> *Sent:* Friday, June 12, 2026 5:37 PM
> *To:* Roy T. Fielding <[e-mail] <mailto:[e-mail]>>; 
> Ted Hardie <[e-mail] <mailto:[e-mail]>>
> *Cc:* The IESG <[e-mail] <mailto:[e-mail]>>; uri- 
> [e-mail] <mailto:[e-mail]> <[e-mail] 
> <mailto:[e-mail]>>; [e-mail] 
> <mailto:[e-mail]> <draft-ietf-spice-glue- 
> [e-mail] <mailto:[e-mail]>>; spice- 
> [e-mail] <mailto:[e-mail]> <[e-mail] 
> <mailto:[e-mail]>>; Chris Inacio <[e-mail] 
> <mailto:[e-mail]>>
> *Subject:* [EXTERNAL] Re: [Uri-review] Request to register the glue 
> URI scheme
> 
> On 6/12/26 12:34 PM, Roy T. Fielding wrote:
>>> On Jun 11, 2026, at 11:44 PM, Ted Hardie <[e-mail] <mailto:[e-mail]>> wrote:
>>>
>>> Hi Roy,
>>>
>>> As you can tell from reading this specification the glue identifier 
>>> has elements that are not directly managed and the other bodies 
>>> minting those elements have not agreed to behave as a part of URN 
>>> namespace authority.  So by the intent-based formulation given 
>>> below, these do not qualify.
>>>
>>> We can certainly re-open the discussion on what the identifier 
>>> landscape within this realm should look like; I think my first such 
>>> discussion was at the first Stockholm IETF more than thirty years 
>>> ago, and I suspect the discussion will outlast me.  But I think any 
>>> changes from that discussion would have to apply to later work than 
>>> this, which is otherwise ready to proceed.
>> 
>> Yes, 1993 in my case, but sadly lost in the former bunyip archives. I 
>> agree with your assessment. Thanks for taking the time to explain it.
>> 
>> However, I think there should be a distinction made between minting 
>> individual URI schemes to carry a third-party identifier, which is 
>> something we have approved many times, versus minting a single "glue"
>> scheme as a separate authority for future third-party namespaces. URN 
>> was approved for that because it had a specific purpose to justify it.
>> 
>> In contrast, "glue" is just a restatement of URI at one level down. 
>> The syntax prepends "glue:", schemes become new namespace 
>> authorities, and IANA is expected to generate a new administrative 
>> hierarchy to maintain registries of arbitrary authorities under the 
>> glue scheme. I don't see any reason to approve that when the same 
>> people can just as easily use existing or new authority-specific 
>> identifier schemes (or URN nids) as normal URIs.
>> 
>> I don't think SPICE was given the remit to produce a URN-alternative. 
>> I think that would require a much larger discussion, IETF-wide, and I 
>> see no justification to open that can of worms.
>> Hence, my suggestion is to reject this draft as an IETF publication. 
>> If the authors want a single reference syntax, see RFC3986.
>> If they want IETF-approved names for GS1, GLEIF, DUNS, PEN, and 
>> ISO6523, then register them as new URI schemes.
>> 
>> If there is a technical reason for their inability to do the same 
>> thing that every other IETF protocol does, please explain that in the proposal.
> 
> Hi Roy,
> 
> This is basically the same reasoning we applied from a URN 
> perspective, so I can't disagree with your assessment.
> 
> Peter
> 

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