[urn] Re: General grumble about incorporating other identifi ers into URNs
John C Klensin <[email protected]> Mon, 09 Mar 2026 19:51:54 -0400
| Newsgroups | gmane.ietf.urn |
|---|---|
| Message-ID | <8990AB31C6EA9B9F3F53A292@PSB> |
Dale, As you (and others) probably noticed, I stepped back from reviewing individual registration application long ago, having concluded that they were in good hands and that, if there was something specific for which I had special knowledge and could contribute, someone would ask. This note/ grumble is, obviously, different. In addition to the obvious, you picked ISBNs as an example and I was involved in one of the revision cycles of the ISBN standard from the ISO side. All of that said, I completely agree with you about revisions/ updates to existing registrations. I'm less sure about "previously-existing identifier systems" because I am not sure I know how to define that precisely enough. I also wonder whether there is another distinction between what might be thought of as ordinary updates and updates that are conditioned on standards (or equivalent) managed elsewhere, for which ISBN is an example. While the key issue is probably revisions/updates (with the change in the number of digits in an ISBN as an extreme case, I wonder if it would be possible to build on the distinction between "Community" and "SDOs, etc." called out in Sections 6.2 and 6.3 of RFC 8141. And that brings me to the next question: do you think whatever needs to be done can be done informally, maybe with a note on the registry, or do we need to rethink/rework parts of 8141? Peter and others on the Expert team? john --On Sunday, March 8, 2026 19:19 -0400 "Dale R. Worley" <[email protected]> wrote: > For many uses, we have defined URN namespaces that incorporate > particular previously-existing identifier systems. Over the past > couple of months there have been two proposals to create URN > namespaces that incorporate multiple other identifier systems. I > expect that there will be more. > > My observation is that people proposing such namespaces generally > have not thought through all of the necessary considerations and the > committee should be on guard about such proposals. In particular, > the proposers generally assume that embedding identifiers from any > one system into URNs is straightforward and needs no further > specification. > > In my experience, this is rarely the case. > > Consider as a typical example the "isbn" namespace. The > registration of version 2 of the namespace required considerable > discussion of several factors: > > - ISBNs conventionally contain hyphens in places that are canonical > for each assigned ISBN. Should the hyphens appear in the URN? - > Should the hyphens be considered significant for lexical comparison? > - When the check digit is "X", how is that represented in the URN? > - The first, 10-digit, version of ISBNs is embedded in the second, > 13-digit, version of ISBNs. Should lexical equivalence consider > the embedded form to be the same as the original 10-digit ISBN? > > Note that these factors are all specific to the ISBN system, and > there is no way to specify in advance all of the factors that will > be relevant for all future identifier systems. > > Thus, any URN namespace that is intended to incorporate in the > future additional identifier systems needs to specify a robust > process for checking that the incorporation addresses all of the > relevant requirements. > > It's not clear to me that this is possible without requiring a new > version of the namespace registration and its review by the > committee. > > Dale > > _______________________________________________ > urn mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ urn mailing list -- [email protected] To unsubscribe send an email to [email protected]