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.