I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had on the wall a picture of their QR code and a bitcoin address. I don't own a mobile phone so the QR code is
useless.
Fixed addresses like that are a temporary thing during Bitcoins maturation period. They lead to merchants exposing data they probably don't realize they're exposing, like their income, which is basically unacceptable for any payment system.
There's no point trying to optimize a case where:
1) You are in the minority (no phone?)
2) The "perfect experience" leaks private data in such a way that would be deemed a gross security breach by any serious payment processor.
OK, some thoughts on the general proposal, from the POV of what it'd take for a large deployment, like for every Gmail or every Facebook user. In terms of ease of implementation it is ordered HTTPS/HTTP then DNS trailing by a large margin. Big sites, even small sites, typically have high-speed load balancing and demuxing already implemented for HTTP[S] and it's usually easy to add new endpoints. The same is not true of DNS, and whilst coding up a custom DNS server is possible it's definitely a worse fit.
FirstBits seems out of the question for the same privacy reasons as given above. No banking system worth its salt would let everyone look up other peoples income.
The simplest approach would be to request a full public key with an HTTPS request like
If you then want to turn the resulting public key into an address before creating a transaction you can obviously do that.
BTW the BIP is pretty hard to read. Your spec for the HTTPS proposal is a big pile of source code. I think it's the same as above, but it's hard to tell without more effort.