[art] Re: [SPICE] draft-ietf-spice-glue-id-04 ietf last call Artart review

[Brent Zundel <[e-mail]>]

Patrik,

Thank you for your review.
We have raised a PR in response and invite your comments there:
https://github.com/ietf-wg-spice/draft-ietf-spice-glue-id/pull/60

On Sun, Feb 1, 2026 at 6:25 PM Patrik Fältström via Datatracker <
[e-mail]> wrote:

> Document: draft-ietf-spice-glue-id
> Title: GLobal Unique Enterprise (GLUE) Identifiers
> Reviewer: Patrik Fältström
> Review result: Ready with Nits
>
> 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.
>
>
> --
> SPICE mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>


-- 

Brent Zundel
Standards Architect | Yubico <http://www.yubico.com/>