URI Scheme

[pedrouid]

As discussed on CASA Meeting 2 we are going to register on IANA our own URI scheme under a single scheme caip: which will then be described under our standard to identify how to part different identifiers

In order to register on IANA we need to include the following

• URI Scheme
• Template
• Description
• Status
• Reference

I propose that we create a CAIP standard for describing all of these which can then be linked on IANA as a Reference

[pedrouid]

My proposal would be to continue using colons as we have so far to index different CAIPs

caip:2:eip155:1

caip:10:eip155:1:0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb

This we could then extended it more easily for new standards but still have more efficient parsing

[ligi]

linking this discussion mentioned in the call: https://github.com/ipfs/go-ipfs/issues/1678 and I suggest:

caip://2/eip155:1
^^^ scheme
      ^ authority (CAIP number)
           ^^^^^^^^ path (CAIP content)

this might be less correct AFAIR (need to read up on this again - very long ago since I digged into this) - but more tooling sees things like this as an actual URL and sees caip as a scheme one can associate to.

[Arachnid]

@ligi A CAIP number is not an 'authority' in the RFC 3986 meaning of the word:

Many URI schemes include a hierarchical element for a naming authority so that governance of the name space defined by the remainder of the URI is delegated to that authority (which may, in turn, delegate it further). The generic syntax provides a common means for distinguishing an authority based on a registered name or server address, along with optional port and user information.

I'd strongly suggest not trying to make this an 'authority' for cargo cult reasons (eg, people are familiar with the :// syntax). Also, I don't think these quality as URLs, because they don't provide a primary means of locating the resource; they're URIs or URNs.

It seems to me that the simplest and most sensible scheme would be to specify that the first part of the path is drawn from a registry maintained by the CAIP maintainers, and can include eip155 and any others that are defined from time to time, and that the syntax of the remainder of the path depends on the first component.

[pedrouid]

I agree that these would not qualify as URLs but only as URIs or URNs

I would keep it simple by just concatenating with colons to index standards

caip:10:eip155:1:0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb

[Arachnid]

I think it makes more sense for CAIPs to maintain a registry rather than try and make the standard number part of the URI. Email URIs are mailto:foo@bar.com, not rfc:822:foo@bar.com. HTTP URLs aren't rfc2616://. Part of the job of a URI is to be readable, and that means using human-comprehensible identifers whenever possible.

[romeo4934]

more something like that? blockchain:bip122:12a765e31ffd4059bada1e25190f6e98 cryptoaddress:cosmos:cosmoshub-3:cosmos1t2uflqwqe0fsj0shcfkrvpukewcw40yjj6hdc0 asset:cosmos:Binance-Chain-Tigris/slip44:714

[Arachnid]

While it'd be nice to have a URI scheme for each CAIP, it's probably more realistic to be something like caip:eip155:1:..., and have a CAIP registry that defines how eip155 URIs work.

[romeo4934]

We don't have that many types of CAIP. The most important one are CAIP2 -> blockchain ID CAIP10 -> Address CAIP19 -> Asset Type and ID

[Arachnid]

It should be easy to maintain a registry, then!

[TimDaub]

more something like that? blockchain:bip122:12a765e31ffd4059bada1e25190f6e98 cryptoaddress:cosmos:cosmoshub-3:cosmos1t2uflqwqe0fsj0shcfkrvpukewcw40yjj6hdc0 asset:cosmos:Binance-Chain-Tigris/slip44:714

I think still using the "/" slash symbol here can cause compatibility issues when using e.g. CAIP-19 within an URL. See #81.

[romeo4934]

I agree

[TimDaub]

I think it makes more sense for CAIPs to maintain a registry rather than try and make the standard number part of the URI. Email URIs are mailto:foo@bar.com, not rfc:822:foo@bar.com. HTTP URLs aren't rfc2616://. Part of the job of a URI is to be readable, and that means using human-comprehensible identifers whenever possible.

I don't find the human-readability argument convincing. It'd be much clearer to my developer brain if we'd indeed start HTTP URLs with rfc2616 as then I'd exactly know where to look for a manual or protocol description.

Besides, it's not entirely clear where to look for the the mapping of scheme to RFC.

But I'd like to highlight another thing: For long ERC721 stood for NFTs, though now there seems to also be a ERC1155. So wouldn't registering a naming in a registry cause problems suddenly? Who'd decide what is the real "NFT"? In today's case too: I can't overrule what's considered an email and mailto.

I like naming it by standards as there's a clear and permissionless way of reserving a name: Write a standard, get allocated a ascending integer, name your URIs.

[TimDaub]

As I'm wanting to start using CAIP-22 to address erc721's as compliant IANA URIs I was wondering what are the necessary steps towards registration with IANA. Does anyone know?

[silverpill]

@TimDaub This is IANA URI scheme registry: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

Requests for permanent registration must be preceded by mailing list review, per Section 7.2 of [RFC7595].

RFC7595, section 7.2: https://www.rfc-editor.org/rfc/rfc7595.html#section-7.2

[bumblefudge]

@TimDaub @romeo4934 @Arachnid Is there still interesting in registering this? Should I start working on it this month?

[TimDaub]

feel free to move ahead without me