Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of m.gmane.org
	designates 80.91.229.3 as permitted sender)
	client-ip=80.91.229.3;
	envelope-from=gcbd-bitcoin-development@m.gmane.org;
	helo=plane.gmane.org; 
To: bitcoin-development@lists.sourceforge.net
From: Andreas Schildbach <andreas@schildbach.de>
Date: Tue, 01 Jul 2014 17:39:42 +0200
Message-ID: <louknu$7ja$1@ger.gmane.org>
References: <leuunm$tjk$1@ger.gmane.org>	<CANEZrP0J849oDvMWjf8LWi0xj44Q8DaUwDip5_smVBMNgeQ3mw@mail.gmail.com>	<CALDj+BZJ0rSKuDHdbL7ANN0Vtaa3-KGYgusqMDzzB-CUxjMz7g@mail.gmail.com>	<CANEZrP3szn=oQS+ZuqSzjUoSAjtkyPxPWJFaU1vDW43dRNVeNQ@mail.gmail.com>	<20140320215208.GC88006@giles.gnomon.org.uk>	<CANEZrP3kHRJ6U-O_Jgei4U6s9GyQGvB_p5ChtcHJEkYR0wWPvQ@mail.gmail.com>	<20140326224826.GE62995@giles.gnomon.org.uk>	<CANEZrP2HtJsOf5zOsPz32U=Jot7U9k80yEu=hj5uMPkRC+WGsQ@mail.gmail.com>	<lgvnc2$eu4$1@ger.gmane.org>	<CANEZrP1==hL1mW6SWV0qXUMVVx7U_HUXtorpb7qVK2R4mOfzbg@mail.gmail.com>	<A1269E16-63BC-44D5-B460-D793D45587AD@riseup.net>	<CALDj+BYkOyNuEiiuTgjd7L-ZeHN4Mb4034W+OeCFob1RwJn=Vg@mail.gmail.com>	<CANEZrP1HvKAg6d7tTcnY3BJr0_5LuCN1FGYQvQ1+RpL1B6cwHw@mail.gmail.com>	<lou05t$2
	ra$1@ger.gmane.org>	<D4B82FD9-8078-48B2-9F91-8A3AB23AEAA7@osfda.org>	<CALDj+BZ8_YB0DHiaGZPq4MB-dvkRqJhBFazcfnrrPX4EvRxbeQ@mail.gmail.com>	<louibr$8gc$1@ger.gmane.org>
	<1016E2A3-C678-46FA-B80E-F9D86FDEA213@osfda.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.6.0
In-Reply-To: <1016E2A3-C678-46FA-B80E-F9D86FDEA213@osfda.org>
Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Precedence: list

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
>