Re: [bitcoin-dev] Proposal for a few IANA mime-types related to Bitcoin
Hi Peter, Yep, I think it is a good idea just to do new BIP and ignore IANA opinion on the matter. I can write it since I was going to propose pretty much the same thing some time ago. I will share the draft in this mail list in a week. Kind regards, Maxim Orlovsky LNP/BP Standards Association http://lnp-bp.org github.com/dr-orlovsky Original Message On 1 Sep 2021, 15:39, Peter D. Gray via bitcoin-dev wrote: >> ... I tried doing this with "application/bitcoin-psbt" back in >> 2019 but it was not accepted... > > Thanks for this background. > > Based on your experience, we should probably ignore the IANA then, > and just declare a few useful "mime types" (note the quotes) in a > new BIP. We can then agree inside the Bitcoin community on their > usage and meaning. > > Anyone want to write that BIP and shepherd it? I can support you > but I'd rather write code. > > --- > @DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10 > > On Tue, Aug 31, 2021 at 07:46:55PM +, Andrew Chow wrote: >> Hi Peter, >> >> It would be nice to have mime types registered for Bitcoin things, but >> I'm not sure that it will be possible, at least not in the way that we >> would like. I tried doing this with "application/bitcoin-psbt" back in >> 2019 but it was not accepted. From that attempt, here is what I have >> learned: >> >> There are only a few accepted top level types, so we would not be able >> to use "bitcoin" as the top level (unless you want to submit an RFC to >> add a "bitcoin" top level). Of the available top level types, >> "application" is the most appropriate for Bitcoin. >> >> Next is the tree that the mime type should be in. The best would be the >> Standards tree, but it has some requirements that Bitcoin doesn't really >> meet. In order to be in the standards tree, the registration must be >> either associated with an IETF specification (so a RFC) or registered by >> a recognized standards related organization. Unfortunately the closest >> thing to a standards organization that Bitcoin has is the BIPs process, >> and that is not a really a standards organization nor is it recognized >> by IANA. So in order to register the mimetypes as Standards tree types, >> we would need to write an RFC, but this could be an independent >> submission (https://www.rfc-editor.org/about/independent/) rather than >> IETF-stream submission. I did not continue to pursue this because I >> didn't have the time. >> >> Another alternative would be to use the Vendor tree, but that would >> prefix the mimetype with "vnd." so it would end up being something like >> "application/vnd.bitcoin.psbt". I did not think this was an reasonable >> so I did not continue to pursue this avenue. >> >> >> Andrew Chow >> >> On 8/31/21 2:27 PM, Peter D. Gray via bitcoin-dev wrote: >> > Hi list! >> > >> > I am proposing to register the following MIME (RFC 2046) media types with >> > the IANA: >> > >> > >> > bitcoin/psbt >> > >> > - aka. a BIP-174 file, in binary >> > - does not make any claims about signed/unsigned status; lets leave that >> > to the file >> > >> > bitcoin/txn >> > >> > - aka. wire-ready fully-signed transaction in binary >> > >> > bitcoin/uri >> > >> > - aka >> > [BIP-21](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki) >> > - could be just a bare bech32 or base58 payment address >> > - but can also encode amount, comments in URL args >> > - potentially interesting as a response to 402 - Payment required >> > >> > >> > Other thoughts >> > >> > - some mime-types are proposed in BIP-71 but those are unrelated to above, >> > and never >> > seem to have been registered >> > >> > - for those who like to encode their binary as base64 or hex, that can be >> > indicated >> > as "encoding=hex" or "encoding=base64" in the optional parameters, just >> > like >> > "text/plain; encoding=utf-8" does. However, the default must be binary. >> > >> > - although the above are useful for web servers, they are also useful >> > elsewhere and I >> > intend to use them in NFC (NDEF records) where a shorter length is >> > critical. >> > >> > - I have no idea how easily IANA will accept these proposals. >> > >> > - current approved mime types: >> > https://www.iana.org/assignments/media-types/media-types.xhtml >> > >> > Thoughts? >> > >> > --- >> > @DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10 >> > >> > ___ >> > bitcoin-dev mailing list >> > bitcoin-dev@lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal for a few IANA mime-types related to Bitcoin
> ... I tried doing this with "application/bitcoin-psbt" back in > 2019 but it was not accepted... Thanks for this background. Based on your experience, we should probably ignore the IANA then, and just declare a few useful "mime types" (note the quotes) in a new BIP. We can then agree inside the Bitcoin community on their usage and meaning. Anyone want to write that BIP and shepherd it? I can support you but I'd rather write code. --- @DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10 On Tue, Aug 31, 2021 at 07:46:55PM +, Andrew Chow wrote: > Hi Peter, > > It would be nice to have mime types registered for Bitcoin things, but > I'm not sure that it will be possible, at least not in the way that we > would like. I tried doing this with "application/bitcoin-psbt" back in > 2019 but it was not accepted. From that attempt, here is what I have > learned: > > There are only a few accepted top level types, so we would not be able > to use "bitcoin" as the top level (unless you want to submit an RFC to > add a "bitcoin" top level). Of the available top level types, > "application" is the most appropriate for Bitcoin. > > Next is the tree that the mime type should be in. The best would be the > Standards tree, but it has some requirements that Bitcoin doesn't really > meet. In order to be in the standards tree, the registration must be > either associated with an IETF specification (so a RFC) or registered by > a recognized standards related organization. Unfortunately the closest > thing to a standards organization that Bitcoin has is the BIPs process, > and that is not a really a standards organization nor is it recognized > by IANA. So in order to register the mimetypes as Standards tree types, > we would need to write an RFC, but this could be an independent > submission (https://www.rfc-editor.org/about/independent/) rather than > IETF-stream submission. I did not continue to pursue this because I > didn't have the time. > > Another alternative would be to use the Vendor tree, but that would > prefix the mimetype with "vnd." so it would end up being something like > "application/vnd.bitcoin.psbt". I did not think this was an reasonable > so I did not continue to pursue this avenue. > > > Andrew Chow > > On 8/31/21 2:27 PM, Peter D. Gray via bitcoin-dev wrote: > > Hi list! > > > > I am proposing to register the following MIME (RFC 2046) media types with > > the IANA: > > > > > > bitcoin/psbt > > > > - aka. a BIP-174 file, in binary > > - does not make any claims about signed/unsigned status; lets leave > > that to the file > > > > bitcoin/txn > > > > - aka. wire-ready fully-signed transaction in binary > > > > bitcoin/uri > > > > - aka > > [BIP-21](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki) > > - could be just a bare bech32 or base58 payment address > > - but can also encode amount, comments in URL args > > - potentially interesting as a response to 402 - Payment required > > > > > > Other thoughts > > > > - some mime-types are proposed in BIP-71 but those are unrelated to above, > > and never > >seem to have been registered > > > > - for those who like to encode their binary as base64 or hex, that can be > > indicated > >as "encoding=hex" or "encoding=base64" in the optional parameters, just > > like > >"text/plain; encoding=utf-8" does. However, the default must be binary. > > > > - although the above are useful for web servers, they are also useful > > elsewhere and I > >intend to use them in NFC (NDEF records) where a shorter length is > > critical. > > > > - I have no idea how easily IANA will accept these proposals. > > > > - current approved mime types: > > https://www.iana.org/assignments/media-types/media-types.xhtml > > > > Thoughts? > > > > --- > > @DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10 > > > > ___ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal for a few IANA mime-types related to Bitcoin
On Tue, Aug 31, 2021 at 12:18 PM Peter D. Gray wrote: > QR Codes do not use IANA mime-types. > > If anyone wanted to use UR encoding for PSBT data in a web context (http), > NFC, or email, it would probably be best to discourage them. > > While I can understand the need for UR encoding in animated QR > codes, I don't think any other use-case could justify introducing > a new word list (ByteWords), a unique checksum algo (Xoshiro256), > fountain codes (Luby Transform) and CBOR... just to wrap a few k > of binary. > > I do love CBOR though. It's the best. UR is more than just a QR, it is URL conformant text that is optimized for compression in QRs. In particular, take a look at the explanation of the UR format at the 20m0s mark in this video: https://youtu.be/RYgOFSdUqWY The rest of the video explains why we made the choices we did. We wanted to leverage existing standards, but there were too many compromises expecially give QR requirements. See the section on “Why Another Standard” in our overview at https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/ur-1-overview.md#why-another-standard Note that the UR specification just is not just being adopted by wallet vendors, but also a number of online services / transaction coordinators that only have access watch-only keys. These services can then do a crypto-request for the airgapped wallet to sign the PSBT. — Christopher Allen > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal for a few IANA mime-types related to Bitcoin
QR Codes do not use IANA mime-types. If anyone wanted to use UR encoding for PSBT data in a web context (http), NFC, or email, it would probably be best to discourage them. While I can understand the need for UR encoding in animated QR codes, I don't think any other use-case could justify introducing a new word list (ByteWords), a unique checksum algo (Xoshiro256), fountain codes (Luby Transform) and CBOR... just to wrap a few k of binary. I do love CBOR though. It's the best. --- @DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10 On Tue, Aug 31, 2021 at 12:01:23PM -0700, Christopher Allen wrote: > Note that a number of wallet companies are now supporting the UR encoded > version of PSBTs, allowing for better QR & Airgap solutions, and also > leverage CBOR which is an IETF standard. > > We have a community of Airgap wallet developers at > https://github.com/BlockchainCommons/Airgapped-Wallet-Community > > …and libraries at > https://github.com/BlockchainCommons/crypto-commons#urs > > We’d love for you to register UR as well, maybe as bitcoin/psbt+ur > > Can you bring this up in our community for further discussion? > https://github.com/BlockchainCommons/Airgapped-Wallet-Community/discussions > > Thanks! > > — Christopher Allen [via iPhone] > > On Tue, Aug 31, 2021 at 11:41 AM Peter D. Gray via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > Hi list! > > > > I am proposing to register the following MIME (RFC 2046) media types with > > the IANA: > > > > > > bitcoin/psbt > > > > - aka. a BIP-174 file, in binary > > - does not make any claims about signed/unsigned status; lets leave > > that to the file > > > > bitcoin/txn > > > > - aka. wire-ready fully-signed transaction in binary > > > > bitcoin/uri > > > > - aka [BIP-21]( > > https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki) > > - could be just a bare bech32 or base58 payment address > > - but can also encode amount, comments in URL args > > - potentially interesting as a response to 402 - Payment required > > > > > > Other thoughts > > > > - some mime-types are proposed in BIP-71 but those are unrelated to above, > > and never > > seem to have been registered > > > > - for those who like to encode their binary as base64 or hex, that can be > > indicated > > as "encoding=hex" or "encoding=base64" in the optional parameters, just > > like > > "text/plain; encoding=utf-8" does. However, the default must be binary. > > > > - although the above are useful for web servers, they are also useful > > elsewhere and I > > intend to use them in NFC (NDEF records) where a shorter length is > > critical. > > > > - I have no idea how easily IANA will accept these proposals. > > > > - current approved mime types: > > https://www.iana.org/assignments/media-types/media-types.xhtml > > > > Thoughts? > > > > --- > > @DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10 > > > > ___ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal for a few IANA mime-types related to Bitcoin
Note that a number of wallet companies are now supporting the UR encoded version of PSBTs, allowing for better QR & Airgap solutions, and also leverage CBOR which is an IETF standard. We have a community of Airgap wallet developers at https://github.com/BlockchainCommons/Airgapped-Wallet-Community …and libraries at https://github.com/BlockchainCommons/crypto-commons#urs We’d love for you to register UR as well, maybe as bitcoin/psbt+ur Can you bring this up in our community for further discussion? https://github.com/BlockchainCommons/Airgapped-Wallet-Community/discussions Thanks! — Christopher Allen [via iPhone] On Tue, Aug 31, 2021 at 11:41 AM Peter D. Gray via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi list! > > I am proposing to register the following MIME (RFC 2046) media types with > the IANA: > > > bitcoin/psbt > > - aka. a BIP-174 file, in binary > - does not make any claims about signed/unsigned status; lets leave > that to the file > > bitcoin/txn > > - aka. wire-ready fully-signed transaction in binary > > bitcoin/uri > > - aka [BIP-21]( > https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki) > - could be just a bare bech32 or base58 payment address > - but can also encode amount, comments in URL args > - potentially interesting as a response to 402 - Payment required > > > Other thoughts > > - some mime-types are proposed in BIP-71 but those are unrelated to above, > and never > seem to have been registered > > - for those who like to encode their binary as base64 or hex, that can be > indicated > as "encoding=hex" or "encoding=base64" in the optional parameters, just > like > "text/plain; encoding=utf-8" does. However, the default must be binary. > > - although the above are useful for web servers, they are also useful > elsewhere and I > intend to use them in NFC (NDEF records) where a shorter length is > critical. > > - I have no idea how easily IANA will accept these proposals. > > - current approved mime types: > https://www.iana.org/assignments/media-types/media-types.xhtml > > Thoughts? > > --- > @DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10 > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal for a few IANA mime-types related to Bitcoin
Hi Peter, It would be nice to have mime types registered for Bitcoin things, but I'm not sure that it will be possible, at least not in the way that we would like. I tried doing this with "application/bitcoin-psbt" back in 2019 but it was not accepted. From that attempt, here is what I have learned: There are only a few accepted top level types, so we would not be able to use "bitcoin" as the top level (unless you want to submit an RFC to add a "bitcoin" top level). Of the available top level types, "application" is the most appropriate for Bitcoin. Next is the tree that the mime type should be in. The best would be the Standards tree, but it has some requirements that Bitcoin doesn't really meet. In order to be in the standards tree, the registration must be either associated with an IETF specification (so a RFC) or registered by a recognized standards related organization. Unfortunately the closest thing to a standards organization that Bitcoin has is the BIPs process, and that is not a really a standards organization nor is it recognized by IANA. So in order to register the mimetypes as Standards tree types, we would need to write an RFC, but this could be an independent submission (https://www.rfc-editor.org/about/independent/) rather than IETF-stream submission. I did not continue to pursue this because I didn't have the time. Another alternative would be to use the Vendor tree, but that would prefix the mimetype with "vnd." so it would end up being something like "application/vnd.bitcoin.psbt". I did not think this was an reasonable so I did not continue to pursue this avenue. Andrew Chow On 8/31/21 2:27 PM, Peter D. Gray via bitcoin-dev wrote: > Hi list! > > I am proposing to register the following MIME (RFC 2046) media types with the > IANA: > > > bitcoin/psbt > > - aka. a BIP-174 file, in binary > - does not make any claims about signed/unsigned status; lets leave that > to the file > > bitcoin/txn > > - aka. wire-ready fully-signed transaction in binary > > bitcoin/uri > > - aka > [BIP-21](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki) > - could be just a bare bech32 or base58 payment address > - but can also encode amount, comments in URL args > - potentially interesting as a response to 402 - Payment required > > > Other thoughts > > - some mime-types are proposed in BIP-71 but those are unrelated to above, > and never >seem to have been registered > > - for those who like to encode their binary as base64 or hex, that can be > indicated >as "encoding=hex" or "encoding=base64" in the optional parameters, just > like >"text/plain; encoding=utf-8" does. However, the default must be binary. > > - although the above are useful for web servers, they are also useful > elsewhere and I >intend to use them in NFC (NDEF records) where a shorter length is > critical. > > - I have no idea how easily IANA will accept these proposals. > > - current approved mime types: > https://www.iana.org/assignments/media-types/media-types.xhtml > > Thoughts? > > --- > @DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10 > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Proposal for a few IANA mime-types related to Bitcoin
Hi list! I am proposing to register the following MIME (RFC 2046) media types with the IANA: bitcoin/psbt - aka. a BIP-174 file, in binary - does not make any claims about signed/unsigned status; lets leave that to the file bitcoin/txn - aka. wire-ready fully-signed transaction in binary bitcoin/uri - aka [BIP-21](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki) - could be just a bare bech32 or base58 payment address - but can also encode amount, comments in URL args - potentially interesting as a response to 402 - Payment required Other thoughts - some mime-types are proposed in BIP-71 but those are unrelated to above, and never seem to have been registered - for those who like to encode their binary as base64 or hex, that can be indicated as "encoding=hex" or "encoding=base64" in the optional parameters, just like "text/plain; encoding=utf-8" does. However, the default must be binary. - although the above are useful for web servers, they are also useful elsewhere and I intend to use them in NFC (NDEF records) where a shorter length is critical. - I have no idea how easily IANA will accept these proposals. - current approved mime types: https://www.iana.org/assignments/media-types/media-types.xhtml Thoughts? --- @DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10 signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
