IETF Last Call Review of draft-ietf-spice-glue-id-04
review-ietf-spice-glue-id-04-artart-lc-faltstrom-2026-02-01-00

I have two related architectural clarity concerns that I believe would benefit
from explicit treatment in the document.

1. Internationalisation and character set constraints

In Sections 3.1 (Authority Identifier) and 3.2 (External Identifier), the ABNF
restricts both components to a limited US-ASCII character set (ALPHA / DIGIT /
"+" / "-" / ".") and does not permit percent-encoding. As a result, GLUE URNs
cannot represent identifiers that contain non-ASCII characters, even via
encoding.

This may be intentional given the currently listed identifier schemes, but the
document does not state that non-ASCII identifiers are out of scope. As
written, the syntax prevents future use with identifier systems whose canonical
representations include non-ASCII characters.

Suggested clarification text (for Section 2 or Section 3):

"A GLUE URN is defined over the restricted US-ASCII syntax specified in
Sections 3.1 and 3.2. Percent-encoding is not permitted. Consequently, GLUE
does not support representation of external identifiers whose canonical form
includes non-ASCII characters. This specification is therefore limited to
identifier systems whose canonical representations are fully within the
permitted character set."

Alternatively, if non-ASCII identifiers are expected to be supported in the
future, the document would need to specify encoding and canonicalization rules.

2. Relationship between GLUE URNs and other URN namespaces

The document defines GLUE URNs of the form:

urn:glue:authority:external-id

The document also provides at least one explicit example (Section 4.1) where a
GLUE URN is stated to be equivalent to a URN defined in another namespace (for
LEI). However, the document does not explicitly state the general relationship
between a GLUE URN and a hypothetical native URN defined by the referenced
authority, for example urn:foo:x.

Under the URN architecture, different namespace identifiers imply different
identifiers by default, even if the namespace-specific strings appear similar.
Therefore, absent an explicit statement to the contrary, urn:glue:foo:x and
urn:foo:x are distinct identifiers.

Because the document includes an explicit equivalence in at least one case,
there is a risk that implementers or relying parties will generalize from that
example and assume equivalence or interchangeability between GLUE URNs and
non-GLUE URNs for other authorities, even when no such equivalence has been
specified.

Suggested clarification text (for Section 2, Section 4, or a new semantics
subsection):

"A GLUE URN is an identifier in a distinct URN namespace. By default, a GLUE
URN is not equivalent to any other URN, including a URN defined by the
referenced authority's own namespace. Equivalence between a GLUE URN and a
non-GLUE URN exists only when explicitly specified for a given Authority
Identifier. Implementations and relying parties MUST NOT assume equivalence
between GLUE URNs and non-GLUE URNs unless such equivalence is explicitly
defined by the authority or documented in the relevant registry entry."

I believe clarifying this point would reduce the risk of incorrect assumptions
about identifier equivalence and improve interoperability, without changing the
core design intent of the document.