Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Register URN with IANA #161

Open
lidel opened this issue May 15, 2020 · 4 comments
Open

Register URN with IANA #161

lidel opened this issue May 15, 2020 · 4 comments
Labels
developers dif/expert Extensive knowledge (implications, ramifications) required effort/weeks Estimated to take multiple weeks help wanted need/analysis Needs further analysis before proceeding need/community-input Needs input from the wider community P2 Medium: Good to have, but can wait until someone steps up specs status/ready Ready to be worked vendors

Comments

@lidel
Copy link
Member

lidel commented May 15, 2020

We have ipfs:// and ipns:// URI registered at IANA (#29 (comment)) 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:, paralleling http:, ftp:, and so forth. URIs of the urn: 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

@lidel lidel added help wanted specs status/ready Ready to be worked vendors developers dif/expert Extensive knowledge (implications, ramifications) required P2 Medium: Good to have, but can wait until someone steps up need/analysis Needs further analysis before proceeding need/community-input Needs input from the wider community effort/weeks Estimated to take multiple weeks labels May 15, 2020
@autonome
Copy link

autonome commented Jul 2, 2020

Came up today at the SDS WG - @jonnycrunch posed as an interop approach for content addressability of this data.

@parkan
Copy link

parkan commented May 30, 2023

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:...

@lidel
Copy link
Member Author

lidel commented Jun 1, 2023

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 👍

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).

@makew0rld
Copy link

makew0rld commented Jul 13, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
developers dif/expert Extensive knowledge (implications, ramifications) required effort/weeks Estimated to take multiple weeks help wanted need/analysis Needs further analysis before proceeding need/community-input Needs input from the wider community P2 Medium: Good to have, but can wait until someone steps up specs status/ready Ready to be worked vendors
Projects
None yet
Development

No branches or pull requests

4 participants