No, this stuff goes into the payment protocol, end of story. Extending the URI spec is a non starter for the reasons Jeff explained, it's simply not possible to keep stuffing things into that endlessly.
Well, from the fact that BIP 0021 contains "otherparam" and "reqparam" today, I had to assume (and did assume) that it is open for further enhancements. Also the text in today's "BIP 0021" wiki goes along these lines.
If it is (was?) decided to freeze the URI scheme acc. to today's BIP 0021 forever, I propose to mention this in the BIP 0021 wiki, to avoid that people like me spend time to think up and write down things in vain.
I still think that a single simple optional parameter like "&tip=0.08" does not harm and has it's justified benefit in a by now neglected
major payment scenario. Indeed I think the scenarios "simple payment w/o tip" and "simple payment with tip" are the only
two dominating payment scenarios in everyday's use, and all the rest (incl. humble-bundle multi-output payment scenarios) is and will remain marginal, so the rest of my "wiki discussion" contributions can be rejected if considered yielding endless amendments, I wouldn't object.
All I keep pleading for is that all the major payment scenarios (of which there exist only two!) should be well accounted for by BIP 0021, and currently one of the two is not considered.
But I will not continue this discussion any further if it is not welcome and if my opinion is singular.
But don't worry - it can still show up immediately in a restaurant. The way the payment protocol can be used in the tablet/mobile scenario is that the recipient of the money serves the payment request (hopefully signed) via Bluetooth. The BT MAC goes in the QRcode/NFC data so the device knows where to connect. The Android wallet already has a primitive version of this up and running, in the labs section of the settings screen. It also means the payer doesn't require any internet connection at all - all the communication is with the waiter/waitresses device. The delay is hardly noticeable and the user experience is entirely transparent, it doesn't look any different to today (there's no pairing involved because we use unauthenticated sockets).
Excellent! The payer can pay w/o own internet connection and just sends the signed transaction to the recipient's phone/tablet (via BT/NFC/animated QR codes)! I was thinking along the very same lines recently and came to the conclusion for myself that exactly this is needed (because of scenarios like "roaming", "bad indoor cellphone coverage" or "cellphone network overload"). Glad to read that this is already being conceptualized! (The only drawback in UX is that customer has to activate/deactivate BT before/after the payment manually, unless BT is active all the time, which many users incl. myself don't like for good reasons)
Just a remark: It must be ensured that the customer really connects (via BT) to the correct tablet and not to a "hijacker" who shows me a different payment address. So on top of the MAC address (which could be imitated by a nearby attacker's phone I suppose) also a one-time session key (PIN or so, even better sth. "assymetric") and/or the (main) payment address should be included in this QR code/NFC code that initiates the BT session. But I guess mechanisms like these are already part of the concept.
Why I still stick to my original proposal (not in substitution but in complement to this one, which has my full support):
Some users might be hesitant using BT, given the various BT security breaches that have been reported in the past on various phones. Whenever I switch on my BT, I could be a potential target (need not even be related to Bitcoin) of an attacker exploiting a bug in the BT stack on my phone. And generally, some users might feel uncomfortable establishing any peer-to-peer BT connection to a foreign device: "Maybe that device exploits some vulnerability of the BT bitcoin payment protocol stack implemented on my phone...".
At the moment the Bluetooth protocol is a custom thing, it's not the payment protocol. Once bitcoinj supports the payment protocol, we'll start transitioning Android users to the newer scheme and then open up a BIP to standardise that.
Of course this only works if the receiver of the funds is using a native app. BitPay will want to produce a native Android app for tablet users anyway, because otherwise the sender of the funds always needs internet access and in many places that's not a given. For example in some restaurants/shops the cell reception isn't so great, and when people travel they won't have roaming access. Actually it'd make sense for them to hire Andreas to do that, if he's so willing. It also has the advantage that merchants could sign the payment requests under their own identity without having to give their SSL private keys to BitPay, which many places won't be willing to do (but putting it into their own PoS systems might be easier to countenance).
