[dragonwriter]

It occurs to me that there is another possible interpretation: the reference to URN being deprecated may have been a distorted reference to the fact that IETF has identified a number of issues with the URN spec and some existing registrations and other related issues and has an active workgroup and working draft on an updated spec. It's hard to tell if that's what was intended, though, since the dismissal was so terse; if so, a discussion of the issues with existing URN spec that are specifically problematic for the use in question would be nice, as would more description of why you aren't using actual URIs with a custom scheme rather than pseudo-URIs (since real URIs, whether URNs are not, mean that tools supporting the standards can be used, rather than building custom tooling and libraries for your almost-but-not-quite-URI setup.)

Whatever the URN reference is intended to mean, this seems to be custom-over-standard with less clear justification than I would want for that choice.

[pcalcado]

Author here.

The deprecation comment refers to this: https://tools.ietf.org/html/rfc3986#section-1.1.3 we had been using URNs and URLs the old way.

But in any case the fact that we're having this conversation I had had to dig up some RFC from 2005 reflects the actual reason for not following any specific standard: I perceive them and their specifications to be confusing and full of historical context that has changed over time. Assuming that there are no other benefits to using the URN scheme specifically (maybe there are and I am not aware of them?) I'd rather use a simplified URI and custom schemes.