Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1X20AH-0003nC-4q for bitcoin-development@lists.sourceforge.net; Tue, 01 Jul 2014 15:40:13 +0000 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; Received: from plane.gmane.org ([80.91.229.3]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1X20AF-0000DM-M0 for bitcoin-development@lists.sourceforge.net; Tue, 01 Jul 2014 15:40:13 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1X20A4-0005eU-Pk for bitcoin-development@lists.sourceforge.net; Tue, 01 Jul 2014 17:40:00 +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 17:40:00 +0200 Received: from andreas by f052195207.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Jul 2014 17:40:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bitcoin-development@lists.sourceforge.net From: Andreas Schildbach Date: Tue, 01 Jul 2014 17:39:42 +0200 Message-ID: References: <20140320215208.GC88006@giles.gnomon.org.uk> <20140326224826.GE62995@giles.gnomon.org.uk> <1016E2A3-C678-46FA-B80E-F9D86FDEA213@osfda.org> 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: <1016E2A3-C678-46FA-B80E-F9D86FDEA213@osfda.org> 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: 1X20AF-0000DM-M0 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 15:40:13 -0000 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 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 >