draft-ietf-appsawg-text-markdown-02.txt   draft-ietf-appsawg-text-markdown-03.txt 
Applications Area Working Group S. Leonard Applications Area Working Group S. Leonard
Internet-Draft Penango, Inc. Internet-Draft Penango, Inc.
Intended Status: Informational September 22, 2014 Intended Status: Informational October 17, 2014
Expires: March 26, 2015 Expires: April 20, 2015
The text/markdown Media Type The text/markdown Media Type
draft-ietf-appsawg-text-markdown-02.txt draft-ietf-appsawg-text-markdown-03
Abstract Abstract
This document registers the text/markdown media type for use with This document registers the text/markdown media type for use with
Markdown, a family of plain text formatting syntaxes that optionally Markdown, a family of plain text formatting syntaxes that optionally
can be converted to formal markup languages such as HTML. can be converted to formal markup languages such as HTML.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 47 skipping to change at page 2, line 5
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
[[TODO: add table of contents.]] Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. This Is Markdown! Or: Markup and Its Discontents . . . . . 2
1.2. Markdown Is About Writing and Editing . . . . . . . . . . . 3
1.3. RFC 2119 . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Markdown Media Type Registration Application . . . . . . . . . 5
3. Optional Parameters . . . . . . . . . . . . . . . . . . . . . 7
3.1. syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. output-type . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Fragment Identifiers . . . . . . . . . . . . . . . . . . . . . 13
4.1. #t . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. #o . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3. #l and #ldef . . . . . . . . . . . . . . . . . . . . . . . 13
4.4. Other Fragment Identifiers . . . . . . . . . . . . . . . . 14
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.1. Syntax Template . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Initial Registration . . . . . . . . . . . . . . . . . . . 17
6.3. Reserved Identifiers . . . . . . . . . . . . . . . . . . . 18
6.4. Standard of Review . . . . . . . . . . . . . . . . . . . . 18
6.5. Provisional Registration . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
1.1. On Formats 1.1. This Is Markdown! Or: Markup and Its Discontents
In computer systems, textual data is stored and processed using a In computer systems, textual data is stored and processed using a
continuum of techniques. On the one end is plain text: a linear continuum of techniques. On the one end is plain text: a linear
sequence of characters in some character set (code), possibly sequence of characters in some character set (code), possibly
interrupted by line breaks, page breaks, or other control characters. interrupted by line breaks, page breaks, or other control characters.
Plain text provides /some/ fixed facilities for formatting The repertoire of these control characters (a form of in-band
instructions, namely codes in the character set that have meanings signaling) is necessarily limited, and not particularly extensible.
other than "represent this character on the output medium"; however, Because they are non-printing, these characters are also hard to
these facilities are not particularly extensible. Compare with enter with standard keyboards.
[RFC6838] Section 4.2.1. Applications may neuter the effects of these
special characters by prohibiting them or by ignoring their dictated
meanings, as is the case with how modern applications treat most
control characters in US-ASCII. On this end, any text reader or
editor that interprets the character set can be used to see or
manipulate the text. If some characters are corrupted, the corruption
is unlikely to affect the ability of a computer system to process the
text (even if the human meaning is changed).
On the other end is binary format: a sequence of instructions
intended for some computer application to interpret and act upon.
Binary formats are flexible in that they can store non-textual data
efficiently (perhaps storing no text at all, or only storing certain
kinds of text for very specialized purposes). Binary formats require
an application to be coded specifically to handle the format; no
partial interoperability is possible. Furthermore, if even one byte
or bit are corrupted in a binary format, it may prevent an
application from processing any of the data correctly.
Between these two extremes lies formatted text, i.e., text that
includes non-textual information coded in a particular way, that
affects the interpretation of the text by computer programs.
Formatted text is distinct from plain text and binary format in that
the non-textual information is encoded into textual characters, which
are assigned specialized meanings /not/ defined by the character set.
With a regular text editor and a standard keyboard (or other standard
input mechanism), a user can enter these textual characters to
express the non-textual meanings. For example, a character like "<"
no longer means "LESS-THAN SIGN"; it means the start of a tag or
element that affects the document in some way.
On the formal end of the spectrum is markup, a family of languages
for annotating a document in such a way that the annotations are
syntactically distinguishable from the text. Markup languages are
(reasonably) well-specified and tend to follow (mostly) standardized
syntax rules. Examples of markup languages include SGML, HTML, XML,
and LaTeX. [[TODO: CITE.]] Standardized rules lead to
interoperability between markup processors, but a skill requirement
for new (human) users of the language that they learn these rules in
order to do useful work. This imposition makes markup less accessible
for non-technical users (i.e., users who are unwilling or unable to
invest in the requisite skill development).
informal /---------formatted text----------\ formal
<------v-------------v-------------v-----------------------v---->
plain text informal markup formal markup binary format
(Markdown) (HTML, XML, etc.)
Figure 1: Degrees of Formality in Data Storage Formats for Text
On the informal end of the spectrum are lightweight markup languages. Markup offers an alternative means to encode this signaling
In comparison with formal markup like XML, lightweight markup uses information by overloading certain characters with additional
simple syntax, and is designed to be easy for humans to enter with meanings. Therefore, markup languages allow for annotating a document
basic text editors. Markdown, the subject of this document, is an in such a way that annotations are syntactically distinguishable from
/informal/ plain text formatting syntax that is intentionally the printing information. Markup languages are (reasonably) well-
targeted at non-technical users (i.e., users upon whom little to no specified and tend to follow (mostly) standardized syntax rules.
skill development is imposed) using unspecialized tools (i.e., text Examples of formal markup languages include SGML, HTML, XML, and
boxes). Jeff Atwood once described these informal markup languages as LaTeX. Standardized rules lead to interoperability between markup
"humane" [HUMANE]. processors, but impose skill requirements on new users that lead to
markup languages becoming less accessible to beginners. These rules
also reify "validity": content that does not conform to the rules is
treated differently (i.e., is rejected) than content that conforms.
1.2. Markdown Design Philosophy In contrast to formal markup languages, lightweight markup languages
use simple syntaxes; they are designed to be easy for humans to enter
and understand with basic text editors. Markdown, the subject of this
document, began as an /informal/ plain text formatting syntax
[MDSYNTAX] and Perl script HTML/XHTML processor [MARKDOWN] targeted
at non-technical users using unspecialized tools, such as plain text
e-mail clients. [MDSYNTAX] explicitly rejects the notion of validity:
there is no such thing as "invalid" Markdown. If the Markdown content
does not result in the "right" output (defined as output that the
author wants, not output that adheres to some dictated system of
rules), the expectation is that the author should continue
experimenting by changing the content or the processor to achieve the
desired output.
Markdown specifically is a family of syntaxes that are based on the Since its development in 2004 [MARKDOWN], a number of web- and
original work of John Gruber with substantial contributions from Internet-facing applications have incorporated Markdown into their
Aaron Swartz, released in 2004 [MARKDOWN]. Since its release a number text entry systems, frequently with custom extensions. Markdown has
of web or web-facing applications have incorporated Markdown into thus evolved into a kind of Internet meme [INETMEME] as different
their text entry systems, frequently with custom extensions. Fed up communities encounter it and adapt the syntax for their specific use
with the complexity and security pitfalls of formal markup languages cases. Markdown now represents a family of related plain text
(e.g., HTML5) and proprietary binary formats (e.g., commercial word formatting syntaxes that, while broadly compatible with humans
processing software), yet unwilling to be confined to the [HUMANE], are intended to produce different kinds of outputs that
restrictions of plain text, many users have turned to Markdown for push the boundaries of mutual intelligibility between software
document processing. Whole toolchains now exist to support Markdown systems.
for online and offline projects.
Informality is a bedrock premise of Gruber's design. Gruber created To support identifying and conveying Markdown, this document defines
Markdown after disastrous experiences with strict XML and XHTML a media type and parameters that indicate the author's intent on how
processing of syndicated feeds. In Mark Pilgrim's "thought to interpret the Markdown. This registration draws particular
experiment", several websites went down because one site included inspiration from text/troff [RFC4263], which is a plain text
invalid XHTML in a blog post, which was automatically copied via formatting syntax for typesetting based on tools from the 1960s
trackbacks across other sites [DIN2MD]. These scenarios led Gruber to ("RUNOFF") and 1970s ("nroff", et. al.). In that sense, Markdown is a
believe that clients (e.g., web browsers) SHOULD try to make sense of kind of troff for modern computing. A companion document [MDMTUSES]
data that they receive, rather than rejecting data simply because it provides additional Markdown background and philosophy.
fails to adhere to strict, unforgiving standards. (In [DIN2MD],
Gruber compared Postel's Law [RFC0793] with the XML standard, which
says: "Once a fatal error is detected [...] the processor MUST NOT
continue normal processing" [XML1.0-3].) As a result, there is no
such thing as "invalid" Markdown; there is no standard demanding
adherence to the Markdown syntax; there is no governing body that
guides or impedes its development. If the Markdown syntax does not
result in the "right" output (defined as output that the author
wants, not output that adheres to some dictated system of rules),
Gruber's view is that the author either should keep on experimenting,
or should change the processor to address the author's particular
needs (see [MARKDOWN] Readme and [MD102b8] perldoc; see also
[CATPICS]).
1.3. Uses of Markdown 1.2. Markdown Is About Writing and Editing
Since its introduction in 2004, Markdown has enjoyed remarkable "HTML is a *publishing* format; Markdown is a *writing* format.
success. Markdown works for users for three key reasons. First, the Thus, Markdown's formatting syntax only addresses issues
markup instructions (in text) look similar to the markup that they that can be conveyed in plain text." [MDSYNTAX]
represent; therefore the cognitive burden to learn the syntax is low.
Second, the primary arbiter of the syntax's success is *running
code*. The tool that converts the Markdown to a presentable format,
and not a series of formal pronouncements by a standards body, is the
basis for whether syntactic elements matter. Third, Markdown has
become something of an Internet meme [INETMEME], in that Markdown
gets received, reinterpreted, and reworked as additional communities
encounter it. There are communities that are using Markdown for
scholarly writing [CITE], for screenplays [CITE], for mathematical
formulae [CITE], and even for music annotation [CITE]. Clearly, a
screenwriter has no use for specialized Markdown syntax for
mathematicians; likewise, mathematicians do not need to identify
characters or props in common ways. The overall gist is that all of
these communities can take the common elements of Markdown (which are
rooted in the common elements of HTML circa 2004) and build on them
in ways that best fit their needs.
1.4. Uses of Labeling Markdown Content as text/markdown The paradigmatic use case for text/markdown is the Markdown editor:
an application that presents Markdown content (which looks like an e-
mail or other piece of plain text writing) alongside a published
format, so that an author can see results instantaneously and can
tweak his or her input in real-time. A significant number of Markdown
editors have adopted "split-screen view" (or "live preview")
technology that looks like Figure 1:
To support identifying and conveying Markdown (as distinguished from +----------------------------------------------------------------------+
plain text), this document defines a media type and parameters that | File Edit (Cloud Stuff) (Fork Me on GitHub) Help |
indicate, in broad strokes, the author's intent on how to interpret +----------------------------------------------------------------------+
the Markdown. This registration draws particular inspiration from the | [ such-and-such identifier ] [ useful statistics] |
text/troff registration [RFC4263]; troff is an informal plain text +----------------------------------++----------------------------------+
formatting syntax primarily intended for output to monospace line- | (plain text, with || (text/html, likely |
oriented printers and screen devices. In that sense, Markdown is a | syntax highlighting) || rendered to screen) |
kind of troff for modern computing. | || |
|# Introduction ||<h1>Introduction</h1> |
| || |
|## Markdown Is About Writing and /|<h2>Markdown Is About Writing and |
/ Editing ||Editing</h2> |
| || |
|> HTML is a *publishing* format; ||<blockquote><p>HTML is a |
|> Markdown is a *writing* format. || <em>publishing</em> format; |
|> Thus, Markdown's formatting || Markdown is a <em>writing</em> |
|> syntax only addresses issues || format. Thus, Markdown's |
|> that can be conveyed in plain <> formatting syntax only addresses |
|> text. [MDSYNTAX][] || issues that can be conveyed in |
| || plain text. <a href="http://darin/
|The paradigmatic use case for |/gfireball.net/projects/markdown/sy/
|`text/markdown` is the Markdown |/ntax#html" title="Markdown: Syntax/
|editor: an application that |/: HTML">MDSYNTAX</a> |
|presents Markdown content ||</p></blockquote> |
|... || |
| ||<p>The paradigmatic use case for |
|[MDSYNTAX]: http://daringfireball./| <code>text/markdown</code> is the|
/net/projects/markdown/syntax#html || Markdown editor: an application |
|"Markdown: Syntax: HTML" || that presents Markdown content |
| || ...</p> |
+----------------------------------++----------------------------------+
The primary purpose of an Internet media type is to label "content" LEGEND: "/" embedded in a vertical line represents a line-continuation
on the Internet, as distinct from "files". Content is any computer- marker, since a line break is not supposed to occur in that content.
readable format that can be represented as a primary sequence of
octets, along with type-specific metadata (parameters) and type-
agnostic metadata (protocol dependent). From this description, it is
apparent that appending ".markdown" to the end of a filename is not a
sufficient means to identify Markdown. Filenames are properties of
files in file systems, but Markdown frequently exists in databases or
content management systems (CMSes) where the file metaphor does not
apply. One CMS [RAILFROG] uses media types to select appropriate
processing, so a media type is necessary for the safe and
interoperable use of Markdown.
Unlike complete HTML documents, [MDSYNTAX] provides no means to Figure 1: Markdown Split-Screen/Live Preview Editor
include metadata into the content stream. Several derivative flavors
have invented metadata incorporation schemes (e.g., [MULTIMD]), but
these schemes only address specific use cases. In general, the
metadata must be supplied via supplementary means in an encapsulating
protocol, format, or convention. The relationship between the content
and the metadata is not directly addressed by this specification;
however, by identifying Markdown with a media type, Markdown content
can participate as a first-class citizen with a wide spectrum of
metadata schemes.
Finally, registering a media type through the IETF process is not Users on diverse platforms SHOULD be able to collaborate with their
trivial. Markdown can no longer be considered a "vendor"-specific tools of choice, whether those tools are desktop-based (MarkdownPad,
innovation, but the registration requirements even in the vendor tree MultiMarkdown Composer), browser-based (Dillinger, Markable), integrated
have proven to be overly burdensome for most Markdown implementers. widgets (Discourse, GitHub), general-purpose editors (emacs, vi), or
Moreover, registering hundreds of Markdown variants with distinct plain old "Notepad". Additionally, users SHOULD be able to identify
media types would impede interoperability: virtually all Markdown particular areas of Markdown content when the Markdown becomes
content can be processed by virtually any Markdown processor, with appreciably large (e.g., book chapters and Internet-Drafts--not just
varying degrees of success. The goal of this specification is to blog posts). Users SHOULD be able to use text/markdown to convey their
reduce all of these burdens by having one media type that works in progress, not just their finished products (for which full-
accommodates diversity and eases registration. blown markups ranging from text/html to application/pdf are
appropriate). This registration facilitates interoperability between
these Markdown editors by conveying the syntax of the particular
Markdown variant and the desired output format.
1.3. Requirements Terminology 1.3. RFC 2119
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Example 2. Markdown Media Type Registration Application
The following is an example of Markdown as an e-mail attachment:
MIME-Version: 1.0
Content-Type: text/markdown; charset=UTF-8; flavor=Original;
processor="Markdown.pl-1.0.2b8 --html4tags"
Content-Disposition: attachment; filename=readme.md
Sample HTML 4 Markdown
=============
This is some sample Markdown. [Hooray!][foo]
(Remember that link names are not case-sensitive.)
Bulleted Lists
-------
Here are some bulleted lists...
* One Potato
* Two Potato
* Three Potato
- One Tomato
- Two Tomato
- Three Tomato
More Information
-----------
[.markdown, .md](http://daringfireball.net/projects/markdown/)
has more information.
[fOo]: http://example.com/some/foo/location
'This Title Will Not Work with Markdown.pl-1.0.1'
3. Markdown Media Type Registration Application
This section provides the media type registration application for the This section provides the media type registration application for the
text/markdown media type (see [RFC6838], Section 5.6). text/markdown media type (see [RFC6838], Section 5.6).
Type name: text Type name: text
Subtype name: markdown Subtype name: markdown
Required parameters: charset. Per Section 4.2.1 of [RFC6838], Required parameters:
charset is REQUIRED. There is no default value. UTF-8 is
RECOMMENDED; however, neither [MDSYNTAX] nor popular charset: Per Section 4.2.1 of [RFC6838], charset is REQUIRED. There
implementations at the time of this registration actually require is no default value. [MDSYNTAX] clearly describes Markdown as a
or assume any particular encoding. In fact, many Markdown writing format; its syntax rules operate on characters
processors can get along just fine by operating on character codes (specifically, on punctuation) rather than code points. Neither
that lie in the Portable Character Set (i.e., printable US-ASCII), [MDSYNTAX] nor many popular implementations at the time of this
blissfully oblivious to coded values outside of that range. registration actually require or assume any particular encoding.
Many Markdown processors will get along just fine by operating on
character codes that lie in printable US-ASCII, blissfully
oblivious to coded values outside of that range.
Optional parameters: Optional parameters:
The following parameters reflect the author's intent regarding the The following parameters reflect the author's intent regarding the
content. A detailed specification can be found in Section 4. content. A detailed specification can be found in Section 3.
flavor: The variant, or "flavor" of the Markdown content, with
optional rules (qualifiers). Default value: "Original".
processor: A specific Markdown implementation, with optional syntax: The Markdown-derivative syntax of the content, with
arguments. Default value: none (receiver's choice). optional version and named extensions. Default value: none
(receiver's choice).
output-type: The Content-Type (Internet media type) of the output, output-type: The Content-Type (Internet media type) of the output,
with optional parameters. Default value: "text/html". with optional parameters. Default value: "text/html".
Encoding considerations: Text. Encoding considerations: Text.
Security considerations: Security considerations:
Markdown interpreted as plain text is relatively harmless. A text Markdown interpreted as plain text is relatively harmless. A text
editor need only display the text. The editor SHOULD take care to editor need only display the text. The editor SHOULD take care to
handle control characters appropriately, and to limit the effect of handle control characters appropriately, and to limit the effect of
the Markdown to the text editing area itself; malicious Unicode- the Markdown to the text editing area itself; malicious Unicode-
based Markdown could, for example, surreptitiously change the based Markdown could, for example, surreptitiously change the
directionality of the text. An editor for normal text would already directionality of the text. An editor for normal text would already
take these control characters into consideration, however. take these control characters into consideration, however.
Markdown interpreted as a precursor to other formats, such as HTML, Markdown interpreted as a precursor to other formats, such as HTML,
carry all of the security considerations as the target formats. For carries all of the security considerations as the target formats.
example, HTML can contain instructions to execute scripts, redirect For example, HTML can contain instructions to execute scripts,
the user to other webpages, download remote content, and upload redirect the user to other webpages, download remote content, and
personally identifiable information. Markdown also can contain upload personally identifiable information. Markdown also can
islands of formal markup, such as HTML. These islands of formal contain islands of formal markup, such as HTML. These islands of
markup may be passed as-is, transformed, or ignored (perhaps formal markup may be passed as-is, transformed, or ignored (perhaps
because the islands are conditional or incompatible) when the because the islands are conditional or incompatible) when the
Markdown is interpreted into the target format. Since Markdown may Markdown is processed. Since Markdown may have different
have different interpretations depending on the tool and the interpretations depending on the tool and the environment, a better
environment, a better approach is to analyze (and sanitize or approach is to analyze (and sanitize or block) the output markup,
block) the output markup, rather than attempting to analyze the rather than attempting to analyze the Markdown.
Markdown.
Specific security considerations apply to the optional parameters; Security provides a significant motivator for the output-type
for details, consult Section 4. parameter. Most Markdown processors emit byte (octet) streams.
Without a well-defined means for a Markdown processor to pass
metadata onwards, it is perilous for post-processing to assume that
the content is always HTML or XHTML. A processor might emit
PostScript (application/postscript) content, for example, in which
case an HTML sanitizer would fail to excise dangerous instructions.
Interoperability considerations: Interoperability considerations:
Markdown flavors are designed to be broadly compatible with humans Markdown syntaxes are designed to be broadly compatible with humans
("humane"), but not necessarily with each other. Therefore, syntax ("humane"), but not necessarily with each other. Therefore, syntax
in one Markdown flavor may be ignored or treated differently in in one Markdown derivative may be ignored or treated differently in
another flavor. The overall effect is a general degradation of the another derivative. The overall effect is a general degradation of
output, proportional to the quantity of flavor-specific Markdown the output, proportional to the quantity of syntax-specific
used in the text. When it is desirable to reflect the author's Markdown used in the text. When it is desirable to reflect the
intent in the output, stick with the flavor identified in the author's intent in the output, stick with the syntax identified in
flavor parameter. the syntax parameter.
Published specification: This specification. Published specification: This specification; [MDSYNTAX].
Applications that use this media type: Applications that use this media type:
Markdown conversion tools, Markdown WYSIWYG editors, and plain text Markdown conversion tools, Markdown WYSIWYG editors, and plain text
editors and viewers; target markup processors indirectly use editors and viewers; markup processor targets indirectly use
Markdown (e.g., web browsers for Markdown converted to HTML). Markdown (e.g., web browsers for Markdown converted to HTML).
Fragment identifier considerations:
Markdown content acts as a "bridge" between plain text and formal
markup, so this specification permits fragment identifiers [[NB:
used to be #i]] #t for the [[NB: used to be input]] source text and
#o for the output content. The #l and #ldef fragment identifiers
identify link references. A detailed specification can be found in
Section 4.
Additional information: Additional information:
Magic number(s): None Magic number(s): None
File extension(s): .md, .markdown File extension(s): .md, .markdown
Macintosh file type code(s): TEXT Macintosh file type code(s):
TEXT. A uniform type identifier (UTI) of
"net.daringfireball.markdown", which conforms to "public.plain-
text", is RECOMMENDED [MDUTI]. Additionally, implementations
SHOULD record syntax and output-type parameters along with the
Markdown, such as in extended attributes; however, the exact
manner of storage is a local matter.
Person & email address to contact for further information: Person & email address to contact for further information:
Sean Leonard <dev+ietf@seantek.com> Sean Leonard <dev+ietf@seantek.com>
Restrictions on usage: None. Restrictions on usage: None.
Author/Change controller: Sean Leonard <dev+ietf@seantek.com> Author/Change controller: Sean Leonard <dev+ietf@seantek.com>
Intended usage: COMMON Intended usage: COMMON
Provisional registration? Yes Provisional registration? No
4. Optional Parameters 3. Optional Parameters
The following optional parameters can be used by an author to The optional parameters "syntax" and "output-type" can be used by an
indicate the author's intent regarding how the Markdown ought to be author to indicate the author's intent regarding how the Markdown
processed. For security and accuracy, IANA registries will be ought to be processed.
created. However, authors who wish to use custom values by private
agreement may do so via an extension mechanism; all unregistered
identifiers MUST start with an exclamation mark "!".
All identifiers are case-sensitive; receivers MUST compare for exact All identifiers are case-sensitive; receivers MUST compare for exact
equality. Identifiers MUST NOT be registered if another registration equality. At the same time, identifiers MUST NOT be registered in the
differs only in the casing, as these registrations may cause IANA registry (see Section 6) if another registration differs only in
confusion. the casing, as these registrations may cause confusion.
The following ABNF definitions are used in this section: The following ABNF definitions are used in this section:
EXTCHAR = <any character outside the US-ASCII range, EXTCHAR = <any character outside the printable US-ASCII
essentially amounting to any Unicode range, essentially amounting to Unicode code
code point beyond U+007F without requiring points less than U+0020 or greater than U+007E
Unicode or any particular encoding> without requiring Unicode or any particular
encoding>
REXTCHAR = <EXTCHAR without spaces (Zs category) or REXTCHAR = <EXTCHAR without separators (Z category) or
control characters> control characters (C category)>
Figure X: ABNF Used in This Section Figure X: ABNF Used in This Section
The discussion in this section presumes that the parameter values are The discussion in this section presumes that the parameter values are
discrete strings. When encoded in protocols such as MIME [RFC2045], discrete strings. When encoded in protocols such as MIME [RFC2045],
however, the value strings MUST be escaped properly. however, the value strings MUST be escaped properly. [MDMTUSES]
provides some strategies to preserve this information when it leaves
4.1. flavor the domain of IETF protocols.
The flavor parameter indicates the Markdown variant in which the
author composed the content. The overall intent of this parameter is
to provide a facility for Markdown tools, such as graphical editors,
to be able to broadly categorize the content and perform useful
services such as syntax highlighting without resorting to executing
the Markdown processor. Of course, actual recipients may use this
information for any useful purpose, including picking and configuring
an appropriate Markdown processor. The entire parameter is case-
sensitive.
An IANA registry of flavors will be created as discussed in Section
5. A flavor identifier is composed of two or more Unicode characters
excluding spaces (Zs category), control characters, the hyphen-minus
"-", quotation marks """, and the plus sign "+"; however, ASCII
characters alone SHOULD be used. Additionally, registered flavor
identifiers MUST NOT begin with "!", the exclamation mark. By
convention, flavor identifiers start with a capital letter (when
using Roman characters), but this is not a requirement. Unregistered
flavor identifiers MUST begin with "!" (plus two additional
characters).
When omitted, the default value is "Original". Its meaning is covered
in Section 5. Generators MUST NOT emit empty flavor parameters, but
parsers MUST treat empty flavor parameters the same as if omitted.
The full ABNF of the flavor parameter is:
flavor-param = flavor *( *WSP rule ) *WSP
flavor = registered-fid / unregistered-fid
registered-fid = fid-char 1*("!" / fid-char)
unregistered-fid = "!" 2*fid-char
fid-char = %d35-%d42 / %d44 / %d46-%d126 / REXTCHAR
rule = "+" (should-rule / any-rule)
should-rule = should-rule-char [ *(should-rule-char / "_")
should-rule-char ]
any-rule = 1*rule-char
rule-char = %d35-%d42 / %d44-%d126 / REXTCHAR
Figure X: ABNF of the flavor parameter
4.1.1. flavor rules
[[TODO: consider. This section is mainly inspired from pandoc.]]
Most flavors are self-contained, with no options. However, some
flavors have optional rules that may be applied with discretion. For
those flavors where optional rules are an integral feature, the
author MAY indicate that those extra rules be applied in a plus sign-
delimited list.
Because Markdown has no inherent concept of validity, authors SHOULD 3.1. syntax
be aware that receivers are not required to honor these optional
rules--the special characters in the Markdown content may well be
interpreted as plain text, rather than Markdown markup. Generally
speaking, defining a new (simple) flavor is preferable to defining a
complex flavor with multiple optional rules.
A flavor rule identifier is composed of any sequence of Unicode The syntax parameter indicates the Markdown-derivative syntax in
characters excluding spaces (Zs category), control characters, which the author composed the content, without regard to any
quotation marks """, exclamation marks "!", and the plus sign "+"; particular implementation. With reference to the "paradigmatic use
however, lowercase ASCII letters and the underscore "_" alone SHOULD case" (i.e., collaborative Markdown editing) in Section 1.3, the
be used, where the underscore SHOULD NOT be at the beginning or end. syntax parameter primarily affects the "left-hand" side of a Markdown
The syntax for flavor rules derives in significant part from pandoc editor. The entire parameter is case-sensitive.
[PANDOC].
[[TODO: There are no requirements about exclamation marks for Syntaxes other than [MDSYNTAX] extend the original rules in some way.
unregistered rules...flavor rules SHOULD be registered along with the These extensions fall into broad categories: clarifying ambiguities
flavor, but a receiver does not need to reject the flavor parameter in [MDSYNTAX], adding brand new features, repurposing [MDSYNTAX] for
simply because it does not recognize a rule...it can just ignore the completely new use cases, and adding metadata or other structured
rule.]] data blocks. Occasionally new syntaxes directly contradict [MDSYNTAX]
based on seasoned experience.
4.2. processor A syntax identifier is composed of two or more characters excluding
(Unicode) separators, control characters, the hyphen-minus "-",
quotation marks """, and angle brackets "<" and ">"; however, ASCII
characters alone SHOULD be used. To promote interoperability, only
registered syntaxes are permissible. An IANA registry of syntaxes
will be created as discussed in Section 6.
The processor parameter indicates the specific Markdown When omitted, the default value is unspecified, which means that the
implementation that the author intends be used. The purpose of this syntax interpretation is up to the receiver. However, the receiver
parameter is to control the automatic processing of Markdown into SHOULD NOT "guess" based on content-sniffing, as this methodology is
some output format, but of course actual recipients may use this error-prone. Generators SHOULD always specify a syntax, whether
information for any useful purpose. The entire parameter is case- explicitly or by context in embedding protocols or formats. All
sensitive. implementations MUST support the syntax value "Original", with the
meaning covered in Section 6. Generators MUST omit the syntax
parameter rather than transmitting an empty string (""); the empty
string is a syntax error per the ABNF below. The full ABNF of the
syntax parameter is:
An IANA registry of processors will be created as discussed in syntax-param = syntax-id [ "-" version ]
Section 5. A processor identifier is composed of two or more Unicode *( 1*WSP extension ) *WSP
characters excluding spaces (Zs category), control characters, the
hyphen-minus "-", quotation marks """, the less-than sign "<", and
the greater-than sign ">"; however, ASCII characters alone SHOULD be
used. Additionally, registered processor identifiers MUST NOT begin
with "!", the exclamation mark. Unregistered processor identifiers
MUST begin with "!" (plus two additional characters).
When omitted, the default value is to use whatever processor the syntax-id = 2*sid-char
receiver prefers. Generators MUST NOT emit empty processor
parameters, but parsers MUST treat empty processor parameters the
same as if omitted.
The full ABNF of the processor parameter is: version = 1*sid-char
processor-param = processor [ "-" version ] sid-char = %d33 / %d35-44 / %d46-59 / %d61 /
*( 1*WSP argument ) *WSP %d63-126 / REXTCHAR
processor = registered-pid / unregistered-pid extension = ext-name [ ":" ( ext-string / ext-uri ) ]
registered-pid = pid-char 1*("!" / pid-char) ext-name = 1*( %d33 / %d35-57 / %d59 / %d61 /
%d63-126 / REXTCHAR )
unregistered-pid = "!" 2*pid-char ext-string = ext-quoted [ ext-string ] /
( ext-safe-char / ">" )
*( ext-safe-char / "<" / ">" / ext-quoted )
version = pid-char *("!" / pid-char) ext-safe-char = %d33 / %d35-59 / %d61 / %d63-126 / REXTCHAR
; [[NB: Could be EXTCHAR ? depends on how we feel about Unicode
; high-order separators]]
argument = regular-argument / uri-argument ext-quoted = DQUOTE *eqcontent DQUOTE
regular-argument = 1*(regular-char / quoted-chars) ext-uri = "<" URI-reference ">" ; from [RFC3986]
pid-char = %d35-%d44 / %d46-%d59 / %d61 / eqcontent = %d0-33 / %d35-127 / EXTCHAR / DQUOTE DQUOTE
%d63-126 / REXTCHAR
regular-char = %d33 / %d35-%d59 / %d61 / %d63-126 / REXTCHAR Figure X: ABNF of the syntax parameter
quoted-chars = DQUOTE *pqcontent DQUOTE
pqcontent = %d1-%d33 / %d35-127 / EXTCHAR / DQUOTE DQUOTE 3.1.1. syntax version
uri-argument = "<" URI-reference ">" ; from [RFC3986] For better precision, an author MAY include the syntax version. The
version is delimited from the syntax identifier with a hyphen-minus
"-" and has the same repertoire as the syntax identifier. The version
string itself is an opaque string of at least one character. Version
strings (e.g., "2.0", "3.0.5") are registered and updated along with
the syntax registration. Updates to syntax registrations SHOULD only
add new versions when those new versions have a material difference
on the interpretation of the Markdown content. If a syntax has a
version "2014.10" and a version "2014.11", for example, but "2014.11"
only fixes typos in the specification, the registration SHOULD NOT
separately register the "2014.11" version. The repertoire of the
version string is the same as the syntax identifier (and like the
processor identifier, ASCII characters alone SHOULD be used).
Figure X: processor parameter ABNF A receiver that recognizes the syntax but not the version MAY use any
version of the syntax, preferably the latest version.
4.2.1. processor version 3.1.2. syntax extensions
For better precision, an author MAY include the processor version. Some Markdown syntaxes are self-contained, with no options. However,
The version is delimited from the processor identifier with a hyphen- others have optional rules or features that may be applied with
minus "-"; the version string itself is an opaque string. Version discretion. For those syntax systems where optional rules are an
strings (e.g., "2.0", "3.0.5") are registered and updated along with integral feature, the author MAY indicate that those named extensions
the processor registration. Updates to processor registrations SHOULD be applied in a whitespace-separated list. The syntax for extensions
only add new versions when those new versions have a material derives in significant part from pandoc [PANDOC].
difference on the interpretation of the Markdown content. If a
processor has a version "2014.10" and a version "2014.11", for
example, but "2014.11" only provides performance updates, then the
processor registration SHOULD NOT separately register the "2014.11"
version. The repertoire of the version string is the same as the
processor identifier (and like the processor identifier, ASCII
characters alone SHOULD be used).
A receiver that recognizes the processor but not the processor All extensions for a particular syntax are to be registered as part
version MAY use any version of the processor, preferably the latest of the syntax registration in Section 7.
version.
4.2.2. processor arguments An extension identifier is composed of any sequence of characters
excluding (Unicode) separators, control characters, the colon ":",
quotation marks """, and angle brackets "<" and ">"; however,
lowercase ASCII letters and the underscore "_" alone SHOULD be used,
where the underscore SHOULD NOT be at the beginning or end.
Processor arguments MAY be supplied for finer-grained control over When present, an extension is "enabled", "enabled, with string", or
how the processor behaves. Multiple arguments and URI references are "enabled, with URI". When absent, an extension is "disabled". An
supported. extension can have different semantics depending on whether a string
or URI is supplied. For example, an extension "bullet" could specify
whether and how to render bulleted lists. "Disabled" could mean
"bulleted" lists do not have bullets; "enabled" could mean that the
bullet is some default character; "enabled, with string" could mean
that the string is used as the bullet; finally, "enabled, with URI"
could mean that the image identified by URI is used as the bullet.
4.2.2.1. Quoted Arguments 3.1.2.1. Enabled, with String
According to the ABNF above, arguments are delimited by whitespace. According to the ABNF above, extensions are delimited by whitespace.
Quotation marks are used to support zero-length arguments, as well as Quotation marks are used to support zero-length strings, whitespace
whitespace or quotation marks in a single argument. If a quotation or quotation marks in a single string, or strings where the first
mark appears anywhere in the argument, the following text is character is "<". If a quotation mark appears anywhere in the string,
considered quoted; two successive quotation marks "" mean one the following text is considered quoted; two successive quotation
quotation mark. A single quotation mark ends the quoting. Because of marks "" within quoted text mean one quotation mark in the string. A
this rule, quotation marks do not have to appear at the termini of an single quotation mark ends the quoting. Generators MUST NOT generate
argument; embedded quotation marks start (and end) quoting within a unterminated quoted strings; however, parsers SHOULD treat an
unterminated quoted string as if it were terminated. Because of this
rule, quotation marks do not have to appear at the termini of a
string; embedded quotation marks start (and end) quoting within a
single argument. For example: single argument. For example:
a""b a""b
means: means:
ab ab
for the actual argument. In spite of this relaxed positioning rule,
for human readability generators SHOULD quote the entire string in
lieu of embedding quoted sub-strings.
for the actual argument. 3.1.2.2. Enabled, with URI
4.2.2.2. URI Reference Arguments
Certain processors can take supplementary content, such as metadata,
from other resources. To support these workflows, an author MAY use
the URI delimiters <> to signal a URI, such as cid: or mid: URLs
[RFC2392] in the context of MIME messages. The URI MUST comply with
[RFC3986], and MAY be a relative reference if the subject Markdown
content has a base URI. The receiver is to interpret this as a
request to retrieve the resource, and to supply that resource in a
local reference form that the processor can use (e.g., via a
temporary file). The URI MUST be entire argument; the URI cannot be
combined with other text to constitute the argument (and the ABNF
above supports this restriction). The reason for this restriction is
security, so that a maliciously constructed argument string cannot
resolve to some other file reference (such as parent directories like
../ or special files such as /dev/hd0). If the processor accepts URI
strings directly, the string is to be supplied as a regular string
without <> delimiters. For security reasons, direct file references
MUST NOT be included in the processor arguments.
The prior paragraph notwithstanding, certain workflows may require
file references. In such cases, file: URLs [RFC1738] (including
relative references) are appropriate. The receiver SHOULD apply the
same security and privacy analyses to file: URLs as it would to any
other URI.
4.2.2.3. Appropriate Arguments and Security Considerations
Not all arguments are appropriate for inclusion in the processor
parameter. Appropriate arguments are basically limited to those that
affect the output markup, without side-effects. Arguments MUST NOT
identify input sources or output destinations. For example, if a
processor normally reads Markdown input using the arguments "-i
filename" or "< filename" (i.e., from standard input), those
arguments MUST be omitted. Arguments that have no bearing on the
output MUST be omitted as well, such as arguments that control
verbosity of the processor (-v) or that cause side-effects (such as
writing diagnostic messages to some other file). Of course, if
warnings or errors are signaled within the output, arguments enabling
that output MAY be used.
When in doubt, a receiver SHOULD omit arguments with unknown or
undocumented effects, and MAY ignore author-supplied arguments
entirely, but SHALL NOT reorder arguments. An author has very little
assurance that a receiver will honor unregistered arguments.
Consequently, the burden is squarely on processor registrants
(Section 5.2) to document their arguments properly.
For security reasons, the parsed argument array (or a string
unambiguously representing the delimited argument array) MUST be
passed directly to the processor. Emitting the argument array as-is
in a batch script (for example) may cause risky side effects, such as
automatic substitutions, alias activation, or macro execution. The
arguments in this parameter MUST be encoded to preserve characters
outside of US-ASCII, and to signal the required encoding to the
receiver. When going between (system) processes, some implementations
may interpret character codes based on locale environment variables.
Therefore, it is not sufficient to pass arguments from this parameter
"as-is" to the processor: the routine MUST change the locale or
transform the arguments to an appropriate character encoding so that
there is no ambiguity. Furthermore, the NUL character (%d0, U+0000)
is not permitted because most common operating systems use that code
point as a delimiter.
4.2.3. Examples of processor parameters
[[TODO: provide examples.]] Certain syntaxes can take supplementary content, such as metadata,
from other resources. To support these workflows, an extension can
use the URI delimiters "<" and ">" to signal a URI, such as a cid: or
mid: URL [RFC2392] in the context of MIME messages. The URI MUST
comply with [RFC3986], and MAY be a relative reference if the subject
Markdown content has a base URI. The charset parameter specifies the
character encoding that is relevant to the URI's semantics (to the
extent that the URI needs it).
4.3. output-type 3.2. output-type
The output-type parameter indicates the Internet media type (and The output-type parameter indicates the Internet media type (and
parameters) of the output from the processor. parameters) of the output from the processor. With reference to the
"paradigmatic use case" (i.e., collaborative Markdown editing) in
Section 1.3, the outout-type parameter primarily affects the "right-
hand" side of a Markdown editor.
When omitted, the default value is "text/html". Generators MUST NOT When omitted, the default value is "text/html". Implementations
emit empty output-type parameters, but parsers MUST treat empty SHOULD anticipate and support HTML (text/html) and XHTML
output-type parameters the same as if omitted. (application/xhtml+xml) output, to the extent that a syntax targets
those markup languages.
The default value of text/html ought to be suitable for the majority The default value of text/html ought to be suitable for the majority
of current purposes. However, Markdown is increasingly becoming of current purposes. However, Markdown is increasingly becoming
integral to workflows where HTML is not the target output; examples integral to workflows where HTML is not the target output; examples
range from TeX [CITE], to PDF [CITE], to OPML [CITE], and even to range from TeX, to PDF, to OPML, and even to entire e-books (e.g.,
entire e-books [CITE]. [PANDOC]). Anticipated output types for a particular syntax are to be
registered as part of the syntax registration in Section 7.
Security provides a significant motivator for this parameter. Most 3.2.1. Value Format and Semantics
Markdown processors emit byte (octet) streams; without a well-defined
means for a Markdown processor to pass metadata onwards, it is
perilous for post-processing to assume that the content is always
HTML. A processor might emit PostScript (application/postscript)
content, for example, in which case an HTML sanitizer would fail to
excise dangerous instructions.
The value of output-type is an Internet media type with optional The value of output-type is an Internet media type with optional
parameters. The syntax (including case sensitivity considerations) is parameters. The syntax (including case sensitivity considerations) is
the same as specified in [RFC2045] for the Content-Type header (with the same as specified in [RFC2045] for the Content-Type header (with
updates over time), namely: updates over time), namely:
type "/" subtype *(";" parameter) type "/" subtype *(";" parameter)
; Matching of media type and subtype ; Matching of media type and subtype
; is ALWAYS case-insensitive. ; is ALWAYS case-insensitive.
Figure X: Content-Type ABNF (from [RFC2045]) Figure X: Content-Type ABNF (from [RFC2045])
The Internet media type in the output-type parameter MUST be The Internet media type in the output-type parameter MUST be
observed. Processors or processor arguments that conflict with the observed.
output-type parameter MUST be re-chosen, ignored, or rejected.
Although arbitrary optional parameters may be passed along with the Although arbitrary parameters may be passed along with the Internet
Internet media type, receivers are under no obligation to honor or media type, receivers are under no obligation to honor or interpret
interpret them in any particular way. For example, the parameter them in any particular way. For example, the parameter value
value "text/plain; format=flowed; charset=ISO-2022-JP" obligates the "text/plain; format=flowed; charset=ISO-2022-JP" obligates the
receiver to output text/plain (and to treat the output as plain text- receiver to output text/plain (and to treat the output as plain text:
-no sneaking in or labeling the output as HTML!). In contrast, such a no sneaking in or labeling the output as HTML!). In contrast, such a
parameter value neither obligates the receiver to follow [RFC3676] parameter value neither obligates the receiver to follow [RFC3676]
(for flowed output) nor to output ISO-2022-JP Japanese character (for flowed output) nor to output ISO-2022-JP Japanese character
encoding (see [RFC1468]). encoding (see [RFC1468]).
Markdown implementations for all kinds of formats already exist,
including formats that are not registered Internet media types, or
that are inexpressible as Internet media types. For example, one
Markdown processor for the mass media industry outputs formatted
screenplays [CITE to fountain.io]: none of applicable media types
application/pdf, text/html, or text/plain adequately distinguish this
kind of output. Such distinctions SHOULD be made in the processor
parameter (and to a lesser extent, the flavor parameter),
underscoring that the primary concern of the output-type parameter is
making technical and security-related decisions.
The output-type parameter does not distinguish between fragment The output-type parameter does not distinguish between fragment
content and whole-document content. A Markdown processor MAY (and content and whole-document content. A Markdown processor MAY (and
typically will) output HTML or XHTML fragment content, without typically will) output HTML or XHTML fragment content, without
preambles or postambles such as <!DOCTYPE>, <html>, <head>, </head>, preambles or postambles such as <!DOCTYPE>, <html>, <head>, </head>,
<body>, </body>, or </html> elements. Receivers MUST be aware of this <body>, </body>, or </html> elements. Receivers MUST be aware of this
behavior and take appropriate precautions. behavior and take appropriate precautions. Fragment vs. whole-
document output considerations are appropriate for addressing in
syntax specifications, either as part of the syntax or by a syntax
extension.
3.2.2. text/markdown Special Value
[[TODO: consider.]]
The author may specify the output-type "text/markdown", which has a The author may specify the output-type "text/markdown", which has a
special meaning. "text/markdown" means that the author does not want special meaning. "text/markdown" means that the author does not want
to invoke Markdown processing at all: the receiver SHOULD view the to invoke Markdown processing at all: the receiver SHOULD view the
Markdown source as-is. In this case, the processor choice has little Markdown source as-is.
practical effect because the Markdown is not actually processed, but
other tools can use the flavor parameter (and secondarily if so This output-type is not the default because one generally assumes
inclined, the processor parameter) to perform useful services such as that Markdown is meant for composing rather than reading: readers
syntax highlighting. This output-type is not the default because one expect to see the output format (or dual-display of the output and
generally assumes that Markdown is meant for composing rather than the Markdown). However, if authors are collaboratively editing a
reading: readers expect to see the output format (or dual-display of document or are discussing Markdown, "text/markdown" may make sense.
the output and the Markdown). However, if authors are collaboratively Furthermore, "text/markdown" differs from "text/plain" in that
editing a document or are discussing Markdown, "text/markdown" may "text/plain" encompasses a wide range of characters and formatting
make sense. While the optional parameter output-type may be used techniques (in Unicode, examples include bullet points, roman
numerals, unambiguous line and paragraph separators, and interlinear
annotation). While the optional parameter output-type may be used
recursively (as a sneaky way to stash the author's follow-on or recursively (as a sneaky way to stash the author's follow-on or
secondary intent), receivers are not obligated to recognize it; secondary intent), receivers are not obligated to recognize it;
optional parameters internal to output-type MAY be ignored. optional parameters internal to output-type MAY be ignored.
5. IANA Considerations 4. Fragment Identifiers
IANA is asked to register the media type text/markdown in the
Standards tree using the application provided in Section 2 of this
document.
IANA is also asked to establish a subtype registry called "Markdown
Parameters". The registry has two sub-registries: a registry of
flavors and a registry of processors.
5.1. Registry of Flavors
Each entry in this registry shall consist of a flavor identifier and
information about the flavor, as follows:
5.1.1. Flavor Template
Identifier: [Identifier] 4.1. #t
Description: [Concise, prose description of the syntax, [[NB: This section used to say: The fragment #i refers to the content
with emphasis on its purpose, the community input into a Markdown processor, which for purposes of this fragment
that it addresses, and notable variations identifier, MUST be treated as plain text (text/plain).]]
from [MDSYNTAX] or another flavor.]
Documentation: [References to documentation.] The fragment #t refers to the Markdown content treated as plain text
(text/plain). A specific area of the text can be identified with a
text/plain sub-fragment identifier (e.g., [RFC5147] or its
successors) delimited by a second "#" character. For example:
#t#line=10 identifies the eleventh line of Markdown input.
Implementers should take heed that the "char" scheme counts by
characters rather than octets (or, for that matter, code points);
thus proper interpretation of the charset parameter is REQUIRED for
interoperability of the "char" scheme. For example, "character" and
"code point" are NOT synonymous in the Unicode Standard.
Rules: 4.2. #o
{for each rule}
Identifier: [Identifier]
Description: [Concise, prose description of the rule.]
Documentation: [References to documentation.]
Responsible Parties: The fragment #o refers to the content output from a Markdown
{for each party} processor, which is governed by the output-type parameter. A specific
([type: individual, corporate, representative]) area of the output can be identified with a sub-fragment identifier
[Name] <contact info 1>...<contact info n> delimited by a second "#" character. The encoding and semantics of
sub-fragment identifiers are also governed by the output-type
parameter. Examples: when the output-type is text/html [RFC2854],
#o#section6 identifies the named anchor "section6" specified by the
input that the Markdown processor converts to <a
name=section6>...</a>. When the output-type is application/pdf
[RFC3778], #o#page=6 causes the sixth page to open.
Currently Maintained? [Yes/No] When the output-type is "text/markdown" (regardless of parameters),
Tools: the #o fragment identifier has no semantics; generators MUST use #t
{for each tool} in lieu of #o.
Name: [Name]
Version(s): [Significant version or versions that
implement the flavor]
Type: ["Processor" or some other type]
Reference(s): <contact info 1>...<contact info n>
Purpose: [Concise, prose description of the tool.]
A responsible party can be an individual author or maintainer, a 4.3. #l and #ldef
corporate author or maintainer (plus an individual contact), or a
representative of a community of interest dedicated to the Markdown
syntax.
Multiple tools MAY be listed, but only one is necessary for a The fragment prefix #l refers to links by their link identifiers. The
successful registration. If a tool is a Markdown processor, it MUST sub-component of this identifier is delimited by a second "#"
be registered; however, any Markdown-related tool (for example, character, followed by the encoded link identifier, optionally
graphical editors, emacs "major modes", web apps) is acceptable. The followed by a 1-based index number. Without the index number, the
purpose of the tool requirement is to ensure that the flavor is fragment refers to all such identified links. Example: #l#eS matches
actually used in practice. links such as "The rain in [Spain][ES]" and "The word [es][] means
'is' in Spanish." #l#es#2 only matches the second instance of the
"es" link identifier.
5.1.2. Initial Registration The fragment prefix #ldef refers to link reference definitions. The
sub-component of this identifier is delimited by a second "#"
character, followed by the encoded link identifier. There is no index
number; in the case of multiple link reference definitions, the last
definition wins.
The registry shall have the following initial registration: Both the #l and #ldef REQUIRE that "#" characters be percent-encoded
if they are part of the link identifier. The percent-encoding of
other characters follow the regular rules of [RFC3986]. [MDSYNTAX]
states that identifiers (or names) "may consist of letters, numbers,
spaces, and punctuation--but they are NOT case sensitive." Characters
outside of the URI character set SHALL be percent-encoded with the
same encoding as the Markdown content. For maximum compatibility and
readability, authors who intend to reference links in fragment
identifiers SHOULD limit themselves to URI characters that do not
require percent-encoding.
Identifier: Original 4.4. Other Fragment Identifiers
Description: Gruber's original Markdown syntax. Specific syntaxes may define additional fragment identifiers specific
to the syntax. For example, a syntax that incorporates "header"
information might consider #h to refer to the "header" part, and #b
to refer to the "body" part.
Documentation: [MDSYNTAX] 5. Example
Rules: None. The following is an example of Markdown as an e-mail attachment:
Responsible Parties: MIME-Version: 1.0
(individual) John Gruber <http://daringfireball.net/> Content-Type: text/markdown; charset=UTF-8; syntax=Original;
<comments@daringfireball.net> output-type="application/xhtml+xml"
Content-Disposition: attachment; filename=readme.md
Currently Maintained? No Sample HTML 4 Markdown
=============
Tools: This is some sample Markdown. [Hooray!][foo]
Name: Markdown.pl (Remember that link identifiers are not case-sensitive.)
Version(s): 1.0.1, 1.0.2b8
Type: Processor
Reference(s): <http://daringfireball.net/projects/markdown/>
Purpose: Converts Markdown to HTML or XHTML circa 2004.
5.1.3. Reserved Identifiers Bulleted Lists
The flavors registry SHALL have the following identifiers RESERVED. -------
No one is allowed to register them (or any case variations of them).
Standard
Common
Markdown
5.1.4. Standard of Review Here are some bulleted lists...
Registrations are made by a highly constrained Expert Review * One Potato
[RFC5226] that amounts more-or-less to First-Come, First-Served with * Two Potato
sanity checking. * Three Potato
- One Tomato
- Two Tomato
- Three Tomato
The designated expert SHALL review the flavor registration. The More Information
identifier MUST comply with the syntax specified in this document. -----------
Additionally, the identifier MUST NOT differ from other registered
identifiers merely by case. The description and documentation SHOULD
provide sufficient guidance to an implementer to implement a tool to
handle the flavor. The designated expert SHOULD warn the registrant
if the description and documentation are inadequate; however,
inadequacy (in the opinion of the designated expert) will not bar a
registration.
All references (including contact information) MUST be verified as [.markdown, .md](http://daringfireball.net/projects/markdown/)
functional at the time of the registration. has more information.
If rules are included in the registration, the rule identifiers MUST [fOo]: http://example.com/loc 'Will Not Work with Markdown.pl-1.0.1'
comply with the syntax specified in this document. The description
and documentation of each rule SHOULD provide sufficient guidance to
an implementer to implement a tool to handle the rule. The designated
expert SHOULD warn the registrant if the description and
documentation are inadequate; however, inadequacy (in the opinion of
the designated expert) will not bar a registration.
The designated expert MUST determine that all tools listed in the 6. IANA Considerations
registration are real implementations. If a tool is a Markdown
processor, the processor MUST be registered in the Registry of
Flavors in Section 5.2. The designated expert MAY request that the
registrant provide evidence that a tool actually works (for example,
that it passes certain test suites); however, the failure of a tool
to work according to the flavor registration will not bar a
registration. (For example, not even Gruber's own Markdown.pl
implementation complies with [MDSYNTAX]. C'est la vie!)
If a registration is being updated, the designated expert SHOULD IANA is asked to register the media type text/markdown in the
verify that the updating registrant matches the contact information Standards tree using the application provided in Section 2 of this
on the prior registration, and if not, that the updating registrant document.
has authority from the prior registrant to update it. All fields may
be updated except the Identifier, which is permanent: not even case
may be changed.
5.2. Registry of Processors IANA is also asked to establish a subtype registry called "Markdown
Syntaxes". Each entry in this registry shall consist of a syntax
identifier and information about the syntax, as follows:
Each entry in this registry SHALL consist of a processor identifier 6.1. Syntax Template
and information about the processor, as follows:
5.2.1. Processor Template {if provisional}
PROVISIONAL REGISTRATION EXPIRES [YYYY-MM-DD date format]
Identifier: [Identifier] Identifier: [Identifier]
Description: [Concise, prose description of the processor, Description: [Concise, prose description of the syntax, with
with emphasis on its purpose, the community emphasis on its purpose and notable variations
that it addresses, and notable variations from [MDSYNTAX] or another syntax. If the syntax
from [MDSYNTAX] or another flavor.] permits structured data, this fact ought to be
included. Other Markdown syntaxes may be referenced
by quoting their registered identifiers.]
Documentation: [References to documentation.] Documentation: [References to documentation.]
Community of Use: [Concise, prose description of the
community of use, such as
"scholarly publications" or "screenwriting".
"General" may be entered if the community
encompasses general users of the Internet.]
[[TODO: Users (screenwriters) or use cases
(screenwriting)?]]
[[NB: Should Versions: and Extensions: be {optional} and
therefore omittable, or should they have "None." to
indicate that no versions or extensions apply?]]
Versions: Versions:
{for each version} {for each version}
Identifier: [Identifier] Identifier: [Identifier]
Description: [Optional, concise, prose description of the Description: [Optional, concise, prose description of the
version. "N/A" SHALL be used to indicate no description.] version. "N/A" SHALL be used to indicate no description.]
Arguments: Extensions:
{in general} {for each extension}
Argument Ordering: [Concise, prose description of how Identifier: [Identifier]
arguments need to be ordered.] Syntax:
{for each argument} {if Enabled}
Argument Syntax: [Syntax here; multiple consecutive argument Enabled
positions are allowed, separated by a single space. Use {if Enabled, with String}
braces for variable information (add : for example input), Enabled, with String: [prose description of what the
<URI> for URI references, and .. for sequences of arguments string is (not what it does)]
with # as a placeholder for the number of arguments or {if Enabled, with URI}
..-.. to indicate the first character of the subsequent Enabled, with URI: [prose description of what the URI
argument that ends the sequence, e.g.: is (not what it does)]
-c Description: [Concise, prose description of the extension,
--title {title: "The Rain in Spain"} i.e., what it does.]
--metadata <URI>
--bullet-chars:{#} {char 1}..{char #}
--verbs {verb: walk, run, sleep}..-..
]
Description: [Concise, prose description of the argument.]
Documentation: [References to documentation.] Documentation: [References to documentation.]
Output Type(s): [Internet media types, comma-separated Anticipated Output Types:
(with optional LWSP)] {for each output-type}
[media type]
{optional} [prose description of parameter considerations]
Security Considerations: [Sufficient description of risks and {optional}
other considerations; "N/A" or Additional Fragment Identifiers:
"None" responses are insufficient.] [Prose description of additional fragment identifiers,
sufficient for interoperability.]
Responsible Parties: Responsible Parties:
{for each party} {for each party}
([type: individual, corporate, representative]) ([type: individual, corporate, representative])
[Name] <contact info 1>...<contact info n> [Name] <contact info 1>...<contact info n>
Currently Maintained? [Yes/No] Currently Maintained? [Yes/No]
{optional}
Implementations:
{for each implementation}
Name: [Name]
Version(s): [Significant version or versions that
implement the syntax]
Type: ["Processor" or some other type]
References: <contact info 1>...<contact info n>
Purpose: [Concise, prose description of the implementation.]
A responsible party can be an individual author or maintainer, a A responsible party can be an individual author or maintainer, a
corporate author or maintainer (plus an individual contact), or a corporate author or maintainer (plus an individual contact), or a
representative of a community of interest dedicated to the Markdown representative of a community of interest dedicated to the Markdown
processor. syntax.
5.2.2. Initial Registration The Versions, Extensions, Additional Fragment Identifiers, and
Implementations sections are optional.
The registry shall have the following initial registration: 6.2. Initial Registration
Identifier: Markdown.pl The registry shall have the following initial registration;
implementations conforming to this document MUST handle this syntax.
[MDMTUSES] provides additional exemplary syntaxes.
Description: Gruber's original Markdown processor, written in Identifier: Original
Perl. Requires Perl 5.6.0 or later. "Welcome to
the 21st Century." Works with Movable Type 2.6+,
Blosxom 2.0+, BBEdit 6.1+, and the command-line.
Documentation: [MARKDOWN] Description: Gruber's original Markdown syntax.
Versions: Documentation:
Identifier: 1.0.1 [MDSYNTAX]. For the "2004" version, the documentation is
Description: The 2004-12-17 version. provided in HTML and in Markdown, as follows:
syntax: Content-Type: text/html; charset=UTF-8
Accessed at October 12, 2014 8:27 PM (-0700)
38570 bytes
SHA-256 hash: B2EC2A62 3257F164 FBC88AE8 C7E76F3F
80F16845 105D9F3E 3E8CE25B 6F0CB33B
Identifier: 1.0.2b8 syntax.text: Content-Type: text/plain; charset=UTF-8
Description: The 2007-05-09 version. Fixes many bugs (actually text/markdown;
and adds several new features; see syntax=Original;
VERSION HISTORY in Markdown.pl. output-type="text/markdown")
Accessed at October 12, 2014 8:27 PM (-0700)
27784 bytes
SHA-256 hash: 01A6A07A F51838E1 8749454B 06D716BC
B1BC0EAA A21B67B7 D6FB5A6B 4FFB5D5B
Arguments: Community of Use: General.
Argument Syntax: --html4tags
Description:
"Use the --html4tags command-line switch to produce HTML
output from a Unix-style command line."
Without this argument, Markdown.pl outputs XHTML style
tags by default, e.g.: <br />. Even though XHTML style
is the default, the output SHOULD be analyzed as
text/html; the processor makes no attempt to make
its output well-formed application/html+xml
(not surprising--see the design philosophy).
Documentation: [MARKDOWN]
Output Type: text/html Versions:
Identifier: 2004
Description: [MDSYNTAX] as it (is rumored to have) existed
since December 14, 2004, corresponding to
Markdown.pl 1.0.1. The version "2004" SHOULD NOT
be specified until further notice; is is only
documented for completeness (in case Gruber
revises the syntax with material contradictions).
Security Considerations: The security of this implementation Anticipated Output Types:
has not been fully analyzed. text/html
application/xhtml+xml
Responsible Parties: Responsible Parties:
(individual) John Gruber <http://daringfireball.net/> (individual) John Gruber <http://daringfireball.net/>
<comments@daringfireball.net> <comments@daringfireball.net>
Currently Maintained? No [[TODO: maybe?]] Currently Maintained? No
5.2.3. Reserved Identifiers Implementations:
Name: Markdown.pl
Version(s): 1.0.1, 1.0.2b8
Type: Processor
References: [MARKDOWN]
Purpose: Converts Markdown to HTML or XHTML circa 2004.
The argument "--html4tags" causes HTML output.
The processors registry SHALL have the following identifiers 6.3. Reserved Identifiers
RESERVED. No one is allowed to register them (or any case variations
of them). The registry SHALL have the following identifiers RESERVED. No one is
allowed to register them (or any case variations of them).
Standard Standard
Common
Markdown Markdown
md
5.2.4. Standard of Review 6.4. Standard of Review
Registrations are First-Come, First-Served [RFC5226]. The checks Registrations are made on a First-Come, First-Served [RFC5226] basis
by anyone with a need to interoperate. While documentation is
required, any level of documentation is sufficient; thus, neither
Specification Required nor Expert Review are warranted. The checks
prescribed by this section can be performed automatically. prescribed by this section can be performed automatically.
The identifier MUST comply with the syntax specified in this Syntax, version, and extension identifiers MUST comply with the
document. Additionally, the identifier MUST NOT differ from other syntaxes specified in this document. Additionally, the identifier
registered identifiers merely by case. The description and MUST NOT differ from other registered identifiers merely by case.
documentation SHOULD provide sufficient guidance to an implementer to Identifiers MUST conform to [[TODO: PRECIS? STRINGPREP?]]. The
know how to invoke the processor and handle the output. purpose of this requirement is to eliminate confusingly similar
identifiers, placing the burden on the registration process rather
than on syntax parameter parsers.
All references (including contact information) MUST be verified as All references (including contact information) MUST be verified as
functional at the time of the registration. functional at the time of the registration.
If arguments are included in the registration, the Argument Syntax
MUST comply with the template instructions in Section 5.2.1. Each
description and documentation field SHOULD provide sufficient
guidance to an implementer to know how to invoke the processor and
handle the output.
The Security Considerations field is not optional; it MUST be
provided.
If a registration is being updated, the contact information MUST If a registration is being updated, the contact information MUST
either match the prior registration and be verified, or the prior either match the prior registration and be verified, or the prior
registrant MUST confirm that the updating registrant has authority to registrant MUST confirm that the updating registrant has authority to
update the registration. All fields may be updated except the update the registration. As a special "escape valve", registrations
Identifier, which is permanent: not even case may be changed. can be updated with IETF Review [RFC5226]. [[NB: Two purposes: 1) to
deal with "harmful" registrations (stale references are not a
sufficient justification); 2) to deal with registrations that are
IETF registrations, like RFC-related Markdown (but this could be
handled by listing the IETF as the contact organization, right?).]]
All fields may be updated except the syntax identifier, which is
permanent: not even case may be changed.
6. Security Considerations 6.5. Provisional Registration
See the answer to the Security Considerations template questions in Any registrant may make a provisional registration to reserve a
Section 2. syntax identifier. Provisional registrations include the ALL-CAPS
legend as shown in Section 6.1. All fields are optional except for
the syntax identifier and contact information. Provisional
registrations expire after three months, after which time the syntax
identifier may be reused.
Security considerations for the optional parameters are integrated 7. Security Considerations
throughout Section 4.
7. References See the Security considerations entry in Section 2.
7.1. Normative References 8. References
8.1. Normative References
[MARKDOWN] Gruber, J., "Daring Fireball: Markdown", December 2004, [MARKDOWN] Gruber, J., "Daring Fireball: Markdown", December 2004,
<http://daringfireball.net/projects/markdown/>. <http://daringfireball.net/projects/markdown/>.
[MDSYNTAX] Gruber, J., "Daring Fireball: Markdown Syntax [MDSYNTAX] Gruber, J., "Daring Fireball: Markdown Syntax
Documentation", December 2004, Documentation", December 2004,
<http://daringfireball.net/projects/markdown/syntax>. <http://daringfireball.net/projects/markdown/syntax>.
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform [MDUTI] Gruber, J., "Daring Fireball: Uniform Type Identifier for
Resource Locators (URL)", RFC 1738, December 1994. Markdown", August 2011,
<http://daringfireball.net/linked/2011/08/05/markdown-
uti>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media
Type", RFC 2854, June 2000.
[RFC3778] Taft, E., Pravetz, J., Zilles, S., and L. Masinter, "The
application/pdf Media Type", RFC 3778, May 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005. 3986, January 2005.
[RFC5147] Wilde, E. and M. Duerst, "URI Fragment Identifiers for the
text/plain Media Type", RFC 5147, April 2008.
[RFC5226] Narten, T., and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T., and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, May 2008. IANA Considerations Section in RFCs", RFC 5226, May 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008. October 2008.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, RFC Specifications and Registration Procedures", BCP 13, RFC
6838, January 2013. 6838, January 2013.
7.2. Informative References 8.2. Informative References
[HUMANE] Atwood, J., "Is HTML a Humane Markup Language?", May 2008, [HUMANE] Atwood, J., "Is HTML a Humane Markup Language?", May 2008,
<http://blog.codinghorror.com/is-html-a-humane-markup- <http://blog.codinghorror.com/is-html-a-humane-markup-
language/>. language/>.
[DIN2MD] Gruber, J., "Dive Into Markdown", March 2004,
<http://daringfireball.net/2004/03/dive_into_markdown>.
[MD102b8] Gruber, J., "[ANN] Markdown.pl 1.0.2b8", May 2007,
<http://six.pairlist.net/pipermail/markdown-discuss/2007-
May/000615.html>, <http://daringfireball.net/projects/
downloads/Markdown_1.0.2b8.tbz>.
[CATPICS] Gruber, J. and M. Arment, "The Talk Show: Ep. 88: 'Cat
Pictures' (Side 1)", July 2014,
<http://daringfireball.net/thetalkshow/2014/07/19/ep-088>.
[INETMEME] Solon, O., "Richard Dawkins on the internet's hijacking of [INETMEME] Solon, O., "Richard Dawkins on the internet's hijacking of
the word 'meme'", June 2013, the word 'meme'", June 2013,
<http://www.wired.co.uk/news/archive/2013-06/20/richard- <http://www.wired.co.uk/news/archive/2013-06/20/richard-
dawkins-memes>, <http://www.webcitation.org/6HzDGE9Go>. dawkins-memes>, <http://www.webcitation.org/6HzDGE9Go>.
[MULTIMD] Penney, F., "MultiMarkdown", April 2014, [MDMTUSES] Leonard, S., "text/markdown Use Cases", draft-seantek-
<http://fletcherpenney.net/multimarkdown/>. text-markdown-use-cases-00 (work in progress), October
2014.
[PANDOC] MacFarlane, J., "Pandoc", 2014, [PANDOC] MacFarlane, J., "Pandoc", 2014,
<http://johnmacfarlane.net/pandoc/>. <http://johnmacfarlane.net/pandoc/>.
[RAILFROG] Railfrog Team, "Railfrog", April 2009, [RAILFROG] Railfrog Team, "Railfrog", April 2009,
<http://railfrog.com/>. <http://railfrog.com/>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC1468] Murai, J., Crispin, M., and E. van der Poel, "Japanese
793, September 1981. Character Encoding for Internet Messages", RFC 1468, June
1993.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998. Locators", RFC 2392, August 1998.
[RFC3676] Gellens, R., "The Text/Plain Format and DelSp Parameters",
RFC 3676, February 2004.
[RFC4263] Lilly, B., "Media Subtype Registration for Media Type [RFC4263] Lilly, B., "Media Subtype Registration for Media Type
text/troff", RFC 4263, January 2006. text/troff", RFC 4263, January 2006.
[XML1.0-3] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and [FOUNTAIN] Maschwitz, S. and J. August, "Fountain | A markup language
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third for screenwriting.", 2014, <http://fountain.io/>.
Edition)", World Wide Web Consortium Recommendation REC-
xml-20040204, February 2004,
<http://www.w3.org/TR/2004/REC-xml-20040204#dt-fatal>.
[TODO] [[Add remaining references.]] [FTSYNTAX] Maschwitz, S. and J. August, "Syntax - Fountain | A markup
language for screenwriting.", 1.1, March 2014,
<http://fountain.io/syntax>.
Appendix A. Change Log Appendix A. Change Log
This draft is a continuation from draft-ietf-appsawg-text-markdown- This draft is a continuation from draft-ietf-appsawg-text-markdown-
01.txt. These technical changes were made: 02.txt. These technical changes were made:
1. The entire document was reorganized: optional parameters now 1. Proposed that the document be split into two documents: the
have their own section, and the Introduction section is main document (which is normative), and a second document. The
divided into four subsections. second document (draft-seantek-text-markdown-use-cases-00)
2. The Introduction section provides substantial background [MDMTUSES] provides additional background information,
information, along with goals and use cases for both Markdown suggestions for preserving metadata, registration templates
and the Internet media type registration. for common Markdown syntaxes, and examples for common Markdown
3. The rules parameter was reverted back to flavor, and flavor syntaxes. RFC 2119 key words are not included in draft-
was beefed up. seantek-text-markdown-use-cases because this content is not
4. The processor parameters were consolidated and simplified. normative (at least, not as normative) compared with the main
5. Dependencies on POSIX were removed. document.
6. The output-type parameter was added. 2. De-emphasized Unicode (and UTF-8 encoding) after close
7. Unregistered identifiers can be used with their own ! syntax. consideration of the original [MDSYNTAX], and the various
8. The IANA Considerations section was fleshed out in great proposed extensions to Markdown in the intervening time.
detail, with emphasis on easing the registration process. "CommonMark", for example, places stronger emphasizes on
9. Security considerations were weaved throughout the Unicode (and UTF-8).
specification. Overall, most of the complexity in this 3. Deleted processor parameter.
specification comes directly from the security considerations. 4. Renamed flavor parameter to syntax parameter.
Those considerations are necessary since a lot of bad things 5. Renamed "rules" to "extensions" in the syntax parameter.
can and will happen when HTML, URIs, and executable code get 6. Parameterized "extensions" so that it can have a string or a
together. URI.
10. Changed the example in Section 2 to use initially registered 7. Simplified the syntax parameter (compared to draft-02, in any
identifiers. event) with fewer exceptional cases in the ABNF.
11. Added output-type="text/markdown" for recursive handling 8. Rewrote significant parts of the output-type parameter, and
(i.e., don't process this Markdown, just show it like it is). gave text/markdown additional explanation.
9. Rewrote the introduction so that it is much shorter.
10. Moved the example towards the end.
11. Added Fragment Identifier Considerations.
12. Consolidated the Security Considerations into the registration
template.
13. Rewrote the IANA Considerations section so that it only
creates one new registry.
14. Redefined the flavors registry (now called the Markdown
Syntaxes registry).
15. Rewrote the "Original" syntax registration to conform to the
new registration template.
16. Added a discussion and example of the Paradigmatic Use Case
(Markdown Editors).
Author's Address Author's Address
Sean Leonard Sean Leonard
Penango, Inc. Penango, Inc.
5900 Wilshire Boulevard 5900 Wilshire Boulevard
21st Floor 21st Floor
Los Angeles, CA 90036 Los Angeles, CA 90036
USA USA
 End of changes. 151 change blocks. 
762 lines changed or deleted 654 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/