[urn] Re: Incorporating other identifiers into URIs

I have realized that I intended to include the author of "Activation of
RFC 8141 Section 5.1 Reserved NIDs via a Territorial URN Framework"
(thread
https://mailarchive.ietf.org/arch/browse/urn/?gbt=1&index=9NlcD93LGRx3pY0HMHbh8MQRuI8)
into this thread regarding general considerations regarding "namespaces
that include identifiers assigned by other organizations", which is
thread
https://mailarchive.ietf.org/arch/browse/urn/?gbt=1&index=KjzL-lRp3zCYw51AATq993ifAmo
So I have sent this message as part of the latter thread, but added
Jesús Alonso Abad as a recipient.

In the latter thread, the general tenor of the discussion is to be
doubtful about URN namespaces that include "foreign" identifiers.

The summary of the technical objections is, IMHO:

> Dale R. Worley <[email protected]> Thu, 19 March 2026 02:52 UTCS
> 
> I address the question of "incorporating" identifiers defined by other
> systems into URIs generally, not just URNs.  E.g., constructing a URN
> that incorporates a Universal Product Code barcode number.
> 
> In the case of URNs, the requirements of uniqueness and long-term
> stability mean that we need to consider how such incorporation is done
> rather carefully.
> 
> 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.
> 
> *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.
> 
> 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.
> 
> 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.

The summary of the *political* objections is, IMHO:

> Peter Saint-Andre <[email protected]> Thu, 19 March 2026 14:39 UTCS
> > [...]
> 
> 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.
> 
> > [...]
> 
> 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.
> 
> > 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").

Dale

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