Keep in mind that links don't always come embedded in html. Think of native
mobile apps.
On Sat, Apr 26, 2014 at 10:43 AM, Ross Nicoll j...@jrn.me.uk wrote:
I'd be very cautious of security implications of embedding files into
the payment request. Even file formats one would presume safe,
The main area of concern is handling unexpected problems while sending
the Payment message, or receiving the corresponding PaymentACK message.
For example, in case of a transport layer failure or non-200 HTTP status
code while sending the Payment message, what should the wallet software
do
Dear Gavin, Andreas,
I'd see standardisation (or at least suggested standards) for error
handling as positive for consistency of user experience. I do see what
you mean about over-specification, however.
Thanks for the feedback, I've taken the main points and created two pull
requests:
PaymentRequests are limited to 50,000 bytes. I can't think of a reason why
Payment messages would need to be any bigger than that. Submit a pull
request to the existing BIP.
In future it might be nice to have images and things in the payment
requests, to make UIs look prettier. But with the
I'd be very cautious of security implications of embedding files into
the payment request. Even file formats one would presume safe, such as
images, have had security issues (i.e.
https://technet.microsoft.com/library/security/ms11-006 )
Longer term I was wondering about embedding the
Dear Gavin, all,
Going over the payment protocol specifications, I've noticed that
there's appears to be a lack of specificity on handling of error states.
In most cases there are reasonably obvious solutions, however it would
seem positive to formalise processes to ensure consistency. I'm
6 matches
Mail list logo
