[urn] Re: [EXTERNAL] Re: [Uri-review] Request to r egister the glue URI scheme
Brent Zundel <[email protected]> Mon, 29 Jun 2026 15:42:43 -0600
| Newsgroups | gmane.ietf.urn,gmane.ietf.uri-review |
|---|---|
| Message-ID | <CAOGO=oHD8aMwUmEc2DdxTqZQ8NhbUKX-aOzHEZLuC0LOnhoMow@mail.gmail.com> |
--===============8807549855107338662== Content-Type: multipart/alternative; boundary="000000000000e17ac006556b5836" --000000000000e17ac006556b5836 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've been following this thread with great interest and not a little curiosity. It seems like there may be some folks who are struggling to understand what we are trying to accomplish with GLUE. Some have pointed out that global business identification is a major problem. One which led to the creation of GLEIF, and has led to a number of other organizations pursuing URN registration for individual schemes. This is laudable. This is good. It may even solve the problem someday, but in my estimation those solutions are a long way off. Where we agree is that there is a problem and many people are interested in solving it. One GLEIF statistic I have seen repeated often is that over 3 million businesses have obtained an LEI. This is great. It is a wonderful step in the right direction, but it is a tiny drop in the bucket of the hundreds of millions of businesses and organizations engaged in trade worldwide. GLUE enables existing business identifiers to be used in the interim between now and whenever in the future those businesses are able to themselves claim an LEI or GLN. Pam pointed out a clear need for additional tools for identifying businesses, ones that are long-lasting, and can be used to help keep the records being passed about as legible as possible. Some have argued that such a mess is clearly not something that a URN scheme is appropriate for. Not in my view. The clear organizational potential that is brought to bear by the introduction of GLUE identifiers would have a significant impact in the clarity and legibility of these currently messy and difficult to read documents. They are messy because there isn't a simple scheme that can be used to organize them. That is all GLUE aims to be. Someone mentioned that a global database might be a more appropriate solution than an identifier scheme and an accompanying registry of authorities. I'm a bit confused what the difference is between a global database and an IANA registry, except that an IANA registry is easier to find, unburdened by corporate interests, and more likely to be a trusted global source of information. I'm fine if GLEIF or GS1 would prefer they not be listed in the registry, since they have their own URN schemes, but such a determination to not be involved completely misses the point. Demanding to be removed from GLUE is like the producers of some informative reference demanding it be removed from another specification that wishes to refer to it. Supporters of GLUE are supporters of the great efforts being made by GLEIF and GS1. GLUE is an attempt to make it even easier to use those identifier schemes in digital trade credentials, alongside the myriad other business and organization identifiers that are in use today. GLUE is not a business registry. It claims no authority for determining the realities of business registration beyond the those already possessed by the authorities themselves. GLUE is just a slightly different way to format the existing identifiers, one that is consistent with the requirements of digital identity and trade modernization schemes. It is paired with what we hope will someday be an expansive registry of organization identifier authorities. There is no registration scheme too small to fit inside GLUE. But, it seems to me like all of that may be beside the point. GLUE isn't some random individual draft out of nowhere. GLUE was been adopted by an IETF working group. That working group reviewed and refined the ideas in GLUE over years. The specification found working group consensus and passed working group last call. To my understanding it even passed IESG review. All that is left is to register the identifier scheme. There have been ample examples shared in this thread and others, ones I am not going to reiterate, that make it seem as though the designated experts are holding GLUE to a higher bar for URN or URI registration than other schemes have been held. I don't believe that the experts are acting inappropriately. I applaud their caution, but encourage them to act and register GLUE. GLUE is not going to break the internet. If its detractors are correct, and GLUE sees little to no use in industry, then it would certainly not be the first IETF specification to meet such a fate. I don't think they are right. I think GLUE can have a positive impact on the disgusting mess that is global business and organization identification= . Thank you for your time. I apologize for the wall of text. tl;dr GLUE is a well-thought out solution to a real problem and it is ready to move forward. Please register the identifier scheme. URN or URI? honestly whichever would be fine. Brent Zundel On Wed, Jun 24, 2026 at 11:35=E2=80=AFAM Michael Jones <michael_b_jones@hot= mail.com> wrote: > 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 establi= sh > 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 thin= k > 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 t= o > approve the registration of the glue: URN scheme. > > Thanks all, > -- Mike > > -----Original Message----- > From: Peter Saint-Andre <[email protected]> > Sent: Tuesday, June 23, 2026 1:07 PM > To: Michael Jones <[email protected]>; Pamela Dingle < > [email protected]>; Roy T. Fielding <[email protected]>; Ted > Hardie <[email protected]>; [email protected] > Cc: The IESG <[email protected]>; [email protected]; > [email protected]; Chris Inacio <[email protected]>; Anish Karmarkar < > [email protected]>; Apoorav Trehan < > [email protected]>; Babak Jahromi (CELA) <[email protected]= > > 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 schem= e > 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 alphanumeri= c > 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 befor= e > 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 alread= y > 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 an= d > 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=E2= =80=99t > > 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=E2=80=99s arguments for URN registration over URI scheme registrati= on were > > compelling.) > > > > Thank > > you, > > > > -- > > Mike > > > > *From:*Pamela Dingle <[email protected]> > > *Sent:* Monday, June 22, 2026 4:05 PM > > *To:* Peter Saint-Andre <[email protected]>; Roy T. Fielding > > <[email protected]>; Ted Hardie <[email protected]> > > *Cc:* The IESG <[email protected]>; [email protected]; draft-ietf-spice- > > [email protected]; [email protected]; Chris Inacio > > <[email protected]>; Anish Karmarkar <[email protected]>; > > Apoorav Trehan <[email protected]>; Babak Jahromi (CELA) > > <[email protected]> > > *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 =E2=80=93 like khsra# (land) in India or municipali= ty > > 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 =E2=80=98relics=E2=80=99 that loose original meani= ng 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=E2=80=99t see local country specific identifiers ever getting a nam= espace > > (b) physical supply chains have long histories and need to retain some > > context over time as things change > > > > ---------------------------------------------------------------------- > > -- > > > > *From:*Peter Saint-Andre <[email protected] > > <mailto:[email protected]>> > > *Sent:* Friday, June 12, 2026 5:37 PM > > *To:* Roy T. Fielding <[email protected] <mailto:[email protected]>>; > > Ted Hardie <[email protected] <mailto:[email protected]>> > > *Cc:* The IESG <[email protected] <mailto:[email protected]>>; uri- > > [email protected] <mailto:[email protected]> <[email protected] > > <mailto:[email protected]>>; [email protected] > > <mailto:[email protected]> <draft-ietf-spice-glue- > > [email protected] <mailto:[email protected]>>; spice- > > [email protected] <mailto:[email protected]> <[email protected] > > <mailto:[email protected]>>; Chris Inacio <[email protected] > > <mailto:[email protected]>> > > *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=E2=80=AFPM, Ted Hardie <[email protected] = <mailto: > [email protected]>> 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 > > > > --000000000000e17ac006556b5836 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I've been following this thread with great interest an= d not a little curiosity.<div><br></div><div>It seems like there may be som= e folks who are struggling to understand what=C2=A0we are trying to accompl= ish with GLUE.</div><div><br></div><div>Some have pointed out that global b= usiness identification is a major problem. One which led to the creation of= GLEIF, and has led to a number of other organizations pursuing URN registr= ation for individual schemes. This is laudable. This is good. It may even s= olve the problem someday, but in my estimation those solutions are a long w= ay off. Where we agree is that there is a problem and many people are inter= ested in solving it.</div><div><br></div><div>One GLEIF statistic I have se= en repeated often is that over 3 million businesses have obtained an LEI. T= his is great. It is a wonderful step in the right direction, but it is a ti= ny drop in the bucket of the hundreds of millions of businesses and organiz= ations engaged in trade worldwide. GLUE enables existing business identifie= rs to be used in the interim between now and whenever in the future those b= usinesses are able to themselves claim an LEI or GLN.</div><div><br></div><= div>Pam pointed out a clear need for additional tools for identifying busin= esses, ones that are long-lasting, and can be used to help keep the records= being passed about as legible as possible.=C2=A0 Some have argued that suc= h a mess is clearly not something that a URN scheme is appropriate for. Not= in my view. The clear organizational potential that is brought to bear by = the introduction of GLUE identifiers would have a significant impact in the= clarity and legibility of these currently messy and difficult to read docu= ments. They are messy because there isn't a simple scheme that can be u= sed to organize them. That is all GLUE aims to be.</div><div><br></div><div= >Someone mentioned that a global database might be a more appropriate solut= ion than an identifier scheme and an accompanying registry of authorities. = I'm a bit confused what the difference is between a global database and= an IANA registry, except that an IANA registry is easier to find, unburden= ed by corporate interests, and more likely to be a trusted global source of= information.</div><div><br></div><div>I'm fine if GLEIF or GS1 would p= refer they not be listed in the registry, since they have their own URN sch= emes, but such a determination to not be involved completely misses the poi= nt. Demanding to be removed from GLUE is like the producers of some informa= tive reference demanding it be removed from another specification that wish= es to refer to it. Supporters of GLUE are supporters of the great efforts b= eing made by GLEIF and GS1. GLUE is an attempt to make it even easier to us= e those identifier schemes in digital trade credentials, alongside the myri= ad other business and organization identifiers that are in use today.</div>= <div><br></div><div>GLUE is not a business registry. It claims no authority= for determining the realities of business registration beyond the those al= ready possessed by the authorities themselves. GLUE is just a slightly diff= erent way to format the existing identifiers, one that is consistent with t= he requirements of digital identity and trade modernization schemes. It is = paired with what we hope will someday be an expansive registry of organizat= ion identifier authorities. There is no registration scheme too small to fi= t inside GLUE.=C2=A0</div><div><br></div><div>But, it seems to me like all = of that may be beside the point. GLUE isn't some random individual draf= t out of nowhere. GLUE was been adopted by an IETF working group. That work= ing group reviewed and refined the ideas in GLUE over years. The specificat= ion found working group consensus and passed working group last call. To my= understanding it even=C2=A0passed IESG review.</div><div>All that is left = is to register the identifier scheme.</div><div><br></div><div>There have b= een ample examples shared in this thread and others, ones I am not going to= reiterate, that make it seem as though the designated experts are holding = GLUE to a higher bar for URN or URI registration than other schemes have be= en held. I don't believe that the experts are acting inappropriately. I= applaud their caution, but encourage them to act and register GLUE.</div><= div><span style=3D"background-color:transparent"><br></span></div><div><spa= n style=3D"background-color:transparent">GLUE is not going to break the int= ernet. If its=C2=A0detractors are correct, and GLUE sees little to no use i= n industry, then it would certainly not be the first IETF specification to = meet such a fate.</span></div><div>I don't think they are right. I thin= k GLUE can have a positive impact on the disgusting mess that is global bus= iness and organization identification.</div><div><br></div><div>Thank you f= or your time. I apologize for the wall of text.</div><div>tl;dr GLUE is a w= ell-thought out solution to a real problem and it is ready to move forward.= Please register the identifier scheme. URN or URI? honestly whichever woul= d be fine.</div><div><br></div><div>Brent Zundel</div></div><br><div class= =3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr= ">On Wed, Jun 24, 2026 at 11:35=E2=80=AFAM Michael Jones <<a href=3D"mai= lto:[email protected]">[email protected]</a>> wrote:= <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8= ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks Peter,<b= r> <br> To your point about GS1, it's fine for GLUE to not re-register GS1 iden= tifiers because they have already taken it upon themselves to establish a G= S1 URN namespace.=C2=A0 Applications needing URIs for GS1 values can use th= ose URNs.<br> <br> GLUE creates a mechanism for establishing URIs for identifiers in organizat= ions that have not taken it upon themselves to do what GS1 is doing.<br> <br> 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 draf= t currently does.=C2=A0 I would therefore ask the URN designated experts to= approve the registration of the glue: URN scheme.<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks all,<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike<br> <br> -----Original Message-----<br> From: Peter Saint-Andre <<a href=3D"mailto:[email protected]" target=3D= "_blank">[email protected]</a>> <br> Sent: Tuesday, June 23, 2026 1:07 PM<br> To: Michael Jones <<a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a>>; Pamela Dingle <<a href= =3D"mailto:[email protected]" target=3D"_blank">Pamela.Dingle@mic= rosoft.com</a>>; Roy T. Fielding <<a href=3D"mailto:[email protected]= " target=3D"_blank">[email protected]</a>>; Ted Hardie <<a href=3D"ma= ilto:[email protected]" target=3D"_blank">[email protected]</a>>; <a h= ref=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a= ><br> Cc: The IESG <<a href=3D"mailto:[email protected]" target=3D"_blank">iesg@ie= tf.org</a>>; <a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a>; <a href=3D"mailto:spice-= [email protected]" target=3D"_blank">[email protected]</a>; Chris Inacio = <<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a= >>; Anish Karmarkar <<a href=3D"mailto:[email protected]"= target=3D"_blank">[email protected]</a>>; Apoorav Trehan &l= t;<a href=3D"mailto:[email protected]" target=3D"_blank">Apoorav= [email protected]</a>>; Babak Jahromi (CELA) <<a href=3D"mailto:b= [email protected]" target=3D"_blank">[email protected]</a>><br> Subject: Re: [EXTERNAL] Re: [Uri-review] Request to register the glue URI s= cheme<br> <br> Thanks to Pam for the further explanation.<br> <br> I'm struggling to see in clear specifics how a URN namespace or URI sch= eme will help clean up the messy world of supply chain traceability in a wa= y that, say, a shared industry database couldn't do (e.g., a flexible o= pen-source project that attempts to put some measure of order on the chaos)= . How does prepending identifiers with urn:glue or glue: <br> help solve the problem of unknown and in many cases unknowable manufacturer= s, compounded by apparently incompetent authorities for tracking such manuf= acturers? Can we even use the term 'identifier' if the data really = are as dirty as Pam describes, with some of these alphanumeric strings bein= g mere hints and guesses?<br> <br> 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 U= RN namespace is supposed to provide "persistent identification of reso= urces and unique assignment of names in accordance with a common definition= ". However, in this case the data are so dirty that resources (i.e., m= anufacturers) might move from one URN "sub-namespace" to another = in a somewhat random fashion as the traceability experts determine that, sa= y, 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 ob= ject in a library or archive), the problem space here feels almost inherent= ly unmanageable.<br> <br> Furthermore, those of you advocating for a GLUE URN namespace have already = received feedback from at least the GS1 authority (with advance warning tha= t the same might be received from the LEI authority and perhaps others that= have had no reason to pay attention to these IETF<br> discussions) that they want no part of GLUE and do not want their identifie= rs to be re-assigned without their authorization within a GLUE namespace.<b= r> <br> Although I realize that there's a compelling and difficult business pro= blem to be solved here, I ask that you please think outside the box and con= sider 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 R= FC 2141 and RFC 8141.<br> <br> Peter<br> <br> On 6/23/26 11:45 AM, Michael Jones wrote:<br> > Thanks, Pam and Microsoft, for sharing this real-world perspective.=C2= =A0 <br> > Let me reinforce your point that GLUE is intended to bring order to <b= r> > identifiers used in global supply chains in which we practically won= =E2=80=99t <br> > see local country-specific or reginal identifier authorities ever <br> > creating a URN namespace on their own.<br> > <br> > For these practical reasons, I would ask that the URN experts <br> > reconsider approving registering the urn:glue: namespace.=C2=A0 (I ask= for <br> > URN registration rather than URI scheme registration because I believe= <br> > Roy=E2=80=99s arguments for URN registration over URI scheme registrat= ion were<br> > compelling.)<br> > <br> >=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Thank <br> > you,<br> > <br> >=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 -- <br> > Mike<br> > <br> > *From:*Pamela Dingle <<a href=3D"mailto:[email protected]= " target=3D"_blank">[email protected]</a>><br> > *Sent:* Monday, June 22, 2026 4:05 PM<br> > *To:* Peter Saint-Andre <<a href=3D"mailto:[email protected]" targ= et=3D"_blank">[email protected]</a>>; Roy T. Fielding <br> > <<a href=3D"mailto:[email protected]" target=3D"_blank">fielding@gb= iv.com</a>>; Ted Hardie <<a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a>><br> > *Cc:* The IESG <<a href=3D"mailto:[email protected]" target=3D"_blank">= [email protected]</a>>; <a href=3D"mailto:[email protected]" target=3D"_bl= ank">[email protected]</a>; draft-ietf-spice- <br> > <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]= </a>; <a href=3D"mailto:[email protected]" target=3D"_blank">spice-chai= [email protected]</a>; Chris Inacio <br> > <<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]= rg</a>>; Anish Karmarkar <<a href=3D"mailto:anish.karmarkar@microsoft= .com" target=3D"_blank">[email protected]</a>>; <br> > Apoorav Trehan <<a href=3D"mailto:[email protected]" tar= get=3D"_blank">[email protected]</a>>; Babak Jahromi (CELA) <= br> > <<a href=3D"mailto:[email protected]" target=3D"_blank">babakj@m= icrosoft.com</a>><br> > *Subject:* Re: [EXTERNAL] Re: [Uri-review] Request to register the <br= > > glue URI scheme<br> > <br> > Hi all,<br> > <br> > I understand why you all have given us the advice that you have - it <= br> > makes sense from a technical perspective.=C2=A0 Unfortunately what we = are <br> > trying to implement using Glue is not a clean thing.=C2=A0 I am hoping= it <br> > would help to talk about what our real world goals are, in case you <b= r> > can see a path that we cannot, and also just to be sure everyone knows= <br> > that we are not trying to be difficult or to drag everyone through a <= br> > shaggy dog story for no good reason.=C2=A0 Any thoughts you have are v= ery <br> > welcome, and if anyone is interested in getting together to <br> > brainstorm, that would be amazing.<br> > <br> > In the same way that I'm not an expert in URI/URN formats, I'm= not an <br> > expert in supply chain traceability, so I have copied my coworkers <br= > > Anish Karmarkar and Apoorav Trehan in case they can correct any errors= <br> > I introduce here.=C2=A0 Apoorav did give some comments on what I'v= e <br> > written; those comments from the actual supply chain expert are <br> > annotated at the end.<br> > <br> > We have a long-standing problem in the physical supply chain world.=C2= =A0 <br> > Over periods of decades, the many businesses that form the many tiers = <br> > of a given supply chain are incorporating, operating, merging, <br> > acquiring, dying.=C2=A0 This happens globally, across multiple legal <= br> > jurisdictions, and potentially multiple regimes.=C2=A0 Paperwork quali= ty <br> > varies, and the authorities that validate the businesses (which are <b= r> > businesses<br> > themselves) go through their own business lifecycles of growing, <br> > merging, dying.=C2=A0 =C2=A0A given business may register and be vette= d with <br> > numerous authorities, accumulate numerous authority identifiers, and <= br> > cease using numerous identifiers.=C2=A0 But those identifiers may appe= ar in <br> > the supply chain manifests and in multi-tier audit logs, internal <br> > siloed tracking databases and physical paperwork of many of the <br> > businesses in the supply chain ecosystem.=C2=A0 The people notating th= e <br> > identifiers are not the owners of the identifiers, they are low level = <br> > workers who are not validating identifiers, they are simply moving and= copying strings.<br> > Decades later, when investigations might occur or traceability efforts= <br> > might be undergone to decide what product could be affected by an <br> > investigation, those investigators deal with exceptionally dirty data;= <br> > they may not even know that a given authority existed 30 years ago let= <br> > alone that the column of the corrolating identifier is labeled in a <b= r> > way that was implicitly known to from that authority but not <br> > explicitly included.=C2=A0 =C2=A0Our primary issue here is that differ= ent <br> > storage of different identifiers, implicitly namespaced rather than <b= r> > explicitly namespaced and spreading through various data structures <b= r> > creates extremely difficult conditions to find evidence.<br> > <br> > What I am hoping to get done with the glue identifier, is to create an= <br> > identifier that is intended to sit for decades and expected to be <br> > mistyped sometimes, to end up in some column of some database <br> > somewhere that could have lost the original context over multiple <br> > upgrades.=C2=A0 A glue identifier is not (at least in this usage) inte= nded <br> > to be resolvable, it is intended to encapsulate just enough <br> > information that no matter where that identifier drifts to, it retains= <br> > at least a hint of its purpose and provenance.=C2=A0 Enough that a per= son <br> > or process digging through the rubble of a 30-year-old data backup of = <br> > a corporation might have a chance to find the information that matches= <br> > an old manifest.=C2=A0 =C2=A0If a data entry clerk can't be bother= ed to check <br> > that the IANA registry identifier of the chinese subsidiary of an <br> > authority should have a c appended to it and they label it as auth <br= > > instead of authc, the auth encoding is still valuable, because whoever= <br> > is doing the forensic work knows that it is a glue identifier to start= <br> > with and that these mistakes can happen.<br> > <br> > These identifiers will not exist in a perfect world of perfect labels.= =C2=A0 <br> > This is a way for an attribute contract to ask for a business <br> > identifier to be encoded in the payload of attestations as informative= <br> > attributes, without requiring an attribute for every possible business= <br> > authority, but retaining an identifier that means later validation is = possible.<br> >=C2=A0 =C2=A0The scheme for a 10-years-dead business authority will nev= er be <br> > registered; having an admin make up something approximate in a glue <b= r> > identifier could be the best possible outcome even if a different <br> > admin in a different place makes up something different.=C2=A0 It is a= <br> > hint, and that's what we want.<br> > <br> > None of this should be in the spec obviously.=C2=A0 But we are trying = to do <br> > something for a meaningful reason, I believe.=C2=A0 =C2=A0I know it do= esn't <br> > match the goals of your important work.=C2=A0 But I cannot imagine tha= t <br> > there is no place at IETF for a logical and standardized data format= =C2=A0<br> > to contain this kind of imperfect information.=C2=A0 Anything you can = do to <br> > help us resolve this would be appreciated.<br> > <br> > Additional notes from Apoorav:<br> > <br> > @Pamela, I agree with your framing and echo that GLUEID is not trying = <br> > to replace existing identifiers, nor is it trying to create a new <br> > authoritative namespace. It is trying to preserve context across <br> > fragmented, long-lived, and imperfect supply chain records. I feel <br= > > that current URN schemes assume well governed durable namespaces (like= <br> > urn:gln: or urn:gs1) The issue in the physical supply chain that the <= br> > many identities we encounter, specifically in other countries and that= <br> > are historical (old =E2=80=93 like khsra# (land) in India or municipal= ity <br> > identifier in Vietnam) might not have a name space at all. Also over <= br> > time as companies, countries and authorities change we see many <br> > identifiers becoming =E2=80=98relics=E2=80=99 that loose original mean= ing over time <br> > (or can be misused). GlueID helps us to encode those anyway and <br> > maintain some hint of original purpose over time.<br> > <br> > Also, not sure if how to word this, but pushing the URN definition to = <br> > individual organizations does not help solve the issue since (a) I <br= > > don=E2=80=99t see local country specific identifiers ever getting a na= mespace <br> > (b) physical supply chains have long histories and need to retain some= <br> > context over time as things change<br> > <br> > ----------------------------------------------------------------------= <br> > --<br> > <br> > *From:*Peter Saint-Andre <<a href=3D"mailto:[email protected]" tar= get=3D"_blank">[email protected]</a> <br> > <mailto:<a href=3D"mailto:[email protected]" target=3D"_blank">stp= [email protected]</a>>><br> > *Sent:* Friday, June 12, 2026 5:37 PM<br> > *To:* Roy T. Fielding <<a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a> <mailto:<a href=3D"mailto:fielding@gbi= v.com" target=3D"_blank">[email protected]</a>>>; <br> > Ted Hardie <<a href=3D"mailto:[email protected]" target=3D"_blank"= >[email protected]</a> <mailto:<a href=3D"mailto:[email protected]" ta= rget=3D"_blank">[email protected]</a>>><br> > *Cc:* The IESG <<a href=3D"mailto:[email protected]" target=3D"_blank">= [email protected]</a> <mailto:<a href=3D"mailto:[email protected]" target=3D"_bl= ank">[email protected]</a>>>; uri- <br> > <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</= a> <mailto:<a href=3D"mailto:[email protected]" target=3D"_blank">uri-= [email protected]</a>> <<a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a> <br> > <mailto:<a href=3D"mailto:[email protected]" target=3D"_blank">ur= [email protected]</a>>>; <a href=3D"mailto:draft-ietf-spice-glue-id@i= etf.org" target=3D"_blank">[email protected]</a> <br> > <mailto:<a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a>> <draft-ietf-spice-= glue- <br> > <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a> <m= ailto:<a href=3D"mailto:[email protected]" target=3D"_blank= ">[email protected]</a>>>; spice- <br> > <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</= a> <mailto:<a href=3D"mailto:[email protected]" target=3D"_blank">sp= [email protected]</a>> <<a href=3D"mailto:[email protected]" ta= rget=3D"_blank">[email protected]</a> <br> > <mailto:<a href=3D"mailto:[email protected]" target=3D"_blank">= [email protected]</a>>>; Chris Inacio <<a href=3D"mailto:inaci= [email protected]" target=3D"_blank">[email protected]</a> <br> > <mailto:<a href=3D"mailto:[email protected]" target=3D"_blank">inacio= @cert.org</a>>><br> > *Subject:* [EXTERNAL] Re: [Uri-review] Request to register the glue <b= r> > URI scheme<br> > <br> > On 6/12/26 12:34 PM, Roy T. Fielding wrote:<br> >>> On Jun 11, 2026, at 11:44=E2=80=AFPM, Ted Hardie <<a href= =3D"mailto:[email protected]" target=3D"_blank">[email protected]</a> <= ;mailto:<a href=3D"mailto:[email protected]" target=3D"_blank">ted.ietf@gm= ail.com</a>>> wrote:<br> >>><br> >>> Hi Roy,<br> >>><br> >>> As you can tell from reading this specification the glue ident= ifier <br> >>> has elements that are not directly managed and the other bodie= s <br> >>> minting those elements have not agreed to behave as a part of = URN <br> >>> namespace authority.=C2=A0 So by the intent-based formulation = given <br> >>> below, these do not qualify.<br> >>><br> >>> We can certainly re-open the discussion on what the identifier= <br> >>> landscape within this realm should look like; I think my first= such <br> >>> discussion was at the first Stockholm IETF more than thirty ye= ars <br> >>> ago, and I suspect the discussion will outlast me.=C2=A0 But I= think any <br> >>> changes from that discussion would have to apply to later work= than <br> >>> this, which is otherwise ready to proceed.<br> >> <br> >> Yes, 1993 in my case, but sadly lost in the former bunyip archives= . =C2=A0<br> >> I agree with your assessment. Thanks for taking the time to explai= n it.<br> >> <br> >> However, I think there should be a distinction made between mintin= g <br> >> individual URI schemes to carry a third-party identifier, which is= <br> >> something we have approved many times, versus minting a single &qu= ot;glue"<br> >> scheme as a separate authority for future third-party namespaces. = URN <br> >> was approved for that because it had a specific purpose to justify= it.<br> >> <br> >> In contrast, "glue" is just a restatement of URI at one = level down. <br> >> The syntax prepends "glue:", schemes become new namespac= e <br> >> authorities, and IANA is expected to generate a new administrative= <br> >> hierarchy to maintain registries of arbitrary authorities under th= e <br> >> glue scheme. I don't see any reason to approve that when the s= ame <br> >> people can just as easily use existing or new authority-specific <= br> >> identifier schemes (or URN nids) as normal URIs.<br> >> <br> >> I don't think SPICE was given the remit to produce a URN-alter= native. <br> >> I think that would require a much larger discussion, IETF-wide, an= d I <br> >> see no justification to open that can of worms.<br> >> Hence, my suggestion is to reject this draft as an IETF publicatio= n. <br> >> If the authors want a single reference syntax, see RFC3986.<br> >> If they want IETF-approved names for GS1, GLEIF, DUNS, PEN, and <b= r> >> ISO6523, then register them as new URI schemes.<br> >> <br> >> If there is a technical reason for their inability to do the same = <br> >> thing that every other IETF protocol does, please explain that in = the proposal.<br> > <br> > Hi Roy,<br> > <br> > This is basically the same reasoning we applied from a URN <br> > perspective, so I can't disagree with your assessment.<br> > <br> > Peter<br> > <br> <br> </blockquote></div> --000000000000e17ac006556b5836-- --===============8807549855107338662== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KdXJuIG1haWxp bmcgbGlzdCAtLSB1cm5AaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byB1 cm4tbGVhdmVAaWV0Zi5vcmcK --===============8807549855107338662==--