well, the QR is pretended to be read by a computer, not by a human. Not much people cares about what the URL contains, if the app you trust is telling what it reads, it is enough.
We can decide a key-value language, and then make a XDR version based on that. Having two ways for two user uses.
QR codes must be as clear as possible, and could benefit from the XDR version as normally it is expected that the user has his wallet active to read the code.
Website applications could use the URL version, so the app is getting opened, ready to deal with the request.
I was thinking about encoding the XDR version inside base64 to add it to a URL, but it may end up taking the same amount of bytes. So no point to do that.
I worked a bit today in my C++ SDK, now i will switch to define a XDR/URL version proposition based possible operations and some others proposed here.
We could just define a final deadline, like 1 of September (or when ever), to present propositions and give opinions, and decide then by a poll between the ones cared about it, so people can use this for the next challenge. Then we all will speak same language!
EDIT: After some tests, i came to the conclusion that the way to go is to have these extra fields key-value to define actions not considered in the stellar SDK (the ones commented in this thread, import wallet, callback, user information not prettended to be saved in the net, etc..) and a key-value to include XDR operations.
Still, the result of this can be too big, like 250 bytes for a single transaction with not much extra data. That means QR version 10 with low ECC.
But!! if we apply the lazy way of reducing entropy/size, deflate+zlib header, we get to ~120 bytes that can fit in a QR version 6 with low ECC.
Why that stress with QR code sizes?, well, that numbers are for 1 tx operation without much extra data, what if you want to do more complicated stuff or include more data.
For the ones wondering why Low ECC in QR. Well, we will have ECC at QR level, then CRC at zlib level and then stellar address checksums. I would even add a header indicating the size of the decompressed zlib to discard on time corrupted data.
ECC in QRs are though fot use case of damaged or dirty QR codes. So we should use high level when printing, and low level when displaying it on a clean screen.
To keep things a bit easier, i dont see the point of having a readable url encoding, as it will get very complicated with non trivial operations. I would keep same format for urls, just encoding the same in base64.
