From: Michael Wozniak <mw@osfda•org>
To: Andreas Schildbach <andreas@schildbach•de>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Date: Tue, 1 Jul 2014 11:07:23 -0400 [thread overview]
Message-ID: <1016E2A3-C678-46FA-B80E-F9D86FDEA213@osfda.org> (raw)
In-Reply-To: <louibr$8gc$1@ger.gmane.org>
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 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[]= 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 violation of the (current)
> spec to choke on more than one r= parameters, I admit that bitcoinj is
> currently implemented that way. (We could however fix this in a
> maintenance release.)
>
> However, r= should also allow all other protocols, exactly like any of
> the r[]= params. I don't think we should do a distinction here. Also
> because of backwards compatibility to the status quo.
>
>
> 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).
>> 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 be able to provide best
>> user experience.
>> Mike, a while ago in this 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.
>>
>> 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.
>>
>>
>> So, the backwards compatibility is a good issue Michael pointed out.
>> 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=", i.e. it's not "r=", and we can add plain "r="
>> alongside. And if particular implementation understands the array
>> construct - it will use it, otherwise it will ignore the "r%5B1%5D=" and
>> use only usual "r=".
>>
>> 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.
>>
>>
>> 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.
>> And then I would also modify existing BIP72 to strictly define "r=" as
>> "http(s)" only parameter, while all other protocols (bluetooth, WiFi
>> Direct, ultrasound, chirp etc) should go to the new array parameter.
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>
>
>
> ------------------------------------------------------------------------------
> 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
next prev parent reply other threads:[~2014-07-01 15:07 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-27 11:59 Andreas Schildbach
2014-01-27 13:11 ` Mike Hearn
2014-01-27 18:18 ` Andreas Schildbach
2014-01-27 18:34 ` Mike Hearn
2014-01-27 20:53 ` [Bitcoin-development] Experiment with linking payment requests via href Andreas Schildbach
2014-01-27 21:47 ` Mike Hearn
2014-01-27 17:11 ` [Bitcoin-development] Payment Protocol for Face-to-face Payments Jeremy Spilman
2014-01-27 17:39 ` Andreas Schildbach
2014-01-27 18:18 ` Jeremy Spilman
2014-01-27 20:34 ` Roy Badami
2014-01-29 14:57 ` Christophe Biocca
2014-01-30 10:46 ` Andreas Schildbach
2014-01-30 10:50 ` Mike Hearn
2014-02-07 23:15 ` Andreas Schildbach
2014-03-02 9:47 ` Andreas Schildbach
2014-03-02 11:50 ` Mike Hearn
2014-03-20 2:22 ` Alex Kotenko
2014-03-20 3:31 ` Jeff Garzik
2014-03-20 8:09 ` Andreas Schildbach
2014-03-20 10:36 ` Mike Hearn
2014-03-20 12:12 ` Adam Back
2014-03-20 12:20 ` Mike Hearn
2014-03-20 17:31 ` Jeff Garzik
2014-03-20 17:42 ` Alex Kotenko
2014-03-20 18:01 ` Jeff Garzik
2014-03-21 10:28 ` Andreas Schildbach
2014-03-21 13:59 ` Alex Kotenko
2014-03-22 16:35 ` Jeff Garzik
2014-03-22 16:45 ` Mike Hearn
2014-03-22 16:55 ` Mark Friedenbach
2014-03-22 17:24 ` Jeff Garzik
2014-03-22 17:30 ` Mike Hearn
2014-03-23 3:47 ` Alex Kotenko
2014-03-21 10:25 ` Andreas Schildbach
2014-03-21 10:59 ` Adam Back
2014-03-21 11:08 ` Mike Hearn
2014-03-21 11:33 ` Mike Hearn
2014-03-21 12:25 ` Adam Back
2014-03-21 13:07 ` Mike Hearn
2014-03-20 18:20 ` Alex Kotenko
2014-03-20 18:31 ` Mike Hearn
2014-03-20 18:50 ` Alex Kotenko
2014-03-20 21:52 ` Roy Badami
2014-03-20 23:02 ` Mike Hearn
2014-03-26 22:48 ` Roy Badami
2014-03-26 22:56 ` Mike Hearn
2014-03-26 23:20 ` Andreas Schildbach
2014-03-27 10:08 ` Mike Hearn
2014-03-27 13:31 ` vv01f
2014-06-30 19:26 ` Alex Kotenko
2014-07-01 8:18 ` Mike Hearn
2014-07-01 9:48 ` Andreas Schildbach
2014-07-01 10:42 ` Michael Wozniak
2014-07-01 13:03 ` Alex Kotenko
2014-07-01 14:59 ` Andreas Schildbach
2014-07-01 15:07 ` Michael Wozniak [this message]
2014-07-01 15:39 ` Andreas Schildbach
2014-07-01 17:18 ` Alex Kotenko
2014-07-01 17:59 ` Mike Hearn
2014-07-02 8:49 ` Alex Kotenko
2014-03-21 10:43 ` Andreas Schildbach
2014-03-20 8:08 ` Andreas Schildbach
2014-03-20 16:14 ` Alex Kotenko
2014-03-21 9:47 ` Andreas Schildbach
2014-03-21 13:54 ` Alex Kotenko
2014-03-21 14:51 ` Andreas Schildbach
2014-03-21 15:38 ` Alex Kotenko
2014-03-21 15:20 ` Andreas Schildbach
2014-03-21 15:24 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1016E2A3-C678-46FA-B80E-F9D86FDEA213@osfda.org \
--to=mw@osfda$(echo .)org \
--cc=andreas@schildbach$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox