[bitcoin-dev] Proposal for a few IANA mime-types related to Bitcoin

[bitcoin-dev] Proposal for a few IANA mime-types related to Bitcoin

[Peter D. Gray]

[-- Attachment #1: Type: text/plain, Size: 1352 bytes --]

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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoin-dev] Proposal for a few IANA mime-types related to Bitcoin

[Christopher Allen]

[-- Attachment #1: Type: text/plain, Size: 2447 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 3869 bytes --]

Re: [bitcoin-dev] Proposal for a few IANA mime-types related to Bitcoin

[Peter D. Gray]

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
> >

Re: [bitcoin-dev] Proposal for a few IANA mime-types related to Bitcoin

[Andrew Chow]

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

Re: [bitcoin-dev] Proposal for a few IANA mime-types related to Bitcoin

[Christopher Allen]

[-- Attachment #1: Type: text/plain, Size: 1487 bytes --]

On Tue, Aug 31, 2021 at 12:18 PM Peter D. Gray <peter@coinkite.com> 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

>

[-- Attachment #2: Type: text/html, Size: 2754 bytes --]

Re: [bitcoin-dev] Proposal for a few IANA mime-types related to Bitcoin

[Peter D. Gray]

[-- Attachment #1: Type: text/plain, Size: 4126 bytes --]

> ... 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 +0000, 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
> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoin-dev] Proposal for a few IANA mime-types related to Bitcoin

[Dr Maxim Orlovsky]

[-- Attachment #1: Type: text/plain, Size: 4687 bytes --]

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 +0000, 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

[-- Attachment #2: Type: text/html, Size: 6068 bytes --]