What is the correct mime type for esoteric languages

Question

What is the correct mime-type type of esoteric languages?
I've googled everywhere, I even tried to ask Chuck Norris, but I didn't find the answer anywhere.

I have tried these for Brainfuck:

application/brainfuck
application/x-brainfuck
application/x+brainfuck
x-esoteric/x-brainfuck
chuck-norris-choice/brainfuck
x-you-lost-the-game/x-fuck-your-brain
42/++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.

But none of them seemed to work.

Answer 1

A far as I'm aware, there is no 'official' media type for brainfuck (Official types listed here). You are of course free to make up your own without officially registering the type, but you should take a few things into consideration before choosing what name to use. All the information you need is in RFC2046. I'll discuss the relevant parts below.

Top Level Media Type

As far as I can see, the two options you might choose from are text and application:

text

According to Section 3:

The subtype "plain" in particular indicates plain text containing no formatting commands or directives of any sort. Plain text is intended to be displayed "as-is". No special software is required to get the full meaning of the text, aside from support for the indicated character set.

If you intend for the data to be displayed rather than interpreted by an application, I would use this.

Section 4.1.4 mentions the following about unrecognised subtypes:

Unrecognized subtypes of "text" should be treated as subtype "plain" as long as the MIME implementation knows how to handle the charset.

Setting your top level media type to text will ensure that compliant applications that do not recognise the full type will still render the data as text.

application

If you intend your data to be interpreted or processed further, you should use the application top-level media type. As in the argument above, if you label your data as application, any programs that receive it are more likely to behave in a sensible fashion.

Section 4.5.3 deals with unrecognised application types:

It is expected that many other subtypes of "application" will be defined in the future. MIME implementations must at a minimum treat any unrecognized subtypes as being equivalent to "application/octet-stream".

Reading the appropriate section (Section 4.5.1) we find out how applications are supposed to handle octet streams:

The recommended action for an implementation that receives an "application/octet-stream" entity is to simply offer to put the data in a file, with any Content-Transfer-Encoding undone, or perhaps to use it as input to a user-specified process.

If this seems like the most logical way to handle your data when it is unrecognised, then application is for you.

Sub-type

Choosing the subtype is much easier. Section 6 covers experimental media types:

A media type value beginning with the characters "X-" is a private value, to be used by consenting systems by mutual agreement. Any format without a rigorous and public definition must be named with an "X-" prefix, and publicly specified values shall never begin with "X-".

So your subtype should be X-brainfuck.

Summary

You have two options:

1. text/X-brainfuck
2. application/X-brainfuck

If you intend for applications to treat the data as plain text and display it, choose 1. If you intend the data to be interpreted or executed, choose 2. If you're unsure what you want to happen, choose 2, because the default expectation is that an application will prompt the user for what to do if it does not recognise the type.

Answer 2

I have no clue why you think application/... is an appropriate mime type for a text file.

One generally accepted MIME type for .bf is text/x-brainfuck. This is a language, not an executable.