[urn] Re: Incorporating other identifiers into URIs

[Olle E Johansson <[e-mail]>]

> On 19 Mar 2026, at 15:39, Peter Saint-Andre <[e-mail]> wrote:
> 
> 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”)

Good feedback. Our use case was: We do not want to create a NEW product registry, but let vendors used their registred name space in other registries if needed and propose alternatives for those that did not have. That’s why we strived to include existing identifiers, 
like PURL or other identifiers like medical device IDs, EAN bar codes… It’s not a coup to take over the management of their name space.

In our case, ECMA would be the maintainer of the URN type name space. Having to update the TEI registration every time we add a new type would be impossible to handle. The management has to possible to delegate to another authority than the IETF.

Well, we’re heading towards a good old URL anyway.

/O