Hi, I'm in the process of adding support for Markdown to a minimal CMS in Rails, [Railfrog][railfrog], which uses mime types to select appropriate processing. I have had a look through the archives but have not been able to see that a consensus has emerged as to what such a mime type for Markdown should look like. My reading of the RFCs suggests that it should be within the "text/*" media type, and it looks as though we could with impunity use our own mime type of, say, text/vnd.railfrog.markdown but this does seem most inelegant. The [registration procedures][reg] do not seem unduly long-winded, and a mime-type of text/markdown seems entirely suitable, alongside text/rtf and text/html. This would, I believe, mean 'registration in the IETF tree' -- does that seem appropriate for Markdown? The ['text' media type][texttype] looks like the right place if I have understood correctly; however, if registration at the top level appears problematic then it should be entirely feasible to register in the 'vendor' tree: * text/vnd.markdown.basic * text/vnd.markdown.maruku * etc. If I read this correctly, no consultation process is then required. 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? In Railfrog we also allow content to be loaded from the file system, with the mime type being inferrred from the file extension. Having reviewed the archives, our current intent is to load as Markdown any files with the extensions * .markdown * .mdtext * .mdml (from [file-extensions], though not at http://www.filext.com) Any suggestions for others we should also be handling? Any comments/flames would be most welcome - and many thanks to everyone who has worked to keep Markdown so clear and simple! Thomas. [railfrog]: http://www.railfrog.com/ [reg]: http://www.mhonarc.org/~ehood/MIME/2048/rfc2048.html#2.1 [texttype]: http://www.mhonarc.org/~ehood/MIME/2046/rfc2046.html#4.1 [file-extensions]: http://www.file-extensions.org/mdml-file-extension
Thomas Nichols wrote:> * .markdown > * .mdtext > * .mdml (from [file-extensions], though not at http://www.filext.com)Ikiwiki uses .mdwn ciao Klaus
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. 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*? 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. `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. 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/
Le 2007-06-14 ? 22:45, Sam Angove a ?crit :> `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 complicated to me. Specifically, what happens if I change the page URL to PHP Markdown Extra some day? Why not one of these instead: text/x-markdown.extra text/x-markdown+extra ? Michel Fortin michel.fortin at michelf.com http://www.michelf.com/
* Michel Fortin <michel.fortin at michelf.com> [2007-06-16 01:30]:> Specifically, what happens if I change the page URL to PHP > Markdown Extra some day?Nothing. Just because people are accustomed to HTTP URIs being derenferencable to some actual page or other resource doesn?t mean they actually have to be. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
Le 2007-06-16 ? 2:57, A. Pagaltzis a ?crit :> * Michel Fortin <michel.fortin at michelf.com> [2007-06-16 01:30]: >> Specifically, what happens if I change the page URL to PHP >> Markdown Extra some day? > > Nothing. Just because people are accustomed to HTTP URIs being > derenferencable to some actual page or other resource doesn?t > mean they actually have to be.Yes, but there is no point in using a URI in this case. Michel Fortin michel.fortin at michelf.com http://www.michelf.com/
* Michel Fortin <michel.fortin at michelf.com> [2007-06-16 15:15]:> Le 2007-06-16 ? 2:57, A. Pagaltzis a ?crit : > >* Michel Fortin <michel.fortin at michelf.com> [2007-06-16 01:30]: > >>Specifically, what happens if I change the page URL to PHP > >>Markdown Extra some day? > > > >Nothing. Just because people are accustomed to HTTP URIs being > >derenferencable to some actual page or other resource doesn?t > >mean they actually have to be. > > Yes, but there is no point in using a URI in this case.It?s a globally unique identifier. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>