draft-ietf-appsawg-text-markdown-08.txt   draft-ietf-appsawg-text-markdown-09.txt 
Applications Area Working Group S. Leonard Applications Area Working Group S. Leonard
Internet-Draft Penango, Inc. Internet-Draft Penango, Inc.
Intended Status: Informational June 18, 2015 Intended Status: Informational August 26, 2015
Expires: December 20, 2015 Expires: February 27, 2016
The text/markdown Media Type The text/markdown Media Type
draft-ietf-appsawg-text-markdown-08 draft-ietf-appsawg-text-markdown-09
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 2, line 19 skipping to change at page 2, line 19
1.2. Markdown Is About Writing and Editing . . . . . . . . . . . 3 1.2. Markdown Is About Writing and Editing . . . . . . . . . . . 3
1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Markdown Media Type Registration Application . . . . . . . . . 5 2. Markdown Media Type Registration Application . . . . . . . . . 5
3. Fragment Identifiers . . . . . . . . . . . . . . . . . . . . . 8 3. Fragment Identifiers . . . . . . . . . . . . . . . . . . . . . 8
3.1. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Content Disposition and preview-type . . . . . . . . . . . . . 8 4. Content Disposition and preview-type . . . . . . . . . . . . . 8
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6.1. Markdown Variants . . . . . . . . . . . . . . . . . . . . . 10 6.1. Markdown Variants . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
1.1. This Is Markdown! Or: Markup and Its Discontents 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: computer-
sequence of characters in some character set (code), possibly encoded text that consists only of a sequence of code points from a
interrupted by line breaks, page breaks, or other control characters. given standard, with no other formatting or structural information
The repertoire of these control characters (a form of in-band [UNICODE]. (On the other end is binary data, which computer systems
signaling) is necessarily limited, and not particularly extensible. store and process with bit-for-bit accuracy.) Many of these standards
Because they are non-printing, these characters are also hard to include control characters that are used as in-band signaling to
enter with standard keyboards. cause effects other than the addition of a symbol (or grapheme) to
the text.
Markup offers an alternative means to encode this signaling Markup offers an alternative means to encode this signaling
information by overloading certain characters with additional information by overloading certain graphic characters (see, e.g.,
meanings. Therefore, markup languages allow for annotating a document [ISO646]) with additional meanings. Therefore, markup languages allow
in such a way that annotations are syntactically distinguishable from for annotating a document in a syntactically distinguishable way from
the printing information. Markup languages are (reasonably) well- the text, while keeping the annotations printable. Markup languages
specified and tend to follow (mostly) standardized syntax rules. are (reasonably) well-specified and tend to follow (mostly)
Examples of formal markup languages include SGML, HTML, XML, and standardized syntax rules. Examples of formal markup languages
LaTeX. Standardized rules lead to interoperability between markup include SGML, HTML, XML, and LaTeX. Standardized rules lead to
processors, but impose skill requirements on new users that lead to interoperability between markup processors, but impose skill
markup languages becoming less accessible to beginners. These rules requirements on new users that lead to markup languages becoming less
also reify "validity": content that does not conform to the rules is accessible to beginners. These rules also reify "validity": content
treated differently (i.e., is rejected) than content that conforms. that does not conform to the rules is treated differently (i.e., is
rejected) than content that conforms.
In contrast to formal markup languages, lightweight markup languages In contrast to formal markup languages, lightweight markup languages
use simple syntaxes; they are designed to be easy for humans to enter use simple syntaxes; they are designed to be easy for humans to enter
and understand with basic text editors. Markdown, the subject of this and understand with basic text editors. Markdown, the subject of this
document, began as an /informal/ plain text formatting syntax document, began as an /informal/ plain text formatting syntax
[MDSYNTAX] and Perl script HTML/XHTML processor [MARKDOWN] targeted [MDSYNTAX] and Perl script HTML/XHTML processor [MARKDOWN] targeted
at non-technical users using unspecialized tools, such as plain text at non-technical users using unspecialized tools, such as plain text
e-mail clients. [MDSYNTAX] explicitly rejects the notion of validity: e-mail clients. [MDSYNTAX] explicitly rejects the notion of validity:
there is no such thing as "invalid" Markdown. If the Markdown content there is no such thing as "invalid" Markdown. If the Markdown content
does not result in the "right" output (defined as output that the does not result in the "right" output (defined as output that the
skipping to change at page 3, line 34 skipping to change at page 3, line 36
compatible with humans [HUMANE], are intended to produce different compatible with humans [HUMANE], are intended to produce different
kinds of outputs that push the boundaries of mutual intelligibility kinds of outputs that push the boundaries of mutual intelligibility
between software systems. between software systems.
To support identifying and conveying Markdown, this document defines To support identifying and conveying Markdown, this document defines
a media type and parameters that indicate the author's intent on how a media type and parameters that indicate the author's intent on how
to interpret the Markdown. This registration draws particular to interpret the Markdown. This registration draws particular
inspiration from text/troff [RFC4263], which is a plain text inspiration from text/troff [RFC4263], which is a plain text
formatting syntax for typesetting based on tools from the 1960s formatting syntax for typesetting based on tools from the 1960s
("RUNOFF") and 1970s ("nroff", et. al.). In that sense, Markdown is a ("RUNOFF") and 1970s ("nroff", et. al.). In that sense, Markdown is a
kind of troff for modern computing. A companion document [MDMTUSES] kind of troff for modern computing. A companion document [MDMTGUID]
provides additional Markdown background and philosophy. provides additional Markdown background, philosophy, local storage
strategies, and variant registrations (including examples).
1.2. Markdown Is About Writing and Editing 1.2. Markdown Is About Writing and Editing
"HTML is a *publishing* format; Markdown is a *writing* format. "HTML is a *publishing* format; Markdown is a *writing* format.
Thus, Markdown's formatting syntax only addresses issues Thus, Markdown's formatting syntax only addresses issues
that can be conveyed in plain text." [MDSYNTAX] that can be conveyed in plain text." [MDSYNTAX]
The paradigmatic use case for text/markdown is the Markdown editor: The paradigmatic use case for text/markdown is the Markdown editor:
an application that presents Markdown content (which looks like an e- an application that presents Markdown content (which looks like an e-
mail or other piece of plain text writing) alongside a published mail or other piece of plain text writing) alongside a published
skipping to change at page 4, line 42 skipping to change at page 4, line 42
/net/projects/markdown/syntax#html || Markdown editor: an application | /net/projects/markdown/syntax#html || Markdown editor: an application |
|"Markdown: Syntax: HTML" || that presents Markdown content | |"Markdown: Syntax: HTML" || that presents Markdown content |
| || ...</p> | | || ...</p> |
+----------------------------------++----------------------------------+ +----------------------------------++----------------------------------+
LEGEND: "/" embedded in a vertical line represents a line-continuation LEGEND: "/" embedded in a vertical line represents a line-continuation
marker, since a line break is not supposed to occur in that content. marker, since a line break is not supposed to occur in that content.
Figure 1: Markdown Split-Screen/Live Preview Editor Figure 1: Markdown Split-Screen/Live Preview Editor
Implementations SHOULD produce and consume mutually intelligible and To get the best results, implementations ought to produce and consume
identifiable bits of Markdown, so that users on diverse platforms can mutually intelligible and identifiable bits of Markdown. That way, users
collaborate with their tools of choice. Those tools MAY be desktop-based on diverse platforms can collaborate with their tools of choice. Those
(MarkdownPad, MultiMarkdown Composer), browser-based (Dillinger, tools can be desktop-based (MarkdownPad, MultiMarkdown Composer),
Markable), integrated widgets (Discourse, GitHub), general-purpose browser-based (Dillinger, Markable), integrated widgets (Discourse,
editors (emacs, vi), or plain old "Notepad". Additionally, GitHub), general-purpose editors (emacs, vi), or plain old "Notepad".
implementations SHOULD have common ways to identify particular areas of Additionally, implementations ought to have common ways to identify
Markdown content when the Markdown becomes appreciably large (e.g., book particular areas of Markdown content when the Markdown becomes
chapters and Internet-Drafts--not just blog posts). So that users have appreciably large (e.g., book chapters and Internet-Drafts--not just
the option to use Markdown in MIME-capable systems to convey their works blog posts). So that users have the option to use Markdown in MIME-
in progress, not just their finished products (for which full-blown capable systems to convey their works in progress, not just their
markups ranging from text/html to application/pdf are appropriate), finished products (for which full-blown markups ranging from text/html
implementations SHOULD label such Markdown content with a common media to application/pdf are appropriate), implementations ought to label such
type: text/markdown. This registration facilitates interoperability Markdown content with a common media type: text/markdown. This
between these Markdown editors by conveying the syntax of the particular registration facilitates interoperability between these Markdown editors
Markdown variant and the desired output format. by conveying the syntax of the particular Markdown variant and the
desired output format.
1.3. Definitions 1.3. Definitions
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].
Since Markdown signifies a family of related formats with varying Since Markdown signifies a family of related formats with varying
degrees of formal documentation and implementation, this degrees of formal documentation and implementation, this
specification uses the term "variant" to identify such formats. specification uses the term "variant" to identify such formats.
skipping to change at page 5, line 32 skipping to change at page 5, line 33
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: Required parameters:
charset: Per Section 4.2.1 of [RFC6838], charset is REQUIRED. There charset: Per Section 4.2.1 of [RFC6838], charset is REQUIRED. There
is no default value. [MDSYNTAX] clearly describes Markdown as a is no default value because neither [MDSYNTAX] nor many popular
"writing format"; its syntax rules operate on characters implementations at the time of this registration do either.
(specifically, on punctuation) rather than code points. This [MDSYNTAX] clearly describes Markdown as a "writing format"; its
registration does not require or assume any particular character syntax rules operate on characters (specifically, on punctuation)
set because neither [MDSYNTAX] nor many popular implementations rather than code points. Many Markdown processors will get along
at the time of this registration do either. Many Markdown just fine by operating on characters in the US-ASCII repertoire
processors will get along just fine by operating on character (specifically punctuation), blissfully oblivious to other
codes that lie in printable US-ASCII, blissfully oblivious to characters or codes.
coded values outside of that range.
Optional parameters: Optional parameters:
variant: An optional identifier of the specific Markdown variant variant: An optional identifier of the specific Markdown variant
that the author intended. The value serves as a "hint" to the that the author intended. The value serves as a "hint" to the
recipient, meaning that the recipient MAY interpret the Markdown recipient, meaning that the recipient MAY interpret the Markdown
as that variant, but is under no obligation to do so. When as that variant, but is under no obligation to do so. When
omitted, there is no hint; the interpretation is entirely up to omitted, there is no hint; the interpretation is entirely up to
the receiver and context. This identifier is plain US-ASCII and the receiver and context. This identifier is plain US-ASCII and
case-insensitive. To promote interoperability, identifiers can be case-insensitive. To promote interoperability, identifiers can be
skipping to change at page 7, line 29 skipping to change at page 7, line 29
See Section 3. See Section 3.
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): Macintosh file type code(s):
TEXT. A uniform type identifier (UTI) of TEXT. A uniform type identifier (UTI) of
"net.daringfireball.markdown", which conforms to "public.plain- "net.daringfireball.markdown", which conforms to "public.plain-
text", is RECOMMENDED [MDUTI]. See [MDMTUSES] for other text", is RECOMMENDED [MDUTI]. See [MDMTGUID] for other
considerations. considerations.
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? No Provisional registration? No
Implementations SHOULD record the value of the variant parameter (and Implementations SHOULD record the value of the variant parameter (and
other parameters if defined by the variant) along with the Markdown other parameters if defined by the variant) along with the Markdown
content when the content leaves the domain of Internet media type- content when the content leaves the domain of Internet media type-
capable formats. Strategies for doing so are discussed in [MDMTUSES]. capable formats. Strategies for doing so are discussed in [MDMTGUID].
The Content-Disposition header (particularly the preview-type The Content-Disposition header (particularly the preview-type
parameter) can be used with Markdown content. See Section 4. parameter) can be used with Markdown content. See Section 4.
3. Fragment Identifiers 3. Fragment Identifiers
[MARKDOWN] does not define any fragment identifiers, but some [MARKDOWN] does not define any fragment identifiers, but some
variants do, and many types of Markdown processor output (e.g., HTML variants do, and many types of Markdown processor output (e.g., HTML
or PDF) will have well-defined fragment identifiers. Which fragment or PDF) will have well-defined fragment identifiers. Which fragment
identifiers are available for a given document are variant-defined. identifiers are available for a given document are variant-defined.
skipping to change at page 8, line 51 skipping to change at page 8, line 51
4. Content Disposition and preview-type 4. Content Disposition and preview-type
The Content-Disposition header [RFC2183] conveys presentational The Content-Disposition header [RFC2183] conveys presentational
information about a MIME entity, using a type and set of parameters. information about a MIME entity, using a type and set of parameters.
The parameter "preview-type" is defined here for Markdown content. The parameter "preview-type" is defined here for Markdown content.
When present, "preview-type" indicates the Internet media type (and When present, "preview-type" indicates the Internet media type (and
parameters) of the preview output desired from the processor by the parameters) of the preview output desired from the processor by the
author. With reference to the "paradigmatic use case" (i.e., author. With reference to the "paradigmatic use case" (i.e.,
collaborative Markdown editing) in Section 1.3, the output-type collaborative Markdown editing) in Section 1.3, the preview-type
parameter primarily affects the "right-hand" side of a Markdown parameter primarily affects the "right-hand" side of a Markdown
editor. There is no default value: when absent, a Markdown user agent editor. There is no default value: when absent, a Markdown user agent
can render or display whatever it wants. can render or display whatever it wants.
The value of this parameter is an Internet media type with optional The value of this parameter 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, e.g., [RFC2231] and [RFC6532]). updates over time, e.g., [RFC2231] and [RFC6532]).
Implementations SHOULD anticipate and support HTML (text/html) and Implementations SHOULD anticipate and support HTML (text/html) and
skipping to change at page 9, line 24 skipping to change at page 9, line 24
targets those markup languages. These types ought to be suitable for targets those markup languages. These types ought to be suitable for
the majority of current purposes. However, Markdown is increasingly the majority of current purposes. However, Markdown is increasingly
becoming integral to workflows where HTML is not the target output; becoming integral to workflows where HTML is not the target output;
examples range from TeX, to PDF, to OPML, and even to entire e-books examples range from TeX, to PDF, to OPML, and even to entire e-books
(e.g., [PANDOC]). (e.g., [PANDOC]).
The reflexive media type "text/markdown" in this parameter value The reflexive media type "text/markdown" in this parameter value
means that the author does not want to invoke Markdown processing at means that the author does not want to invoke Markdown processing at
all: the receiver SHOULD present the Markdown source as-is. all: the receiver SHOULD present the Markdown source as-is.
The preview-type parameter can be used for other types of content, The "preview-type" parameter can be used for other types of content,
but the precise semantics are not defined here. but the precise semantics are not defined here.
5. Example 5. Example
The following is an example of Markdown as an e-mail attachment: The following is an example of Markdown as an e-mail attachment:
MIME-Version: 1.0 MIME-Version: 1.0
Content-Type: text/markdown; charset=UTF-8; variant=Original Content-Type: text/markdown; charset=UTF-8; variant=Original
Content-Disposition: attachment; filename=readme.md; Content-Disposition: attachment; filename=readme.md;
preview-type="application/xhtml+xml" preview-type="application/xhtml+xml"
skipping to change at page 10, line 24 skipping to change at page 10, line 24
[fOo]: http://example.com/loc 'Will Not Work with Markdown.pl-1.0.1' [fOo]: http://example.com/loc 'Will Not Work with Markdown.pl-1.0.1'
6. IANA Considerations 6. IANA Considerations
IANA is asked to register the media type text/markdown in the IANA is asked to register the media type text/markdown in the
Standards tree using the application provided in Section 2 of this Standards tree using the application provided in Section 2 of this
document. document.
IANA is asked to register "preview-type" in the Content Disposition IANA is asked to register "preview-type" in the Content Disposition
Parameters subregistry of the Content Disposition Values and Parameters subregistry of the Content Disposition Values and
Parameters registry. Parameters registry, with the following description: "Internet media
type (and parameters) of the preview output desired from a processor
by the author of the MIME content".
6.1. Markdown Variants 6.1. Markdown Variants
IANA is also asked to establish a registry called "Markdown IANA is also asked to establish a registry called "Markdown
Variants". While the registry is being created in the context of the Variants". While the registry is being created in the context of the
text/markdown media type, the registry is intended for broad text/markdown media type, the registry is intended for broad
community use, so protocols and systems that do not rely on Internet community use, so protocols and systems that do not rely on Internet
media types can still tag Markdown content with a common variant media types can still tag Markdown content with a common variant
identifier. Each entry in this registry shall consist of basic identifier. Each entry in this registry shall consist of basic
information about the variant: information about the variant:
skipping to change at page 11, line 31 skipping to change at page 11, line 34
filenames. Since the identifier MAY be displayed to a user-- filenames. Since the identifier MAY be displayed to a user--
particularly in cases where the receiver does not recognize the particularly in cases where the receiver does not recognize the
identifier--the identifier SHOULD be rationally related to the identifier--the identifier SHOULD be rationally related to the
vernacular name of the variant. vernacular name of the variant.
The Name, Description, Additional Parameters, Fragment Identifiers, The Name, Description, Additional Parameters, Fragment Identifiers,
References, and Contact Information fields SHALL be in a Unicode References, and Contact Information fields SHALL be in a Unicode
character set (e.g., UTF-8). character set (e.g., UTF-8).
The registry includes the registration in Section 6.1.4 (Original The registry includes the registration in Section 6.1.4 (Original
Markdown). [MDMTUSES] includes additional registrations. Markdown). [MDMTGUID] includes additional registrations.
6.1.1. Reserved Identifiers 6.1.1. Reserved Identifiers
The registry has the following identifiers RESERVED, as they have The registry has the following identifiers RESERVED, as they have
engendered some controversy in the Markdown community. No one is engendered some controversy in the Markdown community. No one is
allowed to register them (or any case variations of them). allowed to register them (or any case variations of them). These
identifiers are not and cannot be registered:
Standard Standard
Common Common
Markdown Markdown
The registry includes the following text in the note field:
The variant names Standard, Common, and Markdown are reserved and
cannot be registered.
6.1.2. Standard of Review 6.1.2. Standard of Review
Registrations are made on a First-Come, First-Served [RFC5226] basis Registrations are made on a First-Come, First-Served [RFC5226] basis
by anyone with a need to interoperate. While documentation is by anyone with a need to interoperate. While documentation is
required, any level of documentation is sufficient; thus, neither required, any level of documentation is sufficient; thus, neither
Specification Required nor Expert Review are warranted. The checks 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.
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.
skipping to change at page 14, line 5 skipping to change at page 14, line 14
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
Email Headers", RFC 6532, February 2012. Email Headers", RFC 6532, February 2012.
[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.
8.2. Informative References 8.2. Informative References
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version
8.0.0", The Unicode Consortium, August 2015.
[ISO646] International Organization for Standardization,
"Information technology - ISO 7-bit coded character set
for information interchange", ISO Standard 646, 1991.
[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/>.
[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>.
[MDMTUSES] Leonard, S., "text/markdown Use Cases", draft-ietf- [MDMTGUID] Leonard, S., "Guidance on Markdown: Design Philosophies,
appsawg-text-markdown-use-cases-01 (work in progress), Stability Strategies, and Select Registrations", draft-
February 2015. ietf-appsawg-text-markdown-use-cases-03 (work in
progress), August 2015.
[PANDOC] MacFarlane, J., "Pandoc", 2014, [PANDOC] MacFarlane, J., "Pandoc", 2014,
<http://johnmacfarlane.net/pandoc/>. <http://johnmacfarlane.net/pandoc/>.
[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.
Appendix A. Change Log
This draft is a continuation from draft-ietf-appsawg-text-markdown-
06.txt. These technical changes were made:
1. Defined the IANA email confirmation process.
2. Defined the fields for the variants registry.
3. Referred to use-cases draft.
4. Beefed up the encoding considerations.
5. Referred to the right section (Section 3) in fragment
identifier considerations.
6. Added Original Markdown registration.
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
EMail: dev+ietf@seantek.com EMail: dev+ietf@seantek.com
 End of changes. 19 change blocks. 
75 lines changed or deleted 79 lines changed or added

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