Specify what must happen when tx is used together with other parameters

[mathiasrw]

Thank you for (yet again) providing an utterly well-described suggestion to how to improve the bitcoin world.

When reading the specification section from the description it is not clear what must happen in case the tx parameter is provided together with other parameters:

The protocol works like this: Whenever a wallet encounters a tx parameter in a URI scheme, it can deserialize the tx parameter to display the transaction object detail in a user-friendly manner, as well as give an option to the user to approve or decline the transaction.

If, for example, tx is provided together with an address and an amount i imagine that we will see different wallets doing one of the following:

1. ignore the tx and provide the user with an interface as if only address and amount were present.
2. ignore the other values and provide the user with an interface as if only tx was present.
3. Recognise that this might be an error and provide an error message to the user
4. Treating the tx as one instance to handle and the address/amount as a second one providing the user with one interface followed by another as if tx was sent separately and address/amount sent separately.
5. The client sees the tx as a "baseline" and will seek to adjust the tx by changing address and amount to the values given as parameter in the URI.

As these are vastly different scenarios this could result in bad user experience across wallets. I, therefore, believe the specification should include a description of what must happen in case tx is provided with other parameters.

Personally, I regard option 2. as the most intuitive.