> But we don't have to
> define how the server will get that address.
> Some possibilities:
>
> -A static address: less anonymity, but some people may not care. Say a
> donation address.
> -The servers stores the recipient private keys and generates a new one
> for each payment.
> -The server stores a set of addresses provided by the recipient and it
> manages what address it gives in each request (like in the web service
> I told you I can't find).
>

Exactly, I think we should starting separating the minimal protocol that is
to be supported by everybody, and the rest can be summed up in a few best
practices, no need to standardize the part that to the user is transparent.
I was on the same lines as Andy, which is that in order to have require a
payment I probably have an order/transaction pending with my vendor or have
an account to be filled, so there's a 1-to-1 mapping between the details
page and the bitcoin address I have to send to.

As a further possibility we could use <meta> tags like the OpenID server
delegation mechanism. It would allow customers to open the transaction
details page, see that everything is ok, then paste the same URL into the
bitcoin client, the bitcoin client retrieves the URL, parses the meta tag
and knows what to send where. Alternatively the Bitcoin Client sends an
Accept header which tells the server to return just the address.

As for the format I'd say either a Bitcoin address or a Bitcoin URI [1]
which ought to be flexible enough as it includes amount and messages, for
the customer to be able to track transactions.

Regards,
Chris

[1] https://en.bitcoin.it/wiki/URI_Scheme