William Swanson [ARCHIVE] on Nostr: 📅 Original date posted:2014-03-06 📝 Original message:Hello, I am attempting to ...
📅 Original date posted:2014-03-06
📝 Original message:Hello,
I am attempting to write a parser for bip-0021 URI's, including
support for the new bip-0072 payment parameters. My goal is absolute
correctness. Unfortunately, these BIP's have a few ambiguities and
mistakes which ought to be corrected.
First, I would like to point out that internet RFC 3986 governs the
general syntax for URI's. It obsoletes RFC 1738 and various other
early RFC's. Since RFC 3986 came out in 2005, I think we can agree
that any bitcoin URI scheme should use this and not the earlier ones.
Unfortunately, bip-0021 never actually mentions RFC 3986, which is a
big omission. Even worse, bip-0072 explicitly refers to RFC 1738,
which is obsolete. This is a problem, since the old, obsolete standard
requires more escapes than are actually necessary. Updating bip-0072
to refer to RFC 3986 instead would allow shorter, more readable
bitcoin URI's (things like slashes in payment addresses wouldn't need
to be escaped).
Secondly, neither of the bip's describe what to do with international
characters. I doubt anybody wants to limit the "label" and "message"
parameters to 7-bit ASCII, so a character encoding needs to be
defined. RFC reccomends that all new URI schemes use UTF-8 as their
encoding, which is perfectly reasonable. The bip-0021 standard just
needs to actually say so.
Finally, there is an error in the bip-0021 BNF grammar, which never
mentions the '&' separator between query elements.
What is the procedure for getting these BIP's corrected? Submit a pull
request with the changes? Hopefully we can all agree that these fixes
are useful and necessary.
-William
P.S. The bitcoin-qt client uses QUrl to parse bitcoin uri's, and that
is based on RFC 3986. Thus, the bitcoin-qt client is probably already
implementing these suggestions.
Published at
2023-06-07 15:14:59Event JSON
{
"id": "e134ef582155bc79805d214dc103baf61192f95534f14e2bed5a609af6394dd2",
"pubkey": "a178a4d8dc03df766d640bbff9f4a535decb16c595ad471cabee59e7f78f439d",
"created_at": 1686150899,
"kind": 1,
"tags": [
[
"e",
"e8eeac2f8317c4b91dd8d77b196d0f97e998f7d168d88a53c92712f0f75f00dc",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2014-03-06\n📝 Original message:Hello,\nI am attempting to write a parser for bip-0021 URI's, including\nsupport for the new bip-0072 payment parameters. My goal is absolute\ncorrectness. Unfortunately, these BIP's have a few ambiguities and\nmistakes which ought to be corrected.\n\nFirst, I would like to point out that internet RFC 3986 governs the\ngeneral syntax for URI's. It obsoletes RFC 1738 and various other\nearly RFC's. Since RFC 3986 came out in 2005, I think we can agree\nthat any bitcoin URI scheme should use this and not the earlier ones.\n\nUnfortunately, bip-0021 never actually mentions RFC 3986, which is a\nbig omission. Even worse, bip-0072 explicitly refers to RFC 1738,\nwhich is obsolete. This is a problem, since the old, obsolete standard\nrequires more escapes than are actually necessary. Updating bip-0072\nto refer to RFC 3986 instead would allow shorter, more readable\nbitcoin URI's (things like slashes in payment addresses wouldn't need\nto be escaped).\n\nSecondly, neither of the bip's describe what to do with international\ncharacters. I doubt anybody wants to limit the \"label\" and \"message\"\nparameters to 7-bit ASCII, so a character encoding needs to be\ndefined. RFC reccomends that all new URI schemes use UTF-8 as their\nencoding, which is perfectly reasonable. The bip-0021 standard just\nneeds to actually say so.\n\nFinally, there is an error in the bip-0021 BNF grammar, which never\nmentions the '\u0026' separator between query elements.\n\nWhat is the procedure for getting these BIP's corrected? Submit a pull\nrequest with the changes? Hopefully we can all agree that these fixes\nare useful and necessary.\n\n-William\n\nP.S. The bitcoin-qt client uses QUrl to parse bitcoin uri's, and that\nis based on RFC 3986. Thus, the bitcoin-qt client is probably already\nimplementing these suggestions.",
"sig": "3865aa8dc23f38ef3baf4f0d9a36dc0dc6e66338700abf5b46475928974444c0bf57d61e7c0bc165329350bb3b6fc52bb2f6447a7046f62511e1524a5d346238"
}