[urn] Re: Proposing a way forward re: GLUE and "third-pa rty" registration

--===============0033684427078073146==
Content-Type: multipart/alternative; boundary="0000000000008b44af064f5a447b"

--0000000000008b44af064f5a447b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Forgive the top posting; this is mostly a meta comment.

While there have been various attempts in the past to limit the usage of
specific URI schemes by preventing their registration, that was not much of
a success and the current document puts a priority on avoiding collision
instead.  That's why the provisional registration bar is as low as it is.

As a result, if the proponents want a glue URI scheme instead of a GLUE
URN, a provisional is theirs for the asking.  So I personally suggest that
the question for any URI reviewers would not be:  "How. do we stop this?"
but rather  "What would make this a scheme suitable for permanent
registration?"  To put it another way, rather than trying to stop it, we
should ask what would make it better (or "good enough").

>From my perspective, that are two aspects to that, one being a clear
explanation of the scope of usage, limited to within these credential
contexts, and the second being that the registered GLUE authorities consent
and cooperate with the registration.  That will help ensure that these are
well-scoped adjuncts to the normal usage of these identifiers and not an
attempt to provide a different authority over the same identifier space.

Your mileage may vary, of course.

regards,

Ted Hardie

On Mon, Apr 13, 2026 at 3:38=E2=80=AFPM Peter Saint-Andre <stpeter@stpeter.=
im>
wrote:

> On 4/13/26 8:20 AM, Henry S. Thompson wrote:
> > Peter Saint-Andre writes:
> >
> >> ...
> >
> >> Personally I'd rather get it right than get it done quickly. However,
> >> if folks are in a hurry then I think we already have a proposed
> >> solution: define a `glue` URI scheme.
> >
> > I remain unconvinced that this is any better.
> >
> > If and when this comes forward to uri-review, I for one will lobby for
> > a thorough consideration of the appropriateness of third-party URI
> > schemes, their compatibility with 3896, 7595 and 8820, as well as
> > [webarch], and will seek to to involve the W3C Technical Architecture
> > Group.
>
> Henry, I understand your concerns. For what it's worth, I don't like the
> whole idea of third-party registration or incorporation, because it
> seems to me that the right way to go about this kind of thing is to work
> with the creators/maintainers of the other identifier systems. With
> respect to GLUE specifically, I did not mean to imply that venue
> shopping is appropriate. On the other hand, it is not within the remit
> of the URN namespaces review team to make pronouncements about URIs or
> wider IETF policies. To my mind, third-party URN namespace registrations
> are inconsistent with the principles for managing the URN ecosystem so
> we're on solid ground to not approve the `glue` namespace request, but
> the broader questions need to be discussed in a less obscure venue (I'm
> not sure which, perhaps the [email protected] list).
>
> Peter
>
> _______________________________________________
> urn mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

--0000000000008b44af064f5a447b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-size:small">For=
give the top posting; this is mostly a meta comment.</div><div class=3D"gma=
il_default" style=3D"font-size:small"><br></div><div class=3D"gmail_default=
" style=3D"font-size:small">While there have been various attempts in the p=
ast to limit the usage of specific URI schemes by preventing their registra=
tion, that was not much of a success and the current document puts a priori=
ty on avoiding collision instead.=C2=A0 That&#39;s why the provisional regi=
stration bar is as low as it is.</div><div class=3D"gmail_default" style=3D=
"font-size:small"><br></div><div class=3D"gmail_default" style=3D"font-size=
:small">As a result, if the proponents want a glue URI scheme instead of a =
GLUE URN, a provisional is theirs for the asking.=C2=A0 So I personally sug=
gest that the question for any URI reviewers would not be:=C2=A0 &quot;How.=
 do we stop this?&quot; but rather=C2=A0 &quot;What would make this a schem=
e suitable for permanent registration?&quot;=C2=A0 To put it another way, r=
ather than trying to stop it, we should ask what would make it better (or &=
quot;good enough&quot;).</div><div class=3D"gmail_default" style=3D"font-si=
ze:small"><br></div><div class=3D"gmail_default" style=3D"font-size:small">=
>From my perspective, that are two aspects to that, one being a clear explan=
ation of the scope of usage, limited to within these credential contexts, a=
nd the second being that the registered GLUE authorities consent and cooper=
ate with the registration.=C2=A0 That will help ensure that these are well-=
scoped adjuncts to the normal usage of these identifiers and not an attempt=
 to provide a different authority over the same identifier space.</div><div=
 class=3D"gmail_default" style=3D"font-size:small"><br></div><div class=3D"=
gmail_default" style=3D"font-size:small">Your mileage may vary, of course.<=
/div><div class=3D"gmail_default" style=3D"font-size:small"><br></div><div =
class=3D"gmail_default" style=3D"font-size:small">regards,</div><div class=
=3D"gmail_default" style=3D"font-size:small"><br></div><div class=3D"gmail_=
default" style=3D"font-size:small">Ted Hardie</div></div><br><div class=3D"=
gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On=
 Mon, Apr 13, 2026 at 3:38=E2=80=AFPM Peter Saint-Andre &lt;<a href=3D"mail=
to:[email protected]">[email protected]</a>&gt; wrote:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">On 4/13/26 8:20 AM, Henry S. Thomp=
son wrote:<br>
&gt; Peter Saint-Andre writes:<br>
&gt; <br>
&gt;&gt; ...<br>
&gt; <br>
&gt;&gt; Personally I&#39;d rather get it right than get it done quickly. H=
owever,<br>
&gt;&gt; if folks are in a hurry then I think we already have a proposed<br=
>
&gt;&gt; solution: define a `glue` URI scheme.<br>
&gt; <br>
&gt; I remain unconvinced that this is any better.<br>
&gt; <br>
&gt; If and when this comes forward to uri-review, I for one will lobby for=
<br>
&gt; a thorough consideration of the appropriateness of third-party URI<br>
&gt; schemes, their compatibility with 3896, 7595 and 8820, as well as<br>
&gt; [webarch], and will seek to to involve the W3C Technical Architecture<=
br>
&gt; Group.<br>
<br>
Henry, I understand your concerns. For what it&#39;s worth, I don&#39;t lik=
e the <br>
whole idea of third-party registration or incorporation, because it <br>
seems to me that the right way to go about this kind of thing is to work <b=
r>
with the creators/maintainers of the other identifier systems. With <br>
respect to GLUE specifically, I did not mean to imply that venue <br>
shopping is appropriate. On the other hand, it is not within the remit <br>
of the URN namespaces review team to make pronouncements about URIs or <br>
wider IETF policies. To my mind, third-party URN namespace registrations <b=
r>
are inconsistent with the principles for managing the URN ecosystem so <br>
we&#39;re on solid ground to not approve the `glue` namespace request, but =
<br>
the broader questions need to be discussed in a less obscure venue (I&#39;m=
 <br>
not sure which, perhaps the <a href=3D"mailto:[email protected]" target=3D"_blan=
k">[email protected]</a> list).<br>
<br>
Peter<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>

--0000000000008b44af064f5a447b--


--===============0033684427078073146==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KdXJuIG1haWxp
bmcgbGlzdCAtLSB1cm5AaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byB1
cm4tbGVhdmVAaWV0Zi5vcmcK

--===============0033684427078073146==--