Revisiting mime-types and file extensions

[Thomas Nichols]

Sam Angove wrote:

> On 6/15/07, Thomas Nichols <nichols7 at googlemail.com> wrote:

>> Using the "experimental" types indicated by 'x.' and 'x-' might also be

>> a possibility in the short term, but is not recommended; a properly

>> registered mime type in the main tree would provide a clear

>> standardisation. Is this important enough to anyone else to warrant an

>> attempt to register a name? Or should we just create a solution specific

>> to our own problem domain?

>

> I expect that submitting something acceptable to the IETF standards

> track would be rather a lot of work and probably fail. The lack of

> clear standardisation is an issue regardless, and would have to be

> resolved *before* submission.


Are you referring here to lack of _Markdown_ standardisation? Markdown
!= Markdown Extra != Maruku and so on? If so, I was thinking these might
become subtypes - .....markdown.basic, .....markdown.maruku etc. But if
a full EBNF grammar must be defined for each before standardisation can
begin then this is evidently a non-starter. My assumption was that, as
for (say) text/rtf, the mime type would identify a _family_ of
specifications, with internal version numbers to distinguish between them.

>

> For the vendor tree, the guidelines do qualify "well-known producer",

> "IANA-approved designation of the producer's name", etc. It's not

> clear that `vnd.markdown` is appropriate. Even if it is, what would it

> *mean*?


This bothered me too -- and 'vnd.gruber.*' might conflict with some
other 'gruber'. Perhaps 'vnd.daring-fireball.markdown' might work - but
I prefer your suggestion below.


>

> Right now we really have `text/prs.gruber.markdown`,

> `text/prs.fortin.php-markdown-extra` etc. etc. "Markdown"

> implementations generally implement something close to the former, but

> there are ambiguous edge-cases so who knows for sure? Proposals for a

> normative grammar went nowhere.


Ok -- well I am most certainly not about to open _that_ debate ;-)


>

> `text/x-markdown` seems a reasonable media-type to encompass the whole

> murky, underspecified lot of them. Specific extensions/implementations

> could be indicated with an optional parameter, like:

>

>    text/x-markdown;

> profile="http://www.michelf.com/projects/php-markdown/extra/"

>

> That seems better than requiring a separate media type for every

> extension. YMMV.


This looks a workable option for us (and is in fact what we were doing
last time we played with this). The 'profile' idea is also interesting
-- though for consistency with other mime-types would this be the
optimal syntax? With embedded space/newline and semi-colon? Looking at
the [Apache mime types][apache-mime-example], for example, they all seem
to be just alphanumerics, hyphens and slashes - or are you suggesting
this as an analogue of a Content-Type string, where I might have
CONTENT="text/html; charset=ISO-8859-1"
?
I'm not at all sure how we'd handle that, but it might make a
straightforward way to distinguish Maruku-flavoured-Markdown from, say,
BlueCloth-flavoured-Markdown. In which case...

What profile URIs would people suggest? How about:

  * http://daringfireball.net/projects/markdown/
  * http://maruku.rubyforge.org/
?

Or should those have major/minor version numbers appended:

  * http://daringfireball.net/projects/markdown/1.0
  * http://maruku.rubyforge.org/0.5
?
If the profile is not sufficient precisely to identify the supported
language syntax, I'm not sure it would have much practical value for us.
OTOH, if by looking at the profile string we could identify exactly
which processor was required then we can build a more flexible tool.



>

> As an aside, I think the reStructuredText case is one to avoid

> repeating: it has an IANA registration as `text/prs.fallenstein.rst`,

> but its highest-profile [user][1] prefers `text/x-rst`.

>

> [1]: http://www.python.org/dev/peps/pep-0012/


Very interesting, thank you. If text/x-markdown is an acceptable
compromise, we'll implement this.

Thanks also to all who suggested file extensions -- all but 'md' seem
unambiguous; it appears that 'md' has some [other
uses][md-associations], including one for Windows Media Player. If we
save a document to the filesystem we'll probably use ".markdown" as the
extension.

Thomas.

[apache-mime-example]:
http://unhinfo.unh.edu/NIS/Courses/Plug-ins/mime-types.html
[md-associations]: http://filext.com/file-extension/md