[urn] Re: General grumble about incorporating other identifi ers into URNs

Peter Saint-Andre <[email protected]> Tue, 17 Mar 2026 17:40:53 -0600
Newsgroups gmane.ietf.urn
Message-ID <[email protected]>
On 3/17/26 9:00 AM, Lars G. Svensson wrote:
> On 11 March 2026 17:43 Peter Saint-Andre wrote:
> 
>> On 3/9/26 5:51 PM, John C Klensin wrote:
> 
>>> 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?
> 
>> Personally, I don't yet have clear ideas on what needs to be done, but it's
>> worth thinking about. Dale mentioned extra vigilance, and that's a good place to start.
> 
>>From what I've seen in the discussion about ISBN so far, one crucial aspect seems to be lexical equivalence. Another is the syntax definition that has to be narrow enough to enable reasonable syntax validation, but also broad enough to cater for (possible) future expansion. And also if there are characters in the "other identifier" that carry no semantics, such as '-' in ISBN and ISSN.
> 
>> One straightforward consideration that comes to mind is making sure that
>> the registrants for these "incorporating URN namespaces" have coordinated
>> with those who originally defined the identifier systems to be incorporated
>> (as I did when quizzing Olle as to whether he and other TC54 participants had
>> talked with the LEI folks).
> 
> Yes! Maybe we should add that to §6.3 as a prerequisite.

It's a bit late to add things to §6.3 of RFC 8141, and it seems unlikely 
that the RFC will be replaced anytime soon (if ever, although you never 
know!), but the expert review team and broader community can keep this 
consideration in mind when reviewing registration requests.

>> Another consideration is understanding both change control and the assignment
>> process for the underlying identifier systems. [...]
> 
> This one I find trickier. Do we need to require that registrants supply information about that in the registration form or would it be enough that those procedures are well visible in the "further documentation"?

It is indeed tricky, which is why I think we should be concerned.

Hypothetically, let's imagine that someone proposes to create an 
"incorporating namespace" encapsulating every classification system for 
publications (call it "urn:pub"), similar to the "urn:glue" proposal. 
Now we could have:

urn:pub:isbn:...
urn:pub:issn:...
urn:pub:doi:...
urn:pub:ismn:... (for International Standard Music Numbers)
urn:pub:ddc:... (for Dewey Decimal Classification)
urn:pub:lcc:... (for Library of Congress Classification)
(etc.)

How are all those incorporated identifiers assigned? Do we know that 
they are assigned in well-managed ways (as required by RFC 8141)? What 
if the management/assignment processes differ significantly across the 
incorporated identifier systems? Does there need to be consistency in 
the assignment processes if they will all be bundled under the "urn:pub" 
namespace?

Furthermore, what is the change control process for versioning of the 
incorporated identifier systems? Does the "urn:pub" namespace change 
control process take precedence over the change control process for the 
incorporate identifier systems? Does the registration for the "urn:pub" 
namespace need to be updated each time one of the incorporated 
identifier systems is changed?

The question we would need to ask in this hypothetical case is: does it 
make sense to define "urn:pub" as the "one ring to bind them all" for 
everything that could be published or catalogued? Readers of Tolkien 
might understand that creating one ring can have serious consequences...

Peter


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