[urn] Re: Incorporating other identifiers into URIs

Peter Saint-Andre <[email protected]> Thu, 19 Mar 2026 08:39:37 -0600
Newsgroups gmane.ietf.urn
Message-ID <[email protected]>
On 3/18/26 8:52 PM, Dale R. Worley wrote:

> In regard to the *semantics*, I think it is reasonable to state in the
> registration that the semantics are entirely delegated to the maintainer
> of the external identifier.  A statement like
> 
>      The URN "urn:foobar:upc:nnnnnnnnnnnn" names the Universal Product
>      Code nnnnnnnnnnnn.
> 
> seems to me to be well-defined, and it doesn't infringe on the authority
> of the Universal Produce Code organization, because it slavishly follows
> whatever that authority says about nnnnnnnnnnnn.

This sidesteps the question of whether the originating authority wishes 
its identifiers to be incorporated. It seems to me that as a matter of 
professional courtesy and to avoid any misunderstandings the IETF should 
not incorporate identifier systems defined by other standards 
development organizations without consultation and prior agreement. 
Anything less could be perceived as rather aggressive.

> *Syntactically*, such an incorporation should be aware of any
> "normalization" rules that are used for the external identifier.  E.g.,
> ISBNs are usually written with hyphens, and for any particular ISBN,
> there is a "standard" way to place the hyphens.  There is also a
> 10-digit version which has a canonical embedding into the 13-digit
> version.  Consideration of these factors appears in the definition of
> lexical equivalence for the urn:isbn namespace, and suggests that if an
> ISBN is incorporated into a URN, hyphens should be deleted and the
> 10-digit forms converted into 13-digit forms.

A coordinated approach as I've outlined above would also ensure that the 
URN community has a solid understanding of any syntactic nuances.

Furthermore, we should also come to know whether the originating 
authority currently has, or plans to define, any resolution processes 
and requirements (either for or against), preferences regarding query 
components (which a URN namespace could define when incorporating the 
original identifier system), etc.

There are complexities here that IMHO we really need to think through 
carefully.

> Similar considerations are addressed in the current urn:glue proposal.
> 
> John Klensin raises the issue of change control.  Thinking about this,
> the only general solution I can think of is this:  Where the
> registration specifies that a certain portion of certain URNs is, or is
> derived from, an external identifier, the registration must state the
> specification of the eternal identifier and the particular version.
> 
> This is a necessity because there is no assurance that a later version
> of the external identifier can be successfully incorporated into a URN
> via a transformation rule that was created without the awareness of the
> later version of the external identifier.

That seems potentially problematic with regard to the requirements 
stated RFC 8141 regarding permanence and the necessarily managed 
ecosystem of names.

> In practice, the URN namespace will want to track the definition of the
> external identifier, but it seems that in order to do so, the maintainer
> of the namespace will have to make any consequent changes to the
> transformation rules and update the registration.

Here again, things would be much simpler if the URN namespace maintainer 
were the originating authority, not an intermediary (some would say 
"interloper").

Peter

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