ARC-79, extends ARC-26 URI scheme with App NoOp calls

[emg110]

ARC-79 extends ARC-26 with params required for application NoOp calls.

[scholtz]

its missing the network information.. eg how does the wallet knows if the qr code should be used on mainnet, testnet, aramidmain or voimain?

the examples are bad.. quick example: i can create method called claim&do(uint64,uint64)byte[] which would resolve into algorand://TMTAD6N22HCS2LKH7677L2KFLT3PAQWY6M4JFQFXQS32ECBFC23F57RYX4?type=appl&app=11111111&method=claim&do(uint64,uint64)byte[]&arg=20000&arg=474567&asset=45&app=22222222&app=33333333 and from this the parser would take method claim instead of claim&do(uint64,uint64)byte[]

i stated this multiple times at the wallet council meethings..

[emg110]

Thank you for comments!

1- Since extensions are not intended to change any fundamental property of parent ARC, therefore the problem of NETWORK is not addressable in any extension like ARC79.

2- Regarding examples: ARC-26 ABNF grammar is essentially RFC 3986 and the use of "&" reserved character (e.g., :, /, ?, &, =) is to separate the URL params according to RFC, so if you think that those are bad, feel free to contact RFC and make a PR there.
Example: you cannot use the name "Will&Jones" in any URL param as one param value anywhere because the "&" is reserved as a URL parameter separator and all web browsers and developers know and comply with by using "%26" instead of "&", when it is not a separator.
Here is an example using web API method encodeURI() in action so that you can check it leaves reserved characters intact:

[scholtz]

If we do URL encode of the params then there is the problem with your examples..

as you state legit example:

algorand://TMTAD6N22HCS2LKH7677L2KFLT3PAQWY6M4JFQFXQS32ECBFC23F57RYX4?type=appl&app=11111111&method=claim(uint64,uint64)byte[]&arg=20000&arg=474567&asset=45&fee=10000

however if you do the correct encoding it should be

algorand://TMTAD6N22HCS2LKH7677L2KFLT3PAQWY6M4JFQFXQS32ECBFC23F57RYX4?type=appl&app=11111111&method=claim%28uint64%2Cuint64%29byte%5B%5D&arg=20000&arg=474567&asset=45&fee=10000

This faulty examples in arc26 and arc79 just lead to missusage and failure to standardize this protocol. If you really go by the RFC 3986 then fix your examples so that it is obvious how to work with it.

Btw there are different interpretations on what should be encoded and what should not. section-2.2 states that characters like [ and ] MUST be encoded and in your examples they are not. And in your attempt to write that all is good you also encode it however in the arc they are not encoded.

[emg110]

@scholtz , examples are not URI encoded (like all other URI examples) to maintain human readability in the documentation. This is a known practice and is not considered faulty. Using URI encoding functions and tools will take care of that efficiently.