[urn] Re: Request to register urn:glue

Thanks for your insightful review comments, Dale!  Please review the changes in https://github.com/ietf-wg-spice/draft-ietf-spice-glue-id/pull/73, which endeavor to address your and Peter's feedback.  Some additional replies to your comment are inline below, prefixed by "Mike>".

-----Original Message-----
From: Dale R. Worley <[email protected]> 
Sent: Thursday, March 5, 2026 8:37 AM
To: Michael Jones <[email protected]>
Cc: [email protected]; Paul Wouters <[email protected]>; [email protected]; Amanda Baber <[email protected]>
Subject: Re: [urn] Request to register urn:glue

Comments on draft-ietf-spice-glue-id-07:

2.1.  Uniqueness and Namespacing

   Each GLUE URI MUST be globally unique.

   An organization can be identified by multiple GLUE URIs, but each
   GLUE URI can only refer to a single organization.

The first of these sentences doesn't make much sense, since of course "any two GLUE URIs" means any two that are different.  All of the meaning you want is captured in the second sentence.

Mike> See the revised sentence in the PR.

   It is assumed that most registered organizational entity
   identification schemes already handle any necessary namespacing as
   part of the External Identifier.  However, if collisions are possible
   within the set of possible external identifiers for an Authority
   Identifier scheme, then further namespacing is necessary at the GLUE
   URI level.  Such namespacing MUST be done using the Authority
   Identifier.  The combination of the Authority Identifier and the
   External Identifier MUST result in a unique GLUE URI.

The difficulty with this paragraph is that the term "namespacing"
isn't well-defined.  Pretty much all of the meaning you want is captured in "each GLUE URI can only refer to a single organization"
above.  It seems to me that it would be best to omit this paragraph.

Mike> I applied your suggested wording and Peter's.  I didn't delete the paragraph, because it contains information useful to help readers understand the model.

3.  GLUE URIs

You probably want to title this section "GLUE URNs".

Mike> Done.  Both you and Peter made this kind of suggestion.

   GLUE URIs comply with [RFC3986].

Why doesn't this say "GLUE URNs comply with [RFC38141]."?

   They begin with urn:glue: and are ...

This would read better as

   They begin with "urn:glue:" and are ...

as is the style elsewhere in the document.

Mike> Done

   There is a limit of 1000 characters for an External Identifier.

Given that this limit is much larger than we expect to need in practice, it seems to me that you might instead want to limit the URN's overall length to 1023 characters or less to avoid data processing systems treating GLUE URNs as "potentially large" objects.

The current total limit will be 1060 characters.  That doesn't seem "potentially large" to me.  Is there a meaningful difference between 1023 and 1060, other than the former is a power-of-two-minus-one?

   Consequently,
   GLUE URIs do 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.

I'm not sure you want to use "canonical" here; if you speak of "canonical form" you imply that there are other forms as well, and in that case, there might be a defined form that uses only the permitted characters.  So I think you want to say something like:

   Consequently, GLUE URIs do not support representation of External
   Identifiers which include non-ASCII characters.  This specification
   is therefore limited to identifier systems with representations
   that are fully within the permitted character set.

Mike> Done

--

   It is specific to the Authority Identifier whether the
   External Identifiers are case-insensitive or case-sensitive.  When
   they are case-insensitive, the canonical form is lowercase and
   documents that specify External Identifiers must do so with lowercase
   letters.

I suggest that you avoid having "for some authorities the external identifier is case sensitive and for some it is case-insensitive"
because that becomes a nightmare to implement:  proper equivalence-testing code needs to be continuously updated based on new authority registrations.

Also, despite the statement "It is specific to the Authority Identifier whether the External Identifiers are case-insensitive or case-sensitive", the registrations in sec. 7.1.2 do not state for each authority whether the external identifiers are case-sensitive.  This suggests you haven't thought through all of the complexities involved.

To avoid trouble, I suggest that if the authority considers its identifiers to be case-insensitive, it should only create GLUE URNs in one case or the other.  The current document suggests that you want it to be "MUST be lower-case".  But for some reason, sec. 4.1.1 contradicts that, providing a "urn:glue:lei" URN in upper case.  So maybe you want to just require the authority to pick one case and stick with it.

Mike> Thanks for this useful set of observations!  I've reworked the comparisons description to always enable the use of case-sensitive comparisons independent of the Authority.

4.  GLUE Authority Identifiers

This section list 5 authorities, which are registered in section 7.1.2.  Have your verified that when you mention e.g. "GS1" that it is completely unambiguous what character sequence is intended for the external identifier without any further explanation.

My quick check turns up that DUNS numbers are sometimes expressed using hyphens, which appear to be non-significant:  "A D-U-N-S number is a unique nine-digit identifier assigned by Dun & Bradstreet (D&B) to legally identify businesses, such as 12-345-6789 or 150483782. It is used to verify company identity, creditworthiness, and to register for government contracts or grants."

There are also suggestions that ISO/IEC 6523 identifiers may sometimes be considered to contain colons, which are of course forbidden by the external identifier syntax:  "ISO/IEC 6523 provides a standardized format for uniquely identifying organizations in electronic business, structured as ICD:OrganizationIdentifier. A common example is an Australian Business Number (ABN), represented as 0151:55609885501, where '0151' is the International Code Designator (ICD) for the ABN. Other examples include DUNS (0060) and LEI codes (0199)."

And indeed, since for some future authorities this question will arise, you need some place in the authority registration template to document clearly what form of the identifier is to be used as the external identifier.

Mike> Again, this was super useful feedback.  See the new text on omitting optional characters, case-folding to lowercase, and substituting for colon characters.  And especially, see the new "Transformation Rules" registry field motivated by this set of your comments.

4.1.  Equivalence to Similar URIs

   A GLUE URI is an identifier in a distinct URN namespace.  By default,
   a GLUE URI is not equivalent to any other URI, including a URI
   defined by the referenced authority's own namespace.  Equivalence
   between a GLUE URI and a non-GLUE URI exists only when explicitly
   specified for a given Authority Identifier.

As in the discussion for sec. 3, allowing each registration to specify equivalence to other URNs that a generic equivalence-testing routine has to understand is a recipe for confusion.  Better to allow that the authority can define an equivalence that applications that understand that particular authority identifier can apply but not require a general equivalence-tester to understand.

Mike> I added text motivated by this comment on not requiring implementations to understand equivalencies.

5.  Security Considerations

   Security considerations for URNs can be found in [RFC2141].

Since RFC 2141 was obsoleted by RFC 8141, why doesn't this reference 8141?

Mike> Done

Dale

				Thanks again!
				-- Mike

_______________________________________________
urn mailing list -- [email protected]
To unsubscribe send an email to [email protected]