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

CAIP-19 cannot be unescaped in URL paths #81

Open
TimDaub opened this issue Nov 11, 2021 · 9 comments · May be fixed by #82
Open

CAIP-19 cannot be unescaped in URL paths #81

TimDaub opened this issue Nov 11, 2021 · 9 comments · May be fixed by #82

Comments

@TimDaub
Copy link

TimDaub commented Nov 11, 2021

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
Copy link
Member

ligi commented Nov 12, 2021

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
Copy link
Author

TimDaub commented Nov 12, 2021

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
Copy link
Contributor

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

@TimDaub
Copy link
Author

TimDaub commented Nov 12, 2021

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.

@TimDaub TimDaub mentioned this issue Nov 12, 2021
@romeo4934
Copy link
Contributor

It is good for me. @pedrouid ?

@romeo4934
Copy link
Contributor

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

@TimDaub
Copy link
Author

TimDaub commented Nov 29, 2021

@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
Copy link

ntn-x2 commented Jun 27, 2022

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
Copy link
Author

TimDaub commented Jul 11, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants