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

[Andreas Schildbach <andreas@schildbach.de>]

Ok, one more idea:
r= is used for the first URL, and we *think* of it as r0=
additional URLs are appended as
r1=
r2=
and so on. This would also define an ordering in case we need it.


On 07/01/2014 05:07 PM, Michael Wozniak wrote:
> Multiple parameters is currently undefined as far as I can tell.  Should the client take the first, last, or ignore it completely if there are multiple of any parameter?  I think that’s the point of the parameter pollution discussion, which will define it one way or the other.
> 
> I’m only familiar with the Electrum implementation, which is currently checking for any duplicate parameters and treating the entire URI as invalid if duplicate parameters exist (following the parameter pollution suggestions).
> 
> -
> Michael Wozniak
> 
> On Jul 1, 2014, at 10:59 AM, Andreas Schildbach <andreas@schildbach.de> wrote:
> 
>> 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
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
> 
> 
> ------------------------------------------------------------------------------
> 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
>