đź“… Original date posted:2014-07-01
đź“ť Original message: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
>
Andreas Schildbach [ARCHIVE] /
npub1xg…adsv7
2023-06-07 15:23:25
in reply to nevent1q…d5su
Author Public Key
npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7Published at
2023-06-07 15:23:25Event JSON
{
"id": "062066958296beecdeca12690c0bd1ecb8b09baace20d55f275a332ec88a1057",
"pubkey": "3215b3d77dff1f84eeb5ad46fb1206a8d1657b3ea765a80b5489ece3a702d2bc",
"created_at": 1686151405,
"kind": 1,
"tags": [
[
"e",
"ee6bc64c1976b2dbf1e8fad28498a66081191f29656dae347bd7d9144f6faaad",
"",
"root"
],
[
"e",
"6f3b0bd093664b3a8e8fd638cf1a4452b002a0bcaa54f95525d50200b42df3b4",
"",
"reply"
],
[
"p",
"5dfbe446644f4260520516c70aa838e0d4a0c8577a552092ac76ea0d71e4f5cb"
]
],
"content": "📅 Original date posted:2014-07-01\n📝 Original message:Ok, one more idea:\nr= is used for the first URL, and we *think* of it as r0=\nadditional URLs are appended as\nr1=\nr2=\nand so on. This would also define an ordering in case we need it.\n\n\nOn 07/01/2014 05:07 PM, Michael Wozniak wrote:\n\u003e 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.\n\u003e \n\u003e 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).\n\u003e \n\u003e -\n\u003e Michael Wozniak\n\u003e \n\u003e On Jul 1, 2014, at 10:59 AM, Andreas Schildbach \u003candreas at schildbach.de\u003e wrote:\n\u003e \n\u003e\u003e Does r[]= really need to be encoded as r%5B1%5D= ? In this case, I'd\n\u003e\u003e advocate for a simple array parameter name, like rs= (\"plural\" of r).\n\u003e\u003e Length really does matter for QR codes.\n\u003e\u003e\n\u003e\u003e I'm fine with either multiple r= params or exactly one r= plus zero to\n\u003e\u003e many r[]= params. Although I think it is a violation of the (current)\n\u003e\u003e spec to choke on more than one r= parameters, I admit that bitcoinj is\n\u003e\u003e currently implemented that way. (We could however fix this in a\n\u003e\u003e maintenance release.)\n\u003e\u003e\n\u003e\u003e However, r= should also allow all other protocols, exactly like any of\n\u003e\u003e the r[]= params. I don't think we should do a distinction here. Also\n\u003e\u003e because of backwards compatibility to the status quo.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On 07/01/2014 03:03 PM, Alex Kotenko wrote:\n\u003e\u003e\u003e In my mind it's not like the client's phone is going all directions at\n\u003e\u003e\u003e the same time. There should be a priority method and fallback method(s).\n\u003e\u003e\u003e ​And I ​see p2p radio as priority, and web as fallback, and BIP21 in the\n\u003e\u003e\u003e end as always-working-default.\n\u003e\u003e\u003e\n\u003e\u003e\u003e ​So I'm keeping support for it all while want to be able to provide best\n\u003e\u003e\u003e user experience. \n\u003e\u003e\u003e Mike, a while ago in ​this thread you've described contactless cards\n\u003e\u003e\u003e user experience. I'm also using contactless cards often, and what I'm\n\u003e\u003e\u003e aiming at is creating same level of user experience for Bitcoin users. \n\u003e\u003e\u003e\n\u003e\u003e\u003e Encryption over bluetooth is a matter to worry about, and we will\n\u003e\u003e\u003e introduce that, but we need to sort out more low level problems first\n\u003e\u003e\u003e before coming into that stage. \n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e So, the backwards compatibility is a good issue Michael pointed out. \n\u003e\u003e\u003e While processing of multiple \"r\" parameters is indeed uncertain (since\n\u003e\u003e\u003e there is no RFC for that various implementations may behave\n\u003e\u003e\u003e differently), the array solution is somewhat better. The array parameter\n\u003e\u003e\u003e name is \"r%5B1%5D=\", i.e. it's not \"r=\", and we can add plain \"r=\"\n\u003e\u003e\u003e alongside. And if particular implementation understands the array\n\u003e\u003e\u003e construct - it will use it, otherwise it will ignore the \"r%5B1%5D=\" and\n\u003e\u003e\u003e use only usual \"r=\". \n\u003e\u003e\u003e\n\u003e\u003e\u003e This doens't work though for cases where particular implementation\n\u003e\u003e\u003e understands array construct but doesn't work well with repeating\n\u003e\u003e\u003e parameters, since it will see two repeating \"r\" - an array and a string.\n\u003e\u003e\u003e I don't have a solution for that atm. \n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e If add completely new parameter to solve this we will need to make it an\n\u003e\u003e\u003e array straight away to address upcoming issues with accommodating other\n\u003e\u003e\u003e protocols. \n\u003e\u003e\u003e And then I would also modify existing BIP72 to strictly define \"r=\" as\n\u003e\u003e\u003e \"http(s)\" ​only ​parameter, while all other protocols (bluetooth, WiFi\n\u003e\u003e\u003e Direct, ultrasound, chirp etc) should go to the new array parameter.\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e ​\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\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 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\n\u003e\u003e\u003e\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\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\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 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 \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",
"sig": "f8c2faf132d0f62f590b2853dd1ca91c6aeccbe069fde92799d962d0bb1a16ad73d48395a41f41e85dc70c8c0bd1ffcd135dfb56aa9829e7aab7ac99c8d78a35"
}