text/markdown effort in IETF (invite)

[Carl Jacobsen]

> On Jul 9, 2014, at 3:07 PM, Michel Fortin <michel.fortin at michelf.ca> wrote:
> 
> I sure wish things would be simpler. But as things are now, I have a hard time identifying what "flavor" could mean. Should "Markdown.pl-1.0.1" be a flavor on its own?

Perhaps it would be better to have *two* optional fields:

- A "processor" field, as in `processor="Markdown.pl-1.0.1"` or  `processor="Pandoc-1.12.4.2-nostrict", which indicates that the sender was using (that program) to view the output and was satisfied with it. This could be included whenever known, and hopefully *not* relied upon by the recipient, but could provide useful clues in some cases where the recipient *has* to decide how to interpret something.

- A "flavor" field consisting of zero or more alphanumeric tokens, separated by "+" or "," or some such, declaring well-understood deviations from, or extensions to, the original standard. Not as a completely exhaustive list (you don't have to be able to indicate that your processor has, say, special syntax for animated gif backgrounds if no one else can use that anyway), but simply to promote better interoperability, to be interpreted as "the text contained herein supports basic markdown, plus *at least* X and Y and Z capabilities". Include some useful things like:

    - "nofill" (hard returns should be obeyed rather than joining lines - this would clarify that "two github flavors" situation),
    - "tables" (supports some agreed-upon "least common denominator" table syntax),
    - "footnotes" (similar but for footnotes),
    - "fencedcodeblocks" (you get the idea),
    - "titleblock" (text lines before first blank line are some sort of metadata and shouldn't be displayed to casual viewers),
    - "restrictunderscores" (mid-word underscores are not to be interpreted as starting/ending emphasized or strong text)

The idea being, merely having the "text/markdown" content type would not guarantee anything beyond "well, it's *some* sort of markdown flavored text", while specifying one or more of the attributes in the "flavor" field would indicate "yes, you can assume that if something looks like an X, it *is* an X" (where X is something from the list above). It doesn't necessarily mean you *will* find, say, a table, in the text, merely that if you see something that looks like a table, it likely is.

This way, senders can give a series of hints to make their text more clear to parse, using the "flavor" attribute, and can also declare what processor they were using to view/validate things on their end, in case the recipient feels they simply must know precisely how to interpret the text (at which point it's up to them to decide what, if any, conversion or special handling is necessary). And a recipient wouldn't need to consult an exhaustive list of processors, but simply look at the flavors attribute to see if it recognizes anything there as a useful hint (and render everything else naively).

So, you might have:  content-type="text/markdown" flavor="tables+titleblock" processor="floobity-1.2.3"

We'd need an agreed-upon list of, "ingredients", to put in the "flavors" field, but, again, you wouldn't want to exhaustively list every variant of every extension that any markdown-ish processor has ever come up with, only perhaps a dozen cases to cover the most common extensions (if you need to be more exacting, go consult the processor field and take matters into your own hands).

Does this make sense to anyone else? (I probably should have gone to sleep a long time ago.)

Cheers,
Carl Jacobsen