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; 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Michael Wozniak <mw@osfda.org>
In-Reply-To: <lou05t$2ra$1@ger.gmane.org>
Date: Tue, 1 Jul 2014 06:42:33 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <D4B82FD9-8078-48B2-9F91-8A3AB23AEAA7@osfda.org>
References: <leuunm$tjk$1@ger.gmane.org>	<CANEZrP3nQfvDArKTRgje0Cus4G2JD_zpxSjA3fXfxM2TNAP80Q@mail.gmail.com>	<CALDj+BafD+6KTNcYDBEu5gNPzYozSkiC-JCxrY-PzXL2DYBRsw@mail.gmail.com>	<CAJHLa0N4J_Z907+D0ENSNKfNAW2N=7Jf4JzSCO=SU558GtGTzA@mail.gmail.com>	<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>
To: Andreas Schildbach <andreas@schildbach.de>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Precedence: list

I think it makes more sense to not add a duplicate parameter.  Current =
implementations will break if multiple r parameters are used (either =
reject the URI completely, or do something undefined).  If a new =
parameter is used, then the current implementations will just ignore it =
if they don=E2=80=99t support it.

-
Michael Wozniak

On Jul 1, 2014, at 5:48 AM, Andreas Schildbach <andreas@schildbach.de> =
wrote:

> On 07/01/2014 10:18 AM, Mike Hearn wrote:
>>    =E2=80=8BHowever it's not ideal at the moment. Basically the main =
problem is
>>    that in the BIP72 there is no way to provide a fallback =
alternative
>>    URI for payment request fetch if client wallet supports BIP70 but
>>    doesn't not support fetching over bluetooth or bluetooth =
connection
>>    fails for any reason.=20
>=20
> I think the way to go here is using multiple r=3D parameters.
>=20
>> So the idea here is that the recipient wallet both uploads to the
>> internet and exposes the payment request over Bluetooth =
simultaneously,
>> then let's the sending wallet pick whatever radio layer works best in
>> its current conditions?
>=20
> Either that, or just use the other ones as a fallback. Currently,
> Bitcoin Wallet just falls back to BIP21 if fetching the PR via the r=3D
> URL fails.
>=20
>> I think having multiple r=3D params is reasonable, but the Bluetooth
>> support is not specced in any BIP anyway. And if it were to be, =
people
>> would point out the lack of link-layer encryption.
>=20
> Its "specced" in code and implemented by several parties. I think its
> clear that link-layer encryption has to be an add-on to the current
> unencrypted connection, just like HTTPS is on top of HTTP. Anyway,
> that's unrelated to the question of how to provide fallback URLs.
>=20
> One more thought: We have a similar problem with the BIP70 payment =
URL.
> It doesn't allow for fallbacks either. I brought this issue up in the
> discussion phase of BIP70, but it was dismissed I think because of
> "let's not get too complex for the first version". The fallback here =
is
> to send the transaction via the P2P network.
>=20
> (I think BIP70 via P2P radio will get used more often in future. I =
plan
> to look into Bluetooth 4 LE as soon as I have devices and wanted to =
try
> WIFI Direct again also. I hope we can skip BIP72 for both of those, =
but
> lets see.)
>=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