CAIP-19 cannot be unescaped in URL paths

[TimDaub]

CAIP-19 cannot be unescaped in URL paths

[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