CAIP-19 cannot be unescaped in URL paths

[TimDaub]

Referring to: https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-19.md

The following claim is made:

The following secondary goals can easily be achieved:

• Can be used unescaped in URL paths

with e.g. an identifier like

eip155:1/slip44:60

However, I doubt this claim. If e.g. I was to design a RESTful HTTP API that'd allow users to query for chain-agnostic ERC721 tokens, I'd probably design the endpoint as

/api/v1/nfts/:caip-22id:

and a user would then fill in the :caip-22id portion themselves with e.g. eip155:1/erc721:0x06012c8cf97BEaD5deAe237070F9587f8E7A266d. So combined, it'd look like this:

/api/v1/nfts/eip155:1/erc721:0x06012c8cf97BEaD5deAe237070F9587f8E7A266d

However, going back to the original claim that CAIP-19 ids can be used unescaped in URL paths, I doubt this is the case as between eip155:1 and erc721:, a slash / interferes with the routing scheme on the hypothetical API.

[ligi]

Thanks for looking into this! Summoning Antoine Herzog (@antoineherzog), Pedro Gomes (@pedrouid), Joel Thorstensson (@oed) - the authors of this CAIP
I less think the routing scheme is a problem - but the colon would need to be escaped right? We should definitely look into this before moving this one out of draft state.

[TimDaub]

Do I understand it right that we're looking for a terminal symbol suggesting hierarchy but that doesn't collide with existing standards like e.g. URI or URL?

[romeo4934]

You are right. We should replace it by another symbol not sure which one to choose?

[TimDaub]

Actually, I like what is discussed in #67, which is that fundamentally the concepts in e.g. CAIP-19 and so on are considered to be valid URIs or URNs.

In that issue, it's suggested to solely use the colon: ":". It wouldn't have to be escaped in a URL as outlined in the original post and would hence solve this issue.

[romeo4934]

It is good for me. @pedrouid ?

[romeo4934]

@pedrouid What do you think? I think this is a valid point.

[TimDaub]

@ligi

but the colon would need to be escaped right?

According to the BNF of RFC3686 on URI syntax (https://www.rfc-editor.org/rfc/rfc3986#appendix-A), the "hier-part" is allowed to include a "path-empty" that allows a "pchar" and the colon is a pchar. So in that case a colon wouldn't have to be escaped.

[ntn-x2]

Just my two cents: we are working on a DID specification that wraps around CAIP-19 identifiers, and because the spec also does not allow / characters, we are replacing them with :. This of course creates issues between distinguishing a CAIP-10 from a CAIP-19 identifiers, but as the DID specification is only concerned with CAIP-19 assets, this is something we can live with.

[TimDaub]

interesting, thanks for reporting. I think we may want to make this issue a priority