BIP 0020: Difference between revisions
Line 141: | Line 141: | ||
==References== | |||
<references/> | <references/> |
Revision as of 12:05, 10 January 2011
RFC 3986
the following is taken from wikipedia
Internet standard STD 66 (also RFC 3986) defines the generic syntax to be used in all URI schemes. Every URI is defined as consisting of four parts, as follows:
<scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]
The scheme name consists of a letter followed by any combination of letters, digits, and the plus ("+"), period ("."), or hyphen ("-") characters; and is terminated by a colon (":").
The hierarchical part of the URI is intended to hold identification information hierarchical in nature. Usually this part begins with a double forward slash ("//"), followed by an authority part and an optional path.
- The authority part holds an optional user information part terminated with "@" (e.g.
username:password@
), a hostname (i.e. domain name or IP address), and an optional port number preceded by a colon ":".
- The path part is a sequence of segments (conceptually similar to directories, though not necessarily representing them) separated by a forward slash ("/"). Each segment can contain parameters separated from it using a semicolon (";"), though this is rarely used in practice.
The query is an optional part separated with a question mark, which contains additional identification information which is not hierarchical in nature. The query string syntax is not generically defined, but is commonly organized as a sequence of <key>=<value>
pairs separated by a semicolon[1][2][3] or separated by an ampersand, for example:
Semicolon:key1=value1;key2=value2;key3=value3
Ampersand:key1=value1&key2=value2&key3=value3
The fragment is an optional part separated from the front parts by a hash ("#"). It holds additional identifying information that provides direction to a secondary resource, e.g. a section heading in an article identified by the remainder of the URI. When the primary resource is an HTML document, the fragment is often an id
attribute of a specific element and web browsers will make sure this element is visible.
tcatm
I propose a scheme like this:
() means optional, $* are placeholders
bitcoin:($label@)$address(?$query)(#$message)
Variables
label: Label for that address (e.g. name of receiver) address: bitcoin address query: pairs of key=value seperated by & message: optional message that is shown to the user after scanning the QR code
Query keys
amount: amount of BTC
Examples
Just the address:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt
Address with name:
bitcoin:tcatm@18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt
Request to send 20.30 BTC to me:
bitcoin:tcatm@18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=20.30
Request to send 50 BTC with message:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=50#Payment%20for%20product%20xyz
Characters must be URI encoded.
tcatm, modified by LukeJr
I propose a scheme like this:
[] means optional, <> are placeholders
bitcoin:<address>?amount=<size><unit>[&label=<label>][&message=<message>]
Variables
- label: Label for that address (e.g. name of receiver)
- address: bitcoin address
- message: optional message that is shown to the user after scanning the QR code
- size: amount of $unit
- unit: BTC, [ᵗˢᵐᵇ]TBC[ᵗˢᵐᵇ], or null/omitted (which refers to the base unit)
Examples
Just the address:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt
Address with name:BTC
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?label=tcatm
Request to send 20.30 BTC to tcatm:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=20.30BTC&label=tcatm
Request to send 400 TBC to Luke:
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=400TBC
Request to send 5 uBTC:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=500
Request to send 50 BTC with message:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8qztaWWXt?amount=50BTC&label=tcatm&message=Payment%20for%20product%20xyz
Characters must be URI encoded properly.
BNF syntax
bitcoinurn = "bitcoin:" bitcoinaddress [ ";version=" bitcoinversion ] [ "?" bitcoinparams ] bitcoinaddress = FIXME :) bitcoinversion = "1.0" bitcoinparams = *bitcoinparam bitcoinparam = amountparam | labelparam | messageparam amountparam = "amount=" amount amount = amountdecimal | amounthex | amounttonal amountdecimal = digits btcunits amounthex = "x" hexdigits bitcoinunit amounttonal = tonaldigits tbcunits bitcoinunit = btcunits | tbcunits btcunits = "BTC" | "BTCents" | "uBTC" | "uBTCents" tbcunits = tbcunitsunicode | tbcunitsascii | tbcunitsfull tbcunitsunicode = "ᵇTBC" | "ᵐTBC" | "ˢTBC" | "ᵗTBC" | "TBC" | "TBCᵗ" | "TBCˢ" | "TBCᵐ" | "TBCᵇ" tbcunitsascii = "bTBC" | "mTBC" | "sTBC" | "tTBC" | "TBC" | "TBCt" | "TBCs" | "TBCm" | "TBCb" tbcunitsfull = "tran-TBC" | "song-TBC" | "tam-TBC" | "bong-TBC" | "mill-TBC" | "san-TBC" | "ton-TBC" | "TBC" | "TBC-ton" | "TBC-san" | "TBC-mill" | "TBC-bong" labelparam = "label=" *uchar messageparam = "label=" *uchar
marcusaurelius
References
- ↑ RFC 1866 section 8.2.1 : by Tim Berners-Lee in 1995 encourages CGI authors to support ';' in addition to '&'.
- ↑ HTML 4.01 Specification: Implementation, and Design Notes: "CGI implementors support the use of ";" in place of "&" to save authors the trouble of escaping "&" characters in this manner."
- ↑ Hypertext Markup Language - 2.0 "CGI implementors are encouraged to support the use of ';' in place of '&' "