Author: Andreas Schildbach 2014-07-01 14:59:07
Published on: 2014-07-01T14:59:07+00:00
The discussion on the Bitcoin-development mailing list involves the need to encode r[]= as r%5B1%5D= in QR codes. A suggestion is made to use a simple array parameter name such as rs= instead of r[]. It is agreed that multiple r= params or one r= plus zero to many r[]= params are acceptable, but it may violate the current specification to choke on more than one r= parameters. The backward compatibility of r= is important and should allow all other protocols, similar to any of the r[]= params.Alex Kotenko suggests a priority method and fallback method(s) for providing the best user experience. Encryption over Bluetooth is a concern, and low-level problems need to be sorted out before introducing it. The array solution is preferable since the array parameter name is "r%5B1%5D=" instead of "r=", and plain "r=" can be added alongside it. This approach ignores the "r%5B1%5D=" if a particular implementation does not understand the array construct. However, this does not work well with repeating parameters where an implementation understands the array construct but doesn't work well with repeating parameters because it sees two repeating "r" - an array and a string.In conclusion, adding a completely new parameter would be the best solution to address upcoming issues with accommodating other protocols, and modify existing BIP72 to strictly define "r=" as an "http(s)" only parameter while all other protocols (bluetooth, WiFi Direct, ultrasound, chirp, etc.) should go to the new array parameter.
Updated on: 2023-06-08T01:07:00.479154+00:00