Register URN with IANA
We have
ipfs://andipns://URI registered at IANA (https://github.com/ipfs/in-web-browsers/issues/29#issuecomment-629016191) already! This issue is about URN, preferably scoped to CIDs without pathing.
Why should we care?
Semantic web applications, where URNs are broadly used, may want to use CID identifiers like this:
urn:cid:bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi
We've opted for cid instead of ipfs as ipfs: is already used for URIs and may include unixfs+ipld+web pathing semantics, while cid is just a content identifier, nothing more.
They can do it anyway, but formalized cid URN at IANA would make adoption easier in more strict and spec driven environments.
What are URNs.. today?
The term "URN" continues now as one of more than a hundred URI "schemes",
urn:, parallelinghttp:,ftp:, and so forth. URIs of theurn:scheme are not locators, are not required to be associated with a particular protocol or access method, and need not be resolvable.They should be assigned by a procedure which provides some assurance that they will remain unique and identify the same resource persistently over a prolonged period. Some namespaces under the urn: scheme, such as urn:uuid: assign identifiers in a manner which does not require a registration authority, but most of them do.
A typical URN namespace is
urn:isbn, for International Standard Book Numbers. This view is continued in the 2017 RFC 8141 – https://en.wikipedia.org/wiki/Uniform_Resource_Name
Registration at IANA
AFAIK the URN process is more strict, there is no "provisional" track and "Expert Review" sounds more serious:
Registration Procedure(s)
- Expert Review, per Section 6 of [RFC8141].
- Fast-track procedure for standards organizations described in Section 6.3.
– https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml
Prior art
- I believe we could reuse work kicked-off by @jonnycrunch in https://github.com/jonnycrunch/ipfs-uri-scheme/, perhaps even repurpose that repo for URN?
- There are also provisional requests for URIs at https://github.com/fred-wang/iana-uri-schemes-provisional-registration-requests/
Came up today at the SDS WG - @jonnycrunch posed as an interop approach for content addressability of this data.
has there been any progress on this? is there a recommendation for what prefix we can use on a provisional basis if URNs are expected but we only have CIDs?
EDIT: after a brief out-of-band discussion we're leaning towards using urn:cid:...
No progress on URN yet, but while working on gateways and ipfs: URIs, we've realized there are a lot of implicit behaviors behind "ipfs" pathing (unixfs+web), which need to have own spec at some point..
I agree, for URN, as long you only point at a CID, without any pathing, urn:cid:{cid} makes more sense :+1:
As for URN registration, not a blocker, but hoped to clean up CID spec before we submit its URN to IANA. As bare minimum, wWe could create Addressing section at https://specs.ipfs.tech and move https://github.com/multiformats/cid there. I feel waiting for https://www.ietf.org/mailman/listinfo/multiformats to create RFC draft will take too long (CID is not even in the scope ATM).
Does using this format make sense for non-file CIDs as well, for example a CID that refers to a DAG-CBOR document? Like the CID of an encoded block as shown here.