Sean Leonard | 18 Oct 01:35 2014

New Version Notification for draft-ietf-appsawg-text-markdown-03.txt

And here is the other.


From: internet-drafts <at>
Subject: New Version Notification for draft-ietf-appsawg-text-markdown-03.txt
Date: October 17, 2014 at 4:33:52 PM PDT

A new version of I-D, draft-ietf-appsawg-text-markdown-03.txt
has been successfully submitted by Sean Leonard and posted to the
IETF repository.

Name:		draft-ietf-appsawg-text-markdown
Revision:	03
Title:		The text/markdown Media Type
Document date:	2014-10-17
Group:		appsawg
Pages:		22

  This document registers the text/markdown media type for use with
  Markdown, a family of plain text formatting syntaxes that optionally
  can be converted to formal markup languages such as HTML.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at
(Continue reading)

Sean Leonard | 18 Oct 01:33 2014

New Version Notification for draft-seantek-text-markdown-use-cases-00.txt

Here is one.

From: internet-drafts <at>
Subject: New Version Notification for draft-seantek-text-markdown-use-cases-00.txt
Date: October 17, 2014 at 4:21:21 PM PDT

A new version of I-D, draft-seantek-text-markdown-use-cases-00.txt
has been successfully submitted by Sean Leonard and posted to the
IETF repository.

Name:		draft-seantek-text-markdown-use-cases
Revision:	00
Title:		text/markdown Use Cases
Document date:	2014-10-17
Group:		Individual Submission
Pages:		20

 This document elaborates upon the text/markdown media type for use
 with Markdown, a family of plain text formatting syntaxes that
 optionally can be converted to formal markup languages such as HTML.
 Background information, local storage strategies, and additional
 syntax registrations are supplied.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at
(Continue reading)

Sean Leonard | 18 Oct 01:31 2014

text/markdown draft-03 guide (and use-cases-00 guide)

Hello Markdown World:

The following Internet-Drafts are about to be posted:


As discussed in apps-discuss <at> to make the drafts shorter yet more informative, I split them in
two. The secondary document has seven additional syntax registrations, background information, and
preservation strategies. The main registration document registers the media type. They are meant to be
read together; however, the secondary document makes no normative statements (no RFC 2119 key words).

  1. Introduction
  2. Markdown Media Type Registration Application
  3.  Optional Parameters
    3.1. syntax
    3.2. output-type
  4. Fragment Identifiers
  5.  Example

1. (Introduction)
    1.1. On Formats
    1.2. Markdown Design Philosophy
    1.3. Uses of Markdown
    1.4. Uses of Labeling Markdown Content as text/markdown
  2.  Strategies for Preserving Media Type and Parameters
  3.  Registration Templates for Common Markdown Syntaxes
    3.1. MultiMarkdown
(Continue reading)

Sean Leonard | 10 Oct 17:56 2014

(text/markdown) link label vs. link identifier and last-one-wins

In working on the text/markdown spec, I am making a reference to the syntax of links, specifically the things [1] and [Google] used in this construct:

Hello I am some [Markdown][1] and I use [Google][].

[Google]: "This is Google"

What is the common Markdown way of identifying this syntax element?

stmd (CommonMark) consistently calls it the "link label". (To be clear, it also calls [Markdown] a link label, even though that element does not have the same behavior as [1].)

However, [Markdown Syntax][MDSYNTAX] refers to it once as a "link identifier" in the bullet point: "Square brackets containing the link identifier (optionally indented from the left margin using up to three spaces)". Elsewhere it refers to it as a label. For example: "Reference-style links use a second set of square brackets, inside which you place a label of your choosing to identify the link" and "Then, anywhere in the document, you define your link label like this, on a line by itself".

I reviewed, which consistently uses the variable name $link_id (see also $g_urls, and comments such as # Link defs are in the form: ^[id]: url "optional title").

On this basis, I am going to call it "link identifier". Questions?

Also, seems to define last-wins behavior: the last link definition is indexed as the definition in $g_urls. (See _StripLinkDefinitions.) Older ones get overwritten by newer ones. Is this common or normative behavior? How do other implementations do it?

It's important that I keep the original reference list short; I would rather not refer normatively to documents other than Gruber's own Markdown rules.


Markdown-Discuss mailing list
Markdown-Discuss <at>

maybe we should discuss it

in terms of my last post here:


i was intrigued to see this today:


this mirrors earlier flipboard tech:


p.s.  by now, you might have figured out that
you can search twitter for "beyond markdown".
mofo syne | 4 Oct 05:34 2014

Sub reddit for general discussion on lightweight markup languages

If anybody is a reddit user, let me know, I might need a few moderators.

Might want to also update the sidebar with useful information.

let us not discuss that here

ubi said:
>   shouldn't this be moved to some other mailing list?

i sent only one notification, of the series, and
that was because i did not want to be seen as
"dissing markdown" without giving a fair notice.

and, for the record, i'm _not_ "dissing markdown".

i'm doing what john gruber has always suggested,
which is to make my own thing, with its own name.

and, just for the record once again, i didn't need his
instruction or permission to do that, because i was
working on z.m.l. for many years before markdown.

and i've continued to work on my system long after
he pushed markdown out of his nest to make it fly.


>   I guess Markdown purists (is there such a thing?)
>   may be annoyed.

if markdown purists want to be annoyed at something,
i'd suggest they read my medium article from last year:

>   markdown considered harmful
> <at> bbirdiman/markdown-considered-harmful-495ccfe24a52

that article is eminently fair, but the internet knows that
has never stopped some people from being "annoyed".


i don't want to discuss any of the specifics of my system
on this listserve, for various reasons, but i think i must
correct a few misimpressions from the feedback here.

>   I don't know how I feel
>   about having to add a ">"
>   (which by your convention is
>   a placeholder for [space]>[space])
>   for every line.

you don't have to put a " > " on every line;
putting it on the first line will be sufficient...
thanks for showing me i should've said that.

>   what if the block-quote text is not poetry?

z.m.l. offers two different block-quote tags:
one retains the linebreaks, the other doesn't.

even in the form where lines are rewrapped,
there is a way to specify a specific linebreak
should be retained. (it is the method that is
used across the whole of z.m.l., so i didn't
want to discuss it there in that one context;
i will discuss it as a general rule, later on.
but thanks for showing me it is confusing.)


mofo said:
>   I do wonder if people would be willing to
>   use the [space][tag][space] system though.
>   E.g. when typing '>', will I be willing to
>   tolerate having to add an extra space?
>   Will be interesting to see how tolerable it is.

um, ok.  if that is my biggest problem, i'll have
huge problems and no problems, simultaneously.

>   Also what is a chunk anyway?

>   beyond markdown -- part 2 -- z.m.l. is built to be easy to 
> <at> bbirdiman/beyond-markdown-part-2-b3527d2b9dcf

any set of non-blank lines bordered by blank lines
is a chunk. (though there will be a future wrinkle,
in that there'll be occurrence of "empty" chunks,
a result of splitting the file on double-linebreaks.)

>   Does that include header?

most definitely.

headers will be fully discussed in part 4 or part 5.

>   I might find having to do that space thing
>   to be annoying for headers

you always have the comfort of markdown as a fallback.


ok, now let us not discuss this any more here...


money for mou

interesting to see if there is any demand:



september is still the cruelest month

maybe perhaps it's time to go "beyond markdown".

i don't want to talk about you behind your back...

and do please let me know if i get anything wrong!

> <at> bbirdiman/beyond-markdown-part-1-2300665659f7

> <at> bbirdiman/beyond-markdown-part-2-b3527d2b9dcf

subsequent parts should come relatively quickly...

hey, the background graphic for "part 2" is a photo
i took last night out at chavez ravine, shortly after
kershaw tripled in a run to tie the game in the 5th;
clayton went on to get his 21st win of the season,
as the dodgers clinched the national league west.

in other news, the yankees were eliminated from
the playoffs.  nontheless, re2pect to the captain...


Request for input: text/markdown media type

[Sent by Sean Leonard]
From: IETF Applications Area Working Group (APPSAWG)

To: markdown-discuss <at> 
<mailto:markdown-discuss <at>>
jgm <at> <mailto:jgm <at>>
david <at> <mailto:david <at>>
vicent <at> <mailto:vicent <at>>
neil <at> <mailto:neil <at>>
ben <at> <mailto:ben <at>>
jatwood <at> <mailto:jatwood <at>>
comments <at> <mailto:comments <at>>

Cc: presnick <at> <mailto:presnick <at>>
barryleiba <at> <mailto:barryleiba <at>>

Response Contact: superuser <at> <mailto:superuser <at>>

Technical Contact: superuser <at> <mailto:superuser <at>>
dev+ietf <at> <mailto:dev%2Bietf <at>>

Purpose: Request for input

Attachments: (none)


The Applications Area Working Group (APPSAWG) of the Internet 
Engineering  Task Force (IETF) has taken up a proposed work item to 
register a new Media Type, "text/markdown", for the purposes of 
identifying content in the Markdown format.  The current version of the 
document can be viewed here:

We know Sean Leonard approached the Markdown community about starting 
this work previously (see and 
some of the questions that were discussed in that thread are also being 
asked in the working group.  In the interests of ensuring that any 
choices we make will not conflict with the positions and course of the 
Markdown community, APPSAWG would like to solicit feedback on a few 
important questions.

Part of the impetus here is that an unregistered and unspecified media 
type “text/x-markdown” appears to be in use.  This work seeks to 
formalize this use and register the name.

Our questions for the Markdown community:

(1) We understand there is not a standard Markdown format, but rather a 
number of variants based on one original proposal. This leads us to 
wonder how a consumer would be expected to interpret this media type 
once it is registered.  Typically, a media type registration includes a 
reference to a single, stable, definition document, but we are not aware 
of such a thing for Markdown.  Can or should this work proceed without one?

Note that the IETF has no intention to undertake the work of publishing 
an RFC that contains a Markdown syntax or otherwise blessing any 
particular Markdown variant, or calling one of them “standard".  Any 
Markdown definition document(s) would be referenced by this work and 
would be external to the IETF.

(2) One proposal to address this issue is to include a parameter that 
indicates which flavor of Markdown should be applied in order to 
translate the input when the media type is encountered.  For example:

Content-Type: text/markdown; flavor="foobar"

This would likely necessitate a registry of known variants and their 
respective defining documents so that a consumer has implementation 
guidance.  This puts some burden on the Markdown community to begin 
formally documenting and registering all of its variants that might use 
this media type.

(3) The solution in (2) above further raises the question of whether 
there should be a default variant (i.e., what to do if no “flavor” 
clause is present), and if so, which one should be the default.  If 
there is no default, then how should a consumer interpret the absence of 
the “flavor" tag?

(4) At the same time, it has been observed that regardless of which 
variant is in use as input, any Markdown processor will generally 
produce something useful as output.  Given this, is it necessary to know 
the “flavor” in use at all?  Put another way: Rather than being 
concerned with variants, should "text/markdown" merely be a hint to 
consumers that the content is in some Markdown variant, and beyond that, 
caveat implementer?

(5) Does the Markdown community have any alternative suggestions in 
response to any of these questions?

We look forward to your replies, hopefully within the next several 
weeks, which can be sent to the response and technical contacts listed 
in the header of this liaison.  Markdown community participants are also 
invited to subscribe and reply to apps-discuss <at> 
<mailto:apps-discuss <at>> in order to address the entire working 
group directly.

M. Kucherawy
for the Applications Area Working Group, IETF
Markdown-Discuss mailing list
Markdown-Discuss <at>

clarification of terms would be a good thing

fletcher said:
>   this is NOT Markdown when you do this.

thanks for your guidance on this, fletcher.

today's world seems to be confused about
what markdown _is_ and what it is _not._

perhaps a good explanation would be useful?
you know, one that defined markdown explicitly,
so we knew what it _is_ and what it is _not_...

lacking that, perhaps some good examples
might help.  for instance, _this_ is markdown,
but _that_ is not, nor are _those_other_things_.

maybe draw a line down the middle of a sheet
of paper, and on one side write the things that
_are_ markdown, and the other side _are_not_.

start with commonmark.  markdown?  or not?