However 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.
On 07/01/2014 10:18 AM, Mike Hearn wrote:
However 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
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’t
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
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
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
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.
Hmm, r1, r2 etc is actually interesting. It takes less chars then array
(yes, array brackets have to be escaped) and provides unlimited number of
options, uniformed approach and priority definition. I'd say that is the
way to go. Any objections?
On 1 Jul 2014 16:39, Andreas Schildbach
Nope, r1/r2 sounds good to me. BTW we should update the spec to reflect
that escaping is largely unnecessary in many cases.
--
Open source business process management suite built on Java and Eclipse
Turn processes into
9 matches
Mail list logo
