From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1X1zei-0002Ne-4F for bitcoin-development@lists.sourceforge.net; Tue, 01 Jul 2014 15:07:36 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of osfda.org designates 217.23.13.216 as permitted sender) client-ip=217.23.13.216; envelope-from=mw@osfda.org; helo=smtp.osfda.org; Received: from smtp.osfda.org ([217.23.13.216]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1X1zeg-0007ML-7B for bitcoin-development@lists.sourceforge.net; Tue, 01 Jul 2014 15:07:36 +0000 Received: from [38.105.161.253] (unknown [38.105.161.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osfda.org (Postfix) with ESMTPSA id A851A13A017F; Tue, 1 Jul 2014 17:07:27 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Wozniak In-Reply-To: Date: Tue, 1 Jul 2014 11:07:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1016E2A3-C678-46FA-B80E-F9D86FDEA213@osfda.org> References: <20140320215208.GC88006@giles.gnomon.org.uk> <20140326224826.GE62995@giles.gnomon.org.uk> To: Andreas Schildbach X-Mailer: Apple Mail (2.1878.2) X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1X1zeg-0007ML-7B Cc: bitcoin-development@lists.sourceforge.net 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:07:36 -0000 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=E2=80=99s the point of the = parameter pollution discussion, which will define it one way or the = other. I=E2=80=99m 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[]=3D really need to be encoded as r%5B1%5D=3D ? In this case, = I'd > advocate for a simple array parameter name, like rs=3D ("plural" of = r). > Length really does matter for QR codes. >=20 > I'm fine with either multiple r=3D params or exactly one r=3D plus = zero to > many r[]=3D params. Although I think it is a violation of the = (current) > spec to choke on more than one r=3D parameters, I admit that bitcoinj = is > currently implemented that way. (We could however fix this in a > maintenance release.) >=20 > However, r=3D should also allow all other protocols, exactly like any = of > the r[]=3D params. I don't think we should do a distinction here. Also > because of backwards compatibility to the status quo. >=20 >=20 > 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). >> =E2=80=8BAnd I =E2=80=8Bsee p2p radio as priority, and web as = fallback, and BIP21 in the >> end as always-working-default. >>=20 >> =E2=80=8BSo I'm keeping support for it all while want to be able to = provide best >> user experience.=20 >> Mike, a while ago in =E2=80=8Bthis 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.=20 >>=20 >> 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.=20 >>=20 >>=20 >> So, the backwards compatibility is a good issue Michael pointed out.=20= >> 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=3D", i.e. it's not "r=3D", and we can add plain = "r=3D" >> alongside. And if particular implementation understands the array >> construct - it will use it, otherwise it will ignore the "r%5B1%5D=3D" = and >> use only usual "r=3D".=20 >>=20 >> 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.=20 >>=20 >>=20 >> 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.=20 >> And then I would also modify existing BIP72 to strictly define "r=3D" = as >> "http(s)" =E2=80=8Bonly =E2=80=8Bparameter, while all other protocols = (bluetooth, WiFi >> Direct, ultrasound, chirp etc) should go to the new array parameter. >>=20 >>=20 >> =E2=80=8B >>=20 >>=20 >> = --------------------------------------------------------------------------= ---- >> 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 >>=20 >>=20 >>=20 >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >>=20 >=20 >=20 >=20 > = --------------------------------------------------------------------------= ---- > 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