Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Andreas Schildbach <andreas@schildbach.de>]

Does r[]= really need to be encoded as r%5B1%5D= ? In this case, I'd
advocate for a simple array parameter name, like rs= ("plural" of r).
Length really does matter for QR codes.

I'm fine with either multiple r= params or exactly one r= plus zero to
many r[]= params. Although I think it is a violation of the (current)
spec to choke on more than one r= parameters, I admit that bitcoinj is
currently implemented that way. (We could however fix this in a
maintenance release.)

However, r= should also allow all other protocols, exactly like any of
the r[]= params. I don't think we should do a distinction here. Also
because of backwards compatibility to the status quo.


On 07/01/2014 03:03 PM, Alex Kotenko wrote:
> In my mind it's not like the client's phone is going all directions at
> the same time. There should be a priority method and fallback method(s).
> ​And I ​see p2p radio as priority, and web as fallback, and BIP21 in the
> end as always-working-default.
> 
> ​So I'm keeping support for it all while want to be able to provide best
> user experience. 
> Mike, a while ago in ​this thread you've described contactless cards
> user experience. I'm also using contactless cards often, and what I'm
> aiming at is creating same level of user experience for Bitcoin users. 
> 
> Encryption over bluetooth is a matter to worry about, and we will
> introduce that, but we need to sort out more low level problems first
> before coming into that stage. 
> 
> 
> So, the backwards compatibility is a good issue Michael pointed out. 
> While processing of multiple "r" parameters is indeed uncertain (since
> there is no RFC for that various implementations may behave
> differently), the array solution is somewhat better. The array parameter
> name is "r%5B1%5D=", i.e. it's not "r=", and we can add plain "r="
> alongside. And if particular implementation understands the array
> construct - it will use it, otherwise it will ignore the "r%5B1%5D=" and
> use only usual "r=". 
> 
> This doens't work though for cases where particular implementation
> understands array construct but doesn't work well with repeating
> parameters, since it will see two repeating "r" - an array and a string.
> I don't have a solution for that atm. 
> 
> 
> If add completely new parameter to solve this we will need to make it an
> array straight away to address upcoming issues with accommodating other
> protocols. 
> And then I would also modify existing BIP72 to strictly define "r=" as
> "http(s)" ​only ​parameter, while all other protocols (bluetooth, WiFi
> Direct, ultrasound, chirp etc) should go to the new array parameter.
> 
> 
> ​
> 
> 
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> 
> 
> 
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>