This page is part of the web mail archives of SRFI 83 from before July 7th, 2015. The new archives for SRFI 83 contain all messages, not just those from before July 7th, 2015.
Neil Van Dyke wrote:
Alex Shinn <alexshinn@xxxxxxxxx> wrote at 2006-01-26T10:37:02+0900:
...
The recommended approach would probably be to use a URN (rfc2141):That's what I would've said, til I heard an offhand remark from one person a while ago, which made me wonder whether URNs had fallen into disfavour. I've not been in the loop on that lately. I definitely think that some W3C and IETF people should be consulted about the use of URIs in the Scheme module system, if they've not been already.
That person may have been thinking of the issues described in RFC 3305 (URIs, URLs, and URNs), which are summarized nicely in its section 2.
Summarizing further, URNs are no longer considered to be a disjoint subspace of the entire URI space: a particular URI scheme can define its own subspaces, which could include both URN and URLs.
If the "scheme:" URI scheme were registered (assuming no objections to a scheme named "scheme"), then it could be used for both URNs and URLs, if necessary.
OTOH, the "urn:" URI scheme is intended only for URNs, i.e. names that are not intended to be treated as explicit location specifiers. That would give URIs like "urn:scheme:r6rs" and "urn:scheme:srfi-N" (slashes are disallowed in URNs, according to RFC 2141).
The other library URIs could also be modified for URN syntax. One of the examples in the SRFI could become:
urn:scheme:acme.com:wiley:quicksortThis doesn't necessarily preclude using other kinds of URIs to identify libraries.
Of course, the "urn:scheme:" part could be assumed where appropriate, leaving only the essential bits. E.g. (acme.com wiley quicksort) could be a library specifier which maps to the above URN, which in turn maps to an actual resource.
The above is just laying out some possibilities w.r.t. URNs. I'm not advocating anything, and I'm not one of the authors of this SRFI.
Anton