fix(applications): use correct DOI URN form

[Walentalien]

URN is a URI using urn scheme: https://datatracker.ietf.org/doc/html/rfc8141#section-1.1

[wiktor-k]

I think you may want to update this reference here too.

[Walentalien]

If you want to learn more about the DOI effort, and how to interpret names like doi:10.17487/RFC0791, you can visit the DOI website using the following URL: https://doi.org.

If you mean i should add urn scheme there too then i don't think so.

[wiktor-k]

Oh, right. Re-read this and it makes sense as is. Sorry for the noise! 👋

[Walentalien]

No problem. Reviews are much appreciated 👍🏻

[llpeterson]

The current example in Chapter 2 is valid, per the explanation in Chapter 11. Using URN as the scheme is also valid, but I elected to go with DOI in Chapter 2 for the reason you flagged it: to get you thinking about URNs, and maybe even jump to Chapter 11 for more detail.

[Walentalien]

The current example in Chapter 2 is valid, per the explanation in Chapter 11. Using URN as the scheme is also valid, but I elected to go with DOI in Chapter 2 for the reason you flagged it: to get you thinking about URNs, and maybe even jump to Chapter 11 for more detail.

So doi:... is being referred to as a URN in the book in the broader historical sense mentioned in RFC 3986, rather than according to the formal URN syntax defined in RFC8141 which makes it 'historically' correct ?

[llpeterson]

Interesting stuff... I'm not sure I read it as being only historically correct. My reading is that 8141 is pointing out that urn:doi... and doi:... are technically not equivalent (in the since that they necessarily reference the same object). The unstated assumption is that DOI (the organization) maintains consistency between the two. I need to study this some more. If nothing else, that's a point worth calling out (probably in Chapter 11), maybe as part of a bigger point about the responsibilities of delegated authorities.

Having said that, the lead sentence of that section states a MUST: "When URNs are transported and exchanged, they MUST be represented in the format defined herein." As a textbook, are we in the business of "transporting and exchanging" URNs, or are we in the business of explaining concepts? I would argue the latter, so we have some latitude in how we manage this situation, but this is a fascinating discussion nontheless.

[drbruced12]

I will just add that RFC 3986 has not been obsoleted, and seems to take a broader view of what is a URN than RFC 8141. So I think we are doing the readers a favor if we help them to understand that URN as a term is used more broadly than just the syntax used in 8141. To quote 8141:

Note to the reader:
the term "URN" has been used in other contexts to refer to a URN
namespace, the namespace identifier, the assigned-name, and URIs
that do not use the "urn" scheme. All but the last of these is
described using more specific terminology elsewhere in this
document, but, because of those other uses, the term should be
used and interpreted with care.

Perhaps we should include some similar "use with care" advice in our description?

[llpeterson]

I'll edit Chapter 11 to reflect this discussion. (Probably won't be for a few days.)