text/markdown effort in IETF (invite)

[Sean Leonard]

On 7/10/2014 8:49 AM, Waylan Limberg wrote:
> On Jul 09, 2014, at 11:49 AM, Sean Leonard <dev+ietf at seantek.com> wrote:
>
>> Hi markdown-discuss Folks:
>>
>> I am working on a Markdown effort in the Internet Engineering Task
>> Force, to standardize on "text/markdown" as the Internet media type for
>> all variations of Markdown content. You can read my draft here:
>> <http://tools.ietf.org/html/draft-seantek-text-markdown-media-type-00 
>>        >.
>
> My response below is lengthy but covers a number of different points 
> including some raised later in the discussion by others.
>
> Sean, have you reached out to Mr. Gruber specifically?

Yes, I e-mailed him...twice. We shall see if he responds.

> Why do we need a Mime Type?

In my own selfish use case, I want to identify Markdown files in my 
software projects as text/markdown (or *something*)...not just text/plain.

As I think I said before, Markdown is now being stored and exchanged 
"as-is". It is those "as-is" cases where we want to identify Markdown as 
it is, rather than its incorrect approximations (text/plain) or solely 
in its output formats (text/html, etc.).

> Encodings
> --------------
> [...]
>
> However, if the markdown text is included in a JSON file (see my 
> previous point above), then wouldn't the encoding be defined for the 
> JSON file, not the markdown text specifically. The JSON parsing 
> library would just spit out a Unicode string -- in which case, why do 
> we need this?

It's a general property of text streams (and in particular, a general 
property of Internet media types under the text/ main type) that the 
streams have a designated encoding. Frequently, this encoding is 
implicit, much like you can assume that Windows software uses 
little-endian byte ordering, or that line breaks on *nix-derived 
operating systems are <LF>, not <CRLF> or <CR>. The issue comes down to 
interchange. When a Windows machine exchanges text files or data with a 
Unix machine, how do you represent the concept of newlines in a common way?

To your specific point: if you encase Markdown content in JSON content 
as a JSON string, you can probably assume the Markdown content uses the 
Unicode character set. But you can have Markdown content as-is in its 
own file or other protocol element, where there are no such assumptions. 
For example, in your JSON example, the JSON content is likely in a file 
(or XMLHttpRequest) that needs to be explicitly or implicitly labeled 
with UTF-8 encoding.


> Flavors
> ---------
> [...]

Now that I know more, I am seriously rethinking that part of the 
proposal. Thanks for the info!

-Sean