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