Andreas Schildbach [ARCHIVE] on Nostr: 📅 Original date posted:2014-03-21 📝 Original message:> > Hmm, if we're ...
📅 Original date posted:2014-03-21
📝 Original message:> > Hmm, if we're inventing an URI for bluetooth, I'd rather follow
> existing
> > URI's patterns. BT is strictly point-to-point connection, so BT MAC
> > should be considered as server address, and payment request ID
can be
> > considered as request path. Probably "bt:<bt-mac>/
> > <random_id_of_payment_request>" would be more usual and easily
> > understandable.
>
> Agreed. I used the dash because I feared a slash would need to be
> escaped if used in an URL parameter.
>
> It will need to be escaped, but HTTP URLs used in BIP72 have it
> already, so don't see why we should bother.
Quoting from RFC 3986, Section 3.4. Query: "The characters slash ("/")
and question mark ("?") may represent data within the query component."
> Ok. Btw, I've tested QR possibilities on my PoS screen, in binary mode
> it's limited to about 600 chars, so really I can include only unsigned
> and rather short payment request. Signed requests longer than few
> hundred bytes will not work.
Thanks for testing this. It would be interesting to know what device and
software you used for scanning. But anyway, it falls into the same
ballpark as my tests.
> I probably will skip this anyway and go with bluetooth
> URI scheme we've just agreed + old style payments over p2p network as
> fallback. So no payment requests in QR codes at all from my side.
So BIP72 with a BT URI in the 'r' parameter?
📝 Original message:> > Hmm, if we're inventing an URI for bluetooth, I'd rather follow
> existing
> > URI's patterns. BT is strictly point-to-point connection, so BT MAC
> > should be considered as server address, and payment request ID
can be
> > considered as request path. Probably "bt:<bt-mac>/
> > <random_id_of_payment_request>" would be more usual and easily
> > understandable.
>
> Agreed. I used the dash because I feared a slash would need to be
> escaped if used in an URL parameter.
>
> It will need to be escaped, but HTTP URLs used in BIP72 have it
> already, so don't see why we should bother.
Quoting from RFC 3986, Section 3.4. Query: "The characters slash ("/")
and question mark ("?") may represent data within the query component."
> Ok. Btw, I've tested QR possibilities on my PoS screen, in binary mode
> it's limited to about 600 chars, so really I can include only unsigned
> and rather short payment request. Signed requests longer than few
> hundred bytes will not work.
Thanks for testing this. It would be interesting to know what device and
software you used for scanning. But anyway, it falls into the same
ballpark as my tests.
> I probably will skip this anyway and go with bluetooth
> URI scheme we've just agreed + old style payments over p2p network as
> fallback. So no payment requests in QR codes at all from my side.
So BIP72 with a BT URI in the 'r' parameter?