text/markdown effort in IETF (invite)
dev+ietf at seantek.com
Fri Jul 11 05:12:19 EDT 2014
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:
> 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.).
> 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.
Now that I know more, I am seriously rethinking that part of the
proposal. Thanks for the info!
More information about the Markdown-Discuss