📅 Original date posted:2011-12-16
🗒️ Summary of this message: A discussion about the use of HTTP(s) transport for a look-up in the PATH portion of the URI and the need for standardization in the development process.
📝 Original message:On Fri, Dec 16, 2011 at 12:54 PM, Andy Parkins <andyparkins at gmail.com> wrote:
[snip]
>
> You've been unfair, the equivalent of your "user at authority.tld" is
> "https://authority.tld/user"; or "https://user.authority.tld/"; or
> "https://google.com/bitcoin/user"; or any of an infinite number of other
> variations that _I_ as the mapper get to choose rather than whoever wrote
> the BIP; all of which are arguably no less "elegant" than that simple email.
>
> There is no equivalent in the other direction though. For someone who
> want's to supply the TX to their mapping server... where does it go in
> "user at authority.tld"?
actually there are many differences. Specifying a standard using a
HTTP(s) transport for a look-up isn't something that has been done in
the PATH portion of the URI and that I was pointing out that there is
*NO* RFC that specifies such for a look-up provide the inverse of many
protocol specifications that did *not* choose that methodology.
What has happened is various schemes are specified, developed and
deployed. I am sure you are familure with many. sip:// ftp:// etc://
many are described at http://en.wikipedia.org/wiki/URI_scheme
NAPTR records (see http://en.wikipedia.org/wiki/NAPTR_record) are
another area that deserves research for those that desire URI schemes.
Understand that I am mearly advocating that as a group this work be
done in standards development process, and that IBANN is one such
effort.
-rick
Rick Wesson [ARCHIVE] /
npub1xz…2925u
2023-06-07 04:48:16
in reply to nevent1q…9nm3
Author Public Key
npub1xz8q68hmzur6c6uje593nscy3q4njx05h4vnxmz2wxxptx7u7casl2925uPublished at
2023-06-07 04:48:16Event JSON
{
"id": "9b3611ab16cd4c105d51e6caad0f0149e13c465398345ea3fb5293f318b9d035",
"pubkey": "308e0d1efb1707ac6b92cd0b19c304882b3919f4bd59336c4a718c159bdcf63b",
"created_at": 1686106096,
"kind": 1,
"tags": [
[
"e",
"f45e7ca88e6eb3dd1e645e8e3cbb476c5b24e8003cb71eebe205594bb2a4d152",
"",
"root"
],
[
"e",
"5ab5c60a8aa94b590d8b18d669d4b74e0cbf6b54d93bd3912271a1a63e8fbe89",
"",
"reply"
],
[
"p",
"99bec497728c848e65549d1a5257d08de97621edcb4b77073269a45dac708d59"
]
],
"content": "📅 Original date posted:2011-12-16\n🗒️ Summary of this message: A discussion about the use of HTTP(s) transport for a look-up in the PATH portion of the URI and the need for standardization in the development process.\n📝 Original message:On Fri, Dec 16, 2011 at 12:54 PM, Andy Parkins \u003candyparkins at gmail.com\u003e wrote:\n\n[snip]\n\n\u003e\n\u003e You've been unfair, the equivalent of your \"user at authority.tld\" is\n\u003e \"https://authority.tld/user\" or \"https://user.authority.tld/\" or\n\u003e \"https://google.com/bitcoin/user\" or any of an infinite number of other\n\u003e variations that _I_ as the mapper get to choose rather than whoever wrote\n\u003e the BIP; all of which are arguably no less \"elegant\" than that simple email.\n\u003e\n\u003e There is no equivalent in the other direction though. For someone who\n\u003e want's to supply the TX to their mapping server... where does it go in\n\u003e \"user at authority.tld\"?\n\nactually there are many differences. Specifying a standard using a\nHTTP(s) transport for a look-up isn't something that has been done in\nthe PATH portion of the URI and that I was pointing out that there is\n*NO* RFC that specifies such for a look-up provide the inverse of many\nprotocol specifications that did *not* choose that methodology.\n\nWhat has happened is various schemes are specified, developed and\ndeployed. I am sure you are familure with many. sip:// ftp:// etc://\nmany are described at http://en.wikipedia.org/wiki/URI_scheme\n\nNAPTR records (see http://en.wikipedia.org/wiki/NAPTR_record) are\nanother area that deserves research for those that desire URI schemes.\n\nUnderstand that I am mearly advocating that as a group this work be\ndone in standards development process, and that IBANN is one such\neffort.\n\n-rick",
"sig": "3b6fa987f0520d80fc912e63a2be5fdb28665c694d11307dae9a968eda6856af633a622d17c51f7ec3216905cd64b2246c1571734d3162bbf43c3a1b64a62b3a"
}