CAIP-19 cannot be unescaped in URL paths #81
Comments
|
Thanks for looking into this! Summoning Antoine Herzog (@antoineherzog), Pedro Gomes (@pedrouid), Joel Thorstensson (@oed) - the authors of this CAIP |
|
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. |
|
It is good for me. @pedrouid ? |
|
@pedrouid What do you think? I think this is a valid point. |
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 |
|
interesting, thanks for reporting. I think we may want to make this issue a priority |
Referring to: https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-19.md
The following claim is made:
with e.g. an identifier like
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
and a user would then fill in the
:caip-22idportion themselves with e.g.eip155:1/erc721:0x06012c8cf97BEaD5deAe237070F9587f8E7A266d. So combined, it'd look like this: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:1anderc721:, a slash/interferes with the routing scheme on the hypothetical API.The text was updated successfully, but these errors were encountered: