CAIPs
CAIPs copied to clipboard
ChainAgnostic
CAIP-19 cannot be unescaped in URL paths
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.
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.
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?
You are right. We should replace it by another symbol not sure which one to choose?
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.
@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.
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.
interesting, thanks for reporting. I think we may want to make this issue a priority