From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1X1zWw-0001vo-Fj for bitcoin-development@lists.sourceforge.net; Tue, 01 Jul 2014 14:59:34 +0000 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; Received: from plane.gmane.org ([80.91.229.3]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1X1zWu-00025M-Ex for bitcoin-development@lists.sourceforge.net; Tue, 01 Jul 2014 14:59:34 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1X1zWn-0004TH-0A for bitcoin-development@lists.sourceforge.net; Tue, 01 Jul 2014 16:59:25 +0200 Received: from f052195207.adsl.alicedsl.de ([78.52.195.207]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Jul 2014 16:59:24 +0200 Received: from andreas by f052195207.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Jul 2014 16:59:24 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bitcoin-development@lists.sourceforge.net From: Andreas Schildbach Date: Tue, 01 Jul 2014 16:59:07 +0200 Message-ID: References: <20140320215208.GC88006@giles.gnomon.org.uk> <20140326224826.GE62995@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: f052195207.adsl.alicedsl.de User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: X-Enigmail-Version: 1.5.2 X-Spam-Score: -0.4 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.91.229.3 listed in list.dnswl.org] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 1.1 DKIM_ADSP_ALL No valid author signature, domain signs all mail -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1X1zWu-00025M-Ex Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 14:59:34 -0000 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 >