diff options
Diffstat (limited to 'bip-0073.mediawiki')
| -rw-r--r-- | bip-0073.mediawiki | 43 |
1 files changed, 20 insertions, 23 deletions
diff --git a/bip-0073.mediawiki b/bip-0073.mediawiki index 07add74..4414351 100644 --- a/bip-0073.mediawiki +++ b/bip-0073.mediawiki @@ -1,8 +1,6 @@ -{{bip}} - <pre> BIP: 73 - Title: Use "Accept" header for response type negotiation with Payment Request URLs + Title: Use "Accept" header for response type negotiation with Payment Request URLs Author: Stephen Pair <stephen@bitpay.com> Status: Draft Type: Standards Track @@ -11,15 +9,15 @@ ==Abstract== -This BIP describes an enhancement to the payment protocol ([[BIP 0070|BIP 70]]) +This BIP describes an enhancement to the payment protocol ([[bip-0070.mediawiki|BIP 70]]) that addresses the need for short URLs when scanning from QR codes. It -generalizes the specification for the behavior of a payment request URL in a -way that allows the client and server to negotiate the content of the +generalizes the specification for the behavior of a payment request URL in a +way that allows the client and server to negotiate the content of the response using the HTTP Accept: header field. Specifically, the client can indicate to the server whether it prefers to receive a bitcoin URI or a payment request. -Implementation of this BIP does not require full payment request ([[BIP 0070|BIP 70]]) support. +Implementation of this BIP does not require full payment request ([[bip-0070.mediawiki|BIP 70]]) support. ==Motivation== @@ -29,7 +27,7 @@ downloaded. This creates long URIs that, when rendered as a QR code, have a high information density. Dense QR codes can be difficult to scan resulting in a more frustrating user experience. The goal is to create a standard that would allow QR scanning wallets to use less dense QR codes. It also makes -general purpose QR code scanners more usable with bitcoin accepting +general purpose QR code scanners more usable with bitcoin accepting websites. ==Specification== @@ -37,35 +35,35 @@ websites. QR scanning wallets will consider a non bitcoin URI scanned from a QR code to be an end point where either a bitcoin URI or a payment request can be obtained. -A wallet client uses the Accept: HTTP header to specify whether it can accept +A wallet client uses the Accept: HTTP header to specify whether it can accept a payment request, a URI, or both. A media type of text/uri-list specifies that the client accepts a bitcoin URI. A media type of application/bitcoin-paymentrequest -specifies that the client can process a payment request. In the absence of an -Accept: header, the server is expected to respond with text/html suitable for +specifies that the client can process a payment request. In the absence of an +Accept: header, the server is expected to respond with text/html suitable for rendering in a browser. An HTML response will ensure that QR codes scanned by non Bitcoin wallet QR scanners are useful (they could render an HTML page with a payment link that when clicked would open a wallet on the device). -It is not required that the client and server support the full semantics of an +It is not required that the client and server support the full semantics of an HTTP Accept header. If application/bitcoin-paymentrequest is specified in the header, the server should send a payment request regardless of anything else -specified in the Accept header. If text/uri-list is specified (but not -application/bitcoin-paymentrequest), a valid Bitcoin URI should be returned. If +specified in the Accept header. If text/uri-list is specified (but not +application/bitcoin-paymentrequest), a valid Bitcoin URI should be returned. If neither is specified, the server can return an HTML page. When a uri-list is returned only the first item in the list is used (and expected to be a bitcoin URI), any additional URIs should be ignored. ==Compatibility== -Only QR scanning wallets that implement this BIP will be able to process QR +Only QR scanning wallets that implement this BIP will be able to process QR codes containing payment request URLs. There are two possible workarounds for QR -scanning wallets that do not implement this BIP: 1) the server gives the user an -option to change the QR code to a bitcoin: URI or 2) the user scans the code with +scanning wallets that do not implement this BIP: 1) the server gives the user an +option to change the QR code to a bitcoin: URI or 2) the user scans the code with a generic QR code scanner. -In the second scenario, if the server responds with a webpage containing a link +In the second scenario, if the server responds with a webpage containing a link to a bitcoin URI, the user can complete the payment by clicking that link provided -the user has a wallet installed on their device and it supports bitcoin URIs. If the +the user has a wallet installed on their device and it supports bitcoin URIs. If the wallet/device does not have support for bitcoin URIs, the user can fall back on address copy/paste. @@ -74,10 +72,9 @@ implementing BIP 70 make use of the Accept: HTTP header when retrieving a payment request. ==Examples== -The first image below is of a bitcoin URI with an amount and payment request -specified (note, this is a fairly minimal URI as it does not contain a +The first image below is of a bitcoin URI with an amount and payment request +specified (note, this is a fairly minimal URI as it does not contain a label and the request URL is of moderate size). The second image is a QR code with only the payment request url specified. -[[File:BIP_0073a.png]] [[File:BIP_0073b.png]] -[[Category:BIP]] +<img src=bip-0073/a.png></img><img src=bip-0073/b.png></img> |