đź“… Original date posted:2014-07-01
đź“ť Original message: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" <andreas at schildbach.de> 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. 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 at 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 at 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 at 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140701/f3b7f78d/attachment.html>;
Alex Kotenko [ARCHIVE] /
npub14j…h00t4
2023-06-07 15:23:26
in reply to nevent1q…atus
Author Public Key
npub14jv7tj33yt72yk8mljmvkck3p4xm5s3mxfpj289up38qqsn9dhkqeh00t4Published at
2023-06-07 15:23:26Event JSON
{
"id": "e3c506dcec8636d4d0a593d4c937c913303ca103ad23f5b11d9e41978c1447af",
"pubkey": "ac99e5ca3122fca258fbfcb6cb62d10d4dba423b3243251cbc0c4e0042656dec",
"created_at": 1686151406,
"kind": 1,
"tags": [
[
"e",
"ee6bc64c1976b2dbf1e8fad28498a66081191f29656dae347bd7d9144f6faaad",
"",
"root"
],
[
"e",
"062066958296beecdeca12690c0bd1ecb8b09baace20d55f275a332ec88a1057",
"",
"reply"
],
[
"p",
"3215b3d77dff1f84eeb5ad46fb1206a8d1657b3ea765a80b5489ece3a702d2bc"
]
],
"content": "📅 Original date posted:2014-07-01\n📝 Original message:Hmm, r1, r2 etc is actually interesting. It takes less chars then array\n(yes, array brackets have to be escaped) and provides unlimited number of\noptions, uniformed approach and priority definition. I'd say that is the\nway to go. Any objections?\nOn 1 Jul 2014 16:39, \"Andreas Schildbach\" \u003candreas at schildbach.de\u003e wrote:\n\n\u003e Ok, one more idea:\n\u003e r= is used for the first URL, and we *think* of it as r0=\n\u003e additional URLs are appended as\n\u003e r1=\n\u003e r2=\n\u003e and so on. This would also define an ordering in case we need it.\n\u003e\n\u003e\n\u003e On 07/01/2014 05:07 PM, Michael Wozniak wrote:\n\u003e \u003e Multiple parameters is currently undefined as far as I can tell. Should\n\u003e the client take the first, last, or ignore it completely if there are\n\u003e multiple of any parameter? I think that’s the point of the parameter\n\u003e pollution discussion, which will define it one way or the other.\n\u003e \u003e\n\u003e \u003e I’m only familiar with the Electrum implementation, which is currently\n\u003e checking for any duplicate parameters and treating the entire URI as\n\u003e invalid if duplicate parameters exist (following the parameter pollution\n\u003e suggestions).\n\u003e \u003e\n\u003e \u003e -\n\u003e \u003e Michael Wozniak\n\u003e \u003e\n\u003e \u003e On Jul 1, 2014, at 10:59 AM, Andreas Schildbach \u003candreas at schildbach.de\u003e\n\u003e wrote:\n\u003e \u003e\n\u003e \u003e\u003e Does r[]= really need to be encoded as r%5B1%5D= ? In this case, I'd\n\u003e \u003e\u003e advocate for a simple array parameter name, like rs= (\"plural\" of r).\n\u003e \u003e\u003e Length really does matter for QR codes.\n\u003e \u003e\u003e\n\u003e \u003e\u003e I'm fine with either multiple r= params or exactly one r= plus zero to\n\u003e \u003e\u003e many r[]= params. Although I think it is a violation of the (current)\n\u003e \u003e\u003e spec to choke on more than one r= parameters, I admit that bitcoinj is\n\u003e \u003e\u003e currently implemented that way. (We could however fix this in a\n\u003e \u003e\u003e maintenance release.)\n\u003e \u003e\u003e\n\u003e \u003e\u003e However, r= should also allow all other protocols, exactly like any of\n\u003e \u003e\u003e the r[]= params. I don't think we should do a distinction here. Also\n\u003e \u003e\u003e because of backwards compatibility to the status quo.\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e On 07/01/2014 03:03 PM, Alex Kotenko wrote:\n\u003e \u003e\u003e\u003e In my mind it's not like the client's phone is going all directions at\n\u003e \u003e\u003e\u003e the same time. There should be a priority method and fallback\n\u003e method(s).\n\u003e \u003e\u003e\u003e ​And I ​see p2p radio as priority, and web as fallback, and BIP21 in\n\u003e the\n\u003e \u003e\u003e\u003e end as always-working-default.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e ​So I'm keeping support for it all while want to be able to provide\n\u003e best\n\u003e \u003e\u003e\u003e user experience.\n\u003e \u003e\u003e\u003e Mike, a while ago in ​this thread you've described contactless cards\n\u003e \u003e\u003e\u003e user experience. I'm also using contactless cards often, and what I'm\n\u003e \u003e\u003e\u003e aiming at is creating same level of user experience for Bitcoin users.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e Encryption over bluetooth is a matter to worry about, and we will\n\u003e \u003e\u003e\u003e introduce that, but we need to sort out more low level problems first\n\u003e \u003e\u003e\u003e before coming into that stage.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e So, the backwards compatibility is a good issue Michael pointed out.\n\u003e \u003e\u003e\u003e While processing of multiple \"r\" parameters is indeed uncertain (since\n\u003e \u003e\u003e\u003e there is no RFC for that various implementations may behave\n\u003e \u003e\u003e\u003e differently), the array solution is somewhat better. The array\n\u003e parameter\n\u003e \u003e\u003e\u003e name is \"r%5B1%5D=\", i.e. it's not \"r=\", and we can add plain \"r=\"\n\u003e \u003e\u003e\u003e alongside. And if particular implementation understands the array\n\u003e \u003e\u003e\u003e construct - it will use it, otherwise it will ignore the \"r%5B1%5D=\"\n\u003e and\n\u003e \u003e\u003e\u003e use only usual \"r=\".\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e This doens't work though for cases where particular implementation\n\u003e \u003e\u003e\u003e understands array construct but doesn't work well with repeating\n\u003e \u003e\u003e\u003e parameters, since it will see two repeating \"r\" - an array and a\n\u003e string.\n\u003e \u003e\u003e\u003e I don't have a solution for that atm.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e If add completely new parameter to solve this we will need to make it\n\u003e an\n\u003e \u003e\u003e\u003e array straight away to address upcoming issues with accommodating other\n\u003e \u003e\u003e\u003e protocols.\n\u003e \u003e\u003e\u003e And then I would also modify existing BIP72 to strictly define \"r=\" as\n\u003e \u003e\u003e\u003e \"http(s)\" ​only ​parameter, while all other protocols (bluetooth, WiFi\n\u003e \u003e\u003e\u003e Direct, ultrasound, chirp etc) should go to the new array parameter.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e ​\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e \u003e\u003e\u003e Open source business process management suite built on Java and Eclipse\n\u003e \u003e\u003e\u003e Turn processes into business applications with Bonita BPM Community\n\u003e Edition\n\u003e \u003e\u003e\u003e Quickly connect people, data, and systems into organized workflows\n\u003e \u003e\u003e\u003e Winner of BOSSIE, CODIE, OW2 and Gartner awards\n\u003e \u003e\u003e\u003e http://p.sf.net/sfu/Bonitasoft\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e _______________________________________________\n\u003e \u003e\u003e\u003e Bitcoin-development mailing list\n\u003e \u003e\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e \u003e\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e \u003e\u003e Open source business process management suite built on Java and Eclipse\n\u003e \u003e\u003e Turn processes into business applications with Bonita BPM Community\n\u003e Edition\n\u003e \u003e\u003e Quickly connect people, data, and systems into organized workflows\n\u003e \u003e\u003e Winner of BOSSIE, CODIE, OW2 and Gartner awards\n\u003e \u003e\u003e http://p.sf.net/sfu/Bonitasoft\n\u003e \u003e\u003e _______________________________________________\n\u003e \u003e\u003e Bitcoin-development mailing list\n\u003e \u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e \u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e ------------------------------------------------------------------------------\n\u003e \u003e Open source business process management suite built on Java and Eclipse\n\u003e \u003e Turn processes into business applications with Bonita BPM Community\n\u003e Edition\n\u003e \u003e Quickly connect people, data, and systems into organized workflows\n\u003e \u003e Winner of BOSSIE, CODIE, OW2 and Gartner awards\n\u003e \u003e http://p.sf.net/sfu/Bonitasoft\n\u003e \u003e _______________________________________________\n\u003e \u003e Bitcoin-development mailing list\n\u003e \u003e Bitcoin-development at lists.sourceforge.net\n\u003e \u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e \u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Open source business process management suite built on Java and Eclipse\n\u003e Turn processes into business applications with Bonita BPM Community Edition\n\u003e Quickly connect people, data, and systems into organized workflows\n\u003e Winner of BOSSIE, CODIE, OW2 and Gartner awards\n\u003e http://p.sf.net/sfu/Bonitasoft\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140701/f3b7f78d/attachment.html\u003e",
"sig": "2759d9729dfd90fb3e038bd05e1c4584a3e4336c9b983389b9972d5b3de70ff13a56dd3542f0c5825ef08aaa743b9b231b982b1505dab28767e444ccde3a718b"
}