BIP0071 media type registration with IANA

BIP0071 media type registration with IANA
2014-04-26 20:17 ` Mike Hearn
  
From: Ross Nicoll @ 2014-04-26 20:15 UTC (permalink / raw)
  To: Bitcoin Dev

Dear all,

Still going through the payment protocol specifications... the MIME
types in BIP0071 aren't IANA registered, and honestly look unlikely to
be accepted if they were submitted as-is.

Latest RFC on media type registration is RFC 6838, which very strictly
restricts what can go in the default "application/" namespace.
Essentially they'd want it to be an ISO standard or similar. There are
vendor namespaces, which look much more feasible (this is how Powerpoint
2007 ended up as
"application/vnd.openxmlformats-officedocument.presentationml.presentation"),
but would be quite a dramatic change to BIP0071.

What's the general feeling on this? Personally I'm in favour of
following the registration process, so register a Bitcoin vendor
namespace with IANA, then allocate MIME types such as:

application/vnd.bitcoin.payment.request
application/vnd.bitcoin.payment.payment
application/vnd.bitcoin.payment.ack

Thoughts?

Ross



 permalink raw reply	[|nested]
2014-04-26 20:15 [Bitcoin-development] BIP0071 media type registration with IANA Ross Nicoll

  2014-04-26 21:16   ` Jannis Froese
  
From: Mike Hearn @ 2014-04-26 20:17 UTC (permalink / raw)
  To: Ross Nicoll;  Bitcoin Dev

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

Bitcoin is not a vendor, so I doubt that would work.

I doubt we should spend any time on this. The chance of a string collision
is extremely low. The current mime types are fine.


On Sat, Apr 26, 2014 at 10:15 PM, Ross Nicoll <jrn@jrn•me.uk> wrote:

> Dear all,
>
> Still going through the payment protocol specifications... the MIME
> types in BIP0071 aren't IANA registered, and honestly look unlikely to
> be accepted if they were submitted as-is.
>
> Latest RFC on media type registration is RFC 6838, which very strictly
> restricts what can go in the default "application/" namespace.
> Essentially they'd want it to be an ISO standard or similar. There are
> vendor namespaces, which look much more feasible (this is how Powerpoint
> 2007 ended up as
>
> "application/vnd.openxmlformats-officedocument.presentationml.presentation"),
> but would be quite a dramatic change to BIP0071.
>
> What's the general feeling on this? Personally I'm in favour of
> following the registration process, so register a Bitcoin vendor
> namespace with IANA, then allocate MIME types such as:
>
> application/vnd.bitcoin.payment.request
> application/vnd.bitcoin.payment.payment
> application/vnd.bitcoin.payment.ack
>
> Thoughts?
>
> Ross
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

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

 permalink raw reply	[|nested]
2014-04-26 20:17 ` Mike Hearn

  
From: Jannis Froese @ 2014-04-26 21:16 UTC (permalink / raw)
  To: bitcoin-development

Am 2014-04-26 22:17, schrieb Mike Hearn:
> Bitcoin is not a vendor, so I doubt that would work.
By my interpretation of RFC 6838, the Bitcoin Foundation or even Gavin 
himself could register a vendor tree for Bitcoin. In the case of the 
foundation registering, getting the subtree named vdn.bitcoin should be 
no problem.

> I doubt we should spend any time on this. The chance of a string 
> collision is extremely low. The current mime types are fine.
It's mostly about the good feeling of having followed the rules and 
proper procedures, I doubt that there is a difference in practice



 permalink raw reply	[|nested]