Hi Andreas
I'm implementing support for BIP70 in my POS at the moment, and I've just realized that with options you're proposing usecase I'm looking for is not covered.
Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I need to still be able to use it for backwards compatibility. But at the same time I want to be able to support BIP70. And also I want to avoid using external servers, the concept of my POS is that everything is happening between just payer's phone and payee's POS device. This means that BIP72 HTTP(S) link inside Bitcoin URI is not suitable for me.
You're also offering an option to include Base43 encoded PR body right inside the Bitcoin URI, but in a way that is not backwards compatible with BIP21.
In the end this all means that there is no way for me to at the same time keep backwards compatibility with all wallets not supporting NFC and BIP70 (all other wallets right now), and keep things inside POS without need for external servers.
I understand your intention behind base43 encoding and noncompatible URI - you want to make most possible use of QR codes. But I wonder - did you compare this base43 to base64 encoded request in a binary QR code format? How much do we actually win in total bytes capacity at a price of noncompatibility and increased complexity?
And also maybe we can extend BIP72 to include encoded payment request in the URL directly in a backwards compatible way?