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: <louibr$8gc$1@ger.gmane.org>
Date: Tue, 1 Jul 2014 11:07:23 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <1016E2A3-C678-46FA-B80E-F9D86FDEA213@osfda.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>
	<louibr$8gc$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

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 <andreas@schildbach.de> =
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