Right now Payjoin V2 encodes &ohttp= and &exp= as bip21 URI query keys since that seemed natural as bip78 used them for &pjos=. However, this may present a few problems down the line.
BIP21 parsers would otherwise need to update to support the new ohttp and exp parameters. URL parsers already parse the fragment out of a URL.
QR encoders can encode everything in the &pj= parameter in alphanumeric mode which is more dense but excludes '?', '=', '&'. Each time bip21 uri params switch therefore, the QR encoded incurs overhead to switch between alphanumeric and bytes mode which can be more costly than the advantage.
This stops introducing a precedence problem where multiple bip21 params could be used by conflicting protocols
Right now Payjoin V2 encodes
&ohttp=and&exp=as bip21 URI query keys since that seemed natural as bip78 used them for&pjos=. However, this may present a few problems down the line.Instead of bip21 URI query keys like this
They should be percent-encoded as fragment paramerters in the &pj= url:
This solves problems.
ohttpandexpparameters. URL parsers already parse the fragment out of a URL.&pj=parameter in alphanumeric mode which is more dense but excludes '?', '=', '&'. Each time bip21 uri params switch therefore, the QR encoded incurs overhead to switch between alphanumeric and bytes mode which can be more costly than the advantage.To be done as part of #216