-
Notifications
You must be signed in to change notification settings - Fork 162
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
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-22id
portion 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:1
anderc721:
, a slash/
interferes with the routing scheme on the hypothetical API.The text was updated successfully, but these errors were encountered: