Received-SPF: pass (sog-mx-1.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 16:59:07 +0200
Message-ID: <louibr$8gc$1@ger.gmane.org>
References: <leuunm$tjk$1@ger.gmane.org>	<lge7nk$3mf$2@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$2ra$1@ger.gmane.org>	<D4B82FD9-8078-48B2-9F91-8A3AB23AEAA7@osfda.org>
	<CALDj+BZ8_YB0DHiaGZPq4MB-dvkRqJhBFazcfnrrPX4EvRxbeQ@mail.gmail.com>
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: <CALDj+BZ8_YB0DHiaGZPq4MB-dvkRqJhBFazcfnrrPX4EvRxbeQ@mail.gmail.com>
Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Precedence: list

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
>