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 busi
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" wrote:
>
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.
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
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 viola
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 b
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 suppo
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 o
>
> 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
> re
9 matches
Mail list logo
