[Uri-review] Further insight [urn] Re: [EXTERNAL] Re : Request to register the glue URI scheme
Tom Roberts <[email protected]> Sun, 28 Jun 2026 10:11:02 +0200
| Newsgroups | gmane.ietf.uri-review,gmane.ietf.urn |
|---|---|
| Message-ID | <CACszovQ-eHF5MOi+JKEWcVCnnxxOHHy8_WGBfbfs+cyahMRMMQ@mail.gmail.com> |
--===============2007418225003675881== Content-Type: multipart/alternative; boundary="000000000000a5435706554be236" --000000000000a5435706554be236 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Good day, I've continued to follow this discussion since my earlier posts on the urn list, and I'd like to add one concrete data point from inside an SDO that is facing very much the same problem GLUE is trying to solve. I think it speaks directly to the question now in front of both the URN and URI reviewers. In the SDMX community (ISO 17369), we are in the final stages of registering our own urn:sdmx namespace, with the European Central Bank acting as secretariat; it goes to our governing board this month. Well before that registration, we decided to stand up a working resolver at https://urn.sdmx.io, because our members, the BIS, ECB, Eurostat, IMF, OECD, the UN, the World Bank, and the ILO needed structured data to be resolvable across institutions and jurisdictions. I mention this not as a technical aside, but because it is, in real time, an example of the model this thread has converged on: the authority that defines the identifiers registers the namespace and takes responsibility for it. That is precisely what GLUE sets aside, and it is being done by exactly the kind of organisation GLUE assumes will never do it. I've read Pam's description of the supply-chain traceability problem carefully, and I don't doubt it is real, decades-old, mistyped, decontextualised identifiers drifting through dirty databases is a genuine and hard problem. But I would gently agree with Peter here: if those strings really are "hints and guesses," they don't carry the persistence and uniqueness that make a URN a URN, and wrapping them in a new un-resolvable scheme doesn't supply the provenance the use case actually needs. Meanwhile, for the clean, well-governed systems GLUE also incorporates LEI, GS1, ISO 20022, the governed infrastructure already exists. GLUE therefore seems to fall between two stools: too dirty to meet URN semantics on the one side, and duplicating identifier systems that already have authorities and resolution on the other. The scale on the clean side is not small. The active LEI population passed 3 million this year, with over 3.2 million issued in total, backed by GLEIF's global network of issuers, the Global LEI Index resolver, and now the vLEI for real-time organisational verification. ISO 20022 whose migration only completed in November 2025 already has urn:swift: under RFC 3615. And these authorities are increasingly registering their own namespaces rather than waiting: Chris Day at GS1 has asked not to be incorporated by GLUE and is pursuing its own URN, and SDMX is doing the same. Peter raised the idea of a shared industry database as an alternative; in these domains, the resolvers the authorities already operate are effectively that database. I remain a non-voting participant here, and I defer entirely to the designated URI: and URN: experts on the outcome. But from the practitioner's side, the live evidence increasingly points one way: the originating-authority model works, the authorities are actively adopting it, and GLUE's value rests on a premise that these organisations will not act for themselves, that is being overtaken by events. I would respectfully suggest that is worth weighing before the urn:glue: question is reopened. <http://smartxdata.com/> *Tom Roberts* *Chief Data Officer / Founder* *ISO 17369 TWG Member* *BSI IST/12 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 Wed, Jun 24, 2026 at 8:11=E2=80=AFPM Michael Jones <michael_b_jones@hotm= ail.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 > > > > _______________________________________________ > urn mailing list -- [email protected] > To unsubscribe send an email to [email protected] > --000000000000a5435706554be236 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div> <p class=3D"gmail-p1" style=3D"margin:0px;font-style:normal;font-variant:no= rmal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;f= ont-stretch:normal;font-size:13px;line-height:normal;font-family:"Helv= etica Neue"">Good day,</p> <p class=3D"gmail-p2" style=3D"margin:0px;font-style:normal;font-variant:no= rmal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;f= ont-stretch:normal;font-size:13px;line-height:normal;font-family:"Helv= etica Neue";min-height:15px"><br></p> <p class=3D"gmail-p1" style=3D"margin:0px;font-style:normal;font-variant:no= rmal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;f= ont-stretch:normal;font-size:13px;line-height:normal;font-family:"Helv= etica Neue"">I've continued to follow this discussion since my ear= lier posts on the urn list, and I'd like to add one concrete data point= from inside an SDO that is facing very much the same problem GLUE is tryin= g to solve. I think it speaks directly to the question now in front of both= the URN and URI reviewers.</p> <p class=3D"gmail-p2" style=3D"margin:0px;font-style:normal;font-variant:no= rmal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;f= ont-stretch:normal;font-size:13px;line-height:normal;font-family:"Helv= etica Neue";min-height:15px"><br></p> <p class=3D"gmail-p1" style=3D"margin:0px;font-style:normal;font-variant:no= rmal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;f= ont-stretch:normal;font-size:13px;line-height:normal;font-family:"Helv= etica Neue"">In the SDMX community (ISO 17369), we are in the final st= ages of registering our own urn:sdmx namespace, with the European Central B= ank acting as secretariat; it goes to our governing board this month. Well = before that registration, we decided to stand up a working resolver at <a h= ref=3D"https://urn.sdmx.io">https://urn.sdmx.io</a>, because our members, t= he BIS, ECB, Eurostat, IMF, OECD, the UN, the World Bank, and the ILO neede= d structured data to be resolvable across institutions and jurisdictions. I= mention this not as a technical aside, but because it is, in real time, an= example of the model this thread has converged on: the authority that defi= nes the identifiers registers the namespace and takes responsibility for it= . That is precisely what GLUE sets aside, and it is being done by exactly t= he kind of organisation GLUE assumes will never do it.</p> <p class=3D"gmail-p2" style=3D"margin:0px;font-style:normal;font-variant:no= rmal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;f= ont-stretch:normal;font-size:13px;line-height:normal;font-family:"Helv= etica Neue";min-height:15px"><br></p> <p class=3D"gmail-p1" style=3D"margin:0px;font-style:normal;font-variant:no= rmal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;f= ont-stretch:normal;font-size:13px;line-height:normal;font-family:"Helv= etica Neue"">I've read Pam's description of the supply-chain t= raceability problem carefully, and I don't doubt it is real, decades-ol= d, mistyped, decontextualised identifiers drifting through dirty databases = is a genuine and hard problem. But I would gently agree with Peter here: if= those strings really are "hints and guesses," they don't car= ry the persistence and uniqueness that make a URN a URN, and wrapping them = in a new un-resolvable scheme doesn't supply the provenance the use cas= e actually needs. Meanwhile, for the clean, well-governed systems GLUE also= incorporates LEI, GS1, ISO 20022, the governed infrastructure already exis= ts. GLUE therefore seems to fall between two stools: too dirty to meet URN = semantics on the one side, and duplicating identifier systems that already = have authorities and resolution on the other.</p> <p class=3D"gmail-p2" style=3D"margin:0px;font-style:normal;font-variant:no= rmal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;f= ont-stretch:normal;font-size:13px;line-height:normal;font-family:"Helv= etica Neue";min-height:15px"><br></p> <p class=3D"gmail-p1" style=3D"margin:0px;font-style:normal;font-variant:no= rmal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;f= ont-stretch:normal;font-size:13px;line-height:normal;font-family:"Helv= etica Neue"">The scale on the clean side is not small. The active LEI = population passed 3 million this year, with over 3.2 million issued in tota= l, backed by GLEIF's global network of issuers, the Global LEI Index re= solver, and now the vLEI for real-time organisational verification. ISO 200= 22 whose migration only completed in November 2025 already has urn:swift: u= nder RFC 3615. And these authorities are increasingly registering their own= namespaces rather than waiting: Chris Day at GS1 has asked not to be incor= porated by GLUE and is pursuing its own URN, and SDMX is doing the same. Pe= ter raised the idea of a shared industry database as an alternative; in the= se domains, the resolvers the authorities already operate are effectively t= hat database.</p> <p class=3D"gmail-p2" style=3D"margin:0px;font-style:normal;font-variant:no= rmal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;f= ont-stretch:normal;font-size:13px;line-height:normal;font-family:"Helv= etica Neue";min-height:15px"><br></p> <p class=3D"gmail-p1" style=3D"margin:0px;font-style:normal;font-variant:no= rmal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;f= ont-stretch:normal;font-size:13px;line-height:normal;font-family:"Helv= etica Neue"">I remain a non-voting participant here, and I defer entir= ely to the designated URI: and URN: experts on the outcome. But from the pr= actitioner's side, the live evidence increasingly points one way: the o= riginating-authority model works, the authorities are actively adopting it,= and GLUE's value rests on a premise that these organisations will not = act for themselves, that is being overtaken by events. I would respectfully= suggest that is worth weighing before the urn:glue: question is reopened.<= /p></div><div><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr"><= p class=3D"MsoNormal"><a href=3D"http://smartxdata.com/" target=3D"_blank">= <span style=3D"color:windowtext;text-decoration:none"><br></span></a></p> <p class=3D"MsoNormal"><b><font color=3D"#3d85c6">Tom Roberts</font></b></p= > <p class=3D"MsoNormal"><b><font color=3D"#000000">Chief Data Officer / Foun= der</font></b><br></p><p class=3D"MsoNormal"><b><font color=3D"#000000">ISO= 17369 TWG Member</font></b></p><p class=3D"MsoNormal"><b style=3D"color:rg= b(34,34,34)"><font color=3D"#000000">BSI IST/12 Member</font></b></p><p cla= ss=3D"MsoNormal"><b><span lang=3D"FR" style=3D"font-size:8pt"><font color= =3D"#3d85c6">Mobile=C2=A0</font></span></b><b><span lang=3D"FR" style=3D"fo= nt-size:8pt"><font color=3D"#3d85c6">CZ:</font><font color=3D"#222222"> +42= 0 773 532 216</font></span></b></p><p class=3D"MsoNormal"><b><span lang=3D"= FR" style=3D"font-size:8pt"><font color=3D"#3d85c6">Mobile US</font><font c= olor=3D"#674ea7">:=C2=A0</font><font style=3D"color:rgb(34,34,34)">+1 689-8= 37-7529</font></span></b></p><p class=3D"MsoNormal"><b><span lang=3D"FR" st= yle=3D"font-size:8pt"><font color=3D"#3d85c6">Email: <a href=3D"mailto:data= [email protected]" target=3D"_blank">[email protected]</a></font></sp= an></b></p> <p class=3D"MsoNormal"><b><span style=3D"font-size:8pt" lang=3D"FR">=C2=A0<= /span></b><span style=3D"font-size:8pt"></span></p> <p class=3D"MsoNormal"><img width=3D"200" height=3D"56" src=3D"https://ci3.= googleusercontent.com/mail-sig/AIorK4ziqQBmlvKl7lPZaxdTPpoq8lAfp1lYTcxzNnmT= FSObgiBoB3rSyZw899ztTcEYVq4UEXSn30o" style=3D"color: rgb(112, 173, 71); fon= t-size: 8pt;"><br></p><p class=3D"MsoNormal"><span style=3D"color:windowtex= t;text-decoration:none"></span></p><p class=3D"MsoNormal"><span style=3D"fo= nt-size:8pt;color:rgb(112,173,71)"></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:8pt;color:rgb(112,173,71)">= =C2=A0</span><span style=3D"margin:0px;padding:0px;font-family:Arial,Helvet= ica,sans-serif;line-height:1.35;color:rgb(102,102,102);font-size:11px">CONF= IDENTIAL COMMUNICATION: This email message and any attachment may contain=20 privileged and confidential information intended only for the use of the individual or entity to which the email is addressed. If the reader of=20 this message is not the intended recipient or the employee or agent=20 responsible to deliver it to the intended recipient, that person is=20 hereby notified that any dissemination, distribution or copying of this=20 communication is prohibited. If you have received this communication in=20 error, please notify us as soon as possible by telephone (collect calls=20 will be accepted). Thank you for your cooperation and assistance.</span></p= ><p class=3D"MsoNormal"><a href=3D"https://twitter.com/macktony" target=3D"= _blank"><span style=3D"color:windowtext;text-decoration:none"></span></a></= p> <p class=3D"MsoNormal">=C2=A0</p> =C2=A0 <span style=3D"color:white"></span><span style=3D"font-size:8pt;color:rgb(1= 12,173,71)"></span></div></div></div><br></div><br><div class=3D"gmail_quot= e gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jun = 24, 2026 at 8:11=E2=80=AFPM Michael Jones <<a href=3D"mailto:michael_b_j= [email protected]">[email protected]</a>> wrote:<br></div><bloc= kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:= 1px solid rgb(204,204,204);padding-left:1ex">Thanks Peter,<br> <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> _______________________________________________<br> urn mailing list -- <a href=3D"mailto:[email protected]" target=3D"_blank">urn@i= etf.org</a><br> To unsubscribe send an email to <a href=3D"mailto:[email protected]" targe= t=3D"_blank">[email protected]</a><br> </blockquote></div></div> --000000000000a5435706554be236-- --===============2007418225003675881== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVXJpLXJldmll dyBtYWlsaW5nIGxpc3QgLS0gdXJpLXJldmlld0BpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5k IGFuIGVtYWlsIHRvIHVyaS1yZXZpZXctbGVhdmVAaWV0Zi5vcmcK --===============2007418225003675881==--