draft-ietf-appsawg-text-markdown-04.txt   draft-ietf-appsawg-text-markdown-05.txt 
Applications Area Working Group S. Leonard Applications Area Working Group S. Leonard
Internet-Draft Penango, Inc. Internet-Draft Penango, Inc.
Intended Status: Informational December 16, 2014 Intended Status: Informational December 22, 2014
Expires: June 19, 2015 Expires: June 25, 2015
The text/markdown Media Type The text/markdown Media Type
draft-ietf-appsawg-text-markdown-04 draft-ietf-appsawg-text-markdown-05
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 12 skipping to change at page 2, line 12
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. This Is Markdown! Or: Markup and Its Discontents . . . . . 2 1.1. This Is Markdown! Or: Markup and Its Discontents . . . . . 2
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. Optional Parameters . . . . . . . . . . . . . . . . . . . . . 7 3. Fragment Identifiers . . . . . . . . . . . . . . . . . . . . . 7
4. Fragment Identifiers . . . . . . . . . . . . . . . . . . . . . 7 3.1. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. General-Purpose Fragment Identifiers . . . . . . . . . . . 8 4. Content Disposition and preview-type . . . . . . . . . . . . . 8
4.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6.1. Markdown Variants . . . . . . . . . . . . . . . . . . . . . 10 6.1. Markdown Variants . . . . . . . . . . . . . . . . . . . . . 10
6.2. Reserved Identifiers . . . . . . . . . . . . . . . . . . . 10 6.2. Reserved Identifiers . . . . . . . . . . . . . . . . . . . 11
6.3. Standard of Review . . . . . . . . . . . . . . . . . . . . 11 6.3. Standard of Review . . . . . . . . . . . . . . . . . . . . 11
6.4. Provisional Registration . . . . . . . . . . . . . . . . . 11 6.4. Provisional Registration . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13
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: a linear
sequence of characters in some character set (code), possibly sequence of characters in some character set (code), possibly
skipping to change at page 5, line 36 skipping to change at page 5, line 35
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. [MDSYNTAX] clearly describes Markdown as a
writing format; its syntax rules operate on characters writing format; its syntax rules operate on characters
(specifically, on punctuation) rather than code points. Neither (specifically, on punctuation) rather than code points. Neither
[MDSYNTAX] nor many popular implementations at the time of this [MDSYNTAX] nor many popular implementations at the time of this
registration actually require or assume any particular encoding. registration actually require or assume any particular character
Many Markdown processors will get along just fine by operating on set. Many Markdown processors will get along just fine by
character codes that lie in printable US-ASCII, blissfully operating on character codes that lie in printable US-ASCII,
oblivious to coded values outside of that range. blissfully oblivious to coded values outside of that range.
Optional parameters: Optional parameters:
variant: An optional identifier that serves as a "hint" to the variant: An optional identifier that serves as a "hint" to the
recipient of the specific Markdown variant that the author recipient of the specific Markdown variant that the author
intended. When omitted, there is no hint; the interpretation is intended. When omitted, there is no hint; the interpretation is
entirely up to the receiver and context. This identifier is plain entirely up to the receiver and context. This identifier is plain
US-ASCII and case-insensitive. To promote interoperability, US-ASCII and case-insensitive. To promote interoperability,
identifiers MAY be registered in the registry defined in Section identifiers MAY be registered in the registry defined in Section
6. If a receiver does not recognize the variant identifier, the 6. If a receiver does not recognize the variant identifier, the
skipping to change at page 6, line 35 skipping to change at page 6, line 35
redirect the user to other webpages, download remote content, and redirect the user to other webpages, download remote content, and
upload personally identifiable information. Markdown also can upload personally identifiable information. Markdown also can
contain islands of formal markup, such as HTML. These islands of contain islands of formal markup, such as HTML. These islands of
formal 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 processed. Since Markdown may have different Markdown is processed. Since Markdown may have different
interpretations depending on the tool and the environment, a better interpretations depending on the tool and the environment, a better
approach is to analyze (and sanitize or block) the output markup, approach is to analyze (and sanitize or block) the output markup,
rather than attempting to analyze the Markdown. rather than attempting to analyze the Markdown.
Security provides a significant motivator for the output-type
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 syntaxes are designed to be broadly compatible with humans Markdown variations (some might say "innovations") are designed to
("humane"), but not necessarily with each other. Therefore, syntax be broadly compatible with humans ("humane"), but not necessarily
in one Markdown derivative may be ignored or treated differently in with each other. Therefore, syntax in one Markdown derivative may
another derivative. The overall effect is a general degradation of be ignored or treated differently in another derivative. The
the output, proportional to the quantity of syntax-specific overall effect is a general degradation of the output, proportional
Markdown used in the text. When it is desirable to reflect the to the quantity of variant-specific Markdown used in the text. When
author's intent in the output, stick with the syntax identified in it is desirable to reflect the author's intent in the output, stick
the syntax parameter. with the variant identified in the variant parameter.
Published specification: This specification; [MDSYNTAX]. 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; markup processor targets 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: Fragment identifier considerations:
See Section 4. See 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): 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]. Additionally, implementations text", is RECOMMENDED [MDUTI]. See [MDMTUSES] for other
SHOULD record syntax and output-type parameters along with the considerations.
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? No Provisional registration? No
3. Optional Parameters Implementations SHOULD record the value of the variant parameter (and
other parameters if defined by the variant) along with the Markdown
[[NB: OMITTED from this draft. This section may be replaced with content when the content leaves the domain of Internet media type-
Content-Disposition: ... preview-type=...]] capable formats. Strategies for doing so are discussed in [MDMTUSES].
4. Fragment Identifiers
Many types of content (such as HTML or PDF) that is output from a The Content-Disposition header (particulalry the preview-type
Markdown processor will have well-defined fragment identifier parameter) can be used with Markdown content. See Section 4.
semantics associated with the content (such as named anchors or page
numbers, respectively). However, the original [MDSYNTAX] neither
defines a syntax for naming such content parts, nor associates such
parts with fragment identifiers. Several variants have since defined
such content parts, making them suitable for use with fragment
identifiers.
4.1. General-Purpose Fragment Identifiers 3. Fragment Identifiers
A Markdown fragment identifier is a sequence of characters that [MARKDOWN] does not define any fragment identifiers, but some
identifies some area of the Markdown content. Each Markdown variant variants do, and many types of Markdown processor output (e.g., HTML
can formally define a syntax for such fragment identifiers. (In or PDF) will have well-defined fragment identifiers. Which fragment
practice, identifiers that are similar to HTML's anchors are used by identifiers are available for a given document are variant-defined.
many variants, usually by surrounding the identifier with "{#" and
"}" and placing the production at the end of a line that comprises
particular kinds of content, such as a header, table, or image.)
[[NB: citation necessary to PHP Markdown Extra as an exemplary
syntax?]]
When encoded in a URI, the production SHALL conform to the fragment When encoded in a URI, characters that are outside of the fragment
production of [RFC3986] (specifically: pchar, "/", and "?" production of [RFC3986] are percent-encoded. The default encoding
characters). Characters that are outside of that production SHALL be (character set) of percent-encoded octets in URIs is the same as the
percent-encoded. The character set for percent-encoded octets SHALL Markdown content, which is identified by the charset parameter or by
be the same as the Markdown content, i.e., identified by the charset other contextual means. Fragment identifiers SHOULD be considered
parameter or by other contextual means. Variants are free to specify case-sensitive, which maintains consistency with HTML. Variants MAY
how fragment identifiers are compared. In the absence of a variant- override the guidance in this paragraph. [[NB: citation necessary to
specific rule, fragment identifiers SHOULD be considered case- HTML4/HTML5?]]
sensitive, which maintains consistency with HTML. [[NB: citation
necessary to HTML4/HTML5?]]
At least the first equals sign "=" SHOULD be percent-encoded to At least the first equals sign "=" SHOULD be percent-encoded to
prevent ambiguity as described in the following section. prevent ambiguity as described in the following section.
4.2. Parameters 3.1. Parameters
Similar to application/pdf [RFC3778] and text/plain [RFC5147], this Similar to application/pdf [RFC3778] and text/plain [RFC5147], this
registration permits a parameter syntax for fragment identifiers. The registration permits a parameter syntax for fragment identifiers. The
syntax is a parameter name, the equals sign "=" (which MUST NOT be syntax is a parameter name, the equals sign "=" (which MUST NOT be
percent-encoded), and a parameter value. To the extent that multiple percent-encoded), and a parameter value. To the extent that multiple
parameters can appear in a fragment production, the parameters SHALL parameters can appear in a fragment production, the parameters SHALL
be separated by the ampersand "&" (which MUST NOT be percent- be separated by the ampersand "&" (which MUST NOT be percent-
encoded). encoded).
The only parameter defined in this registration is "line", which has The only parameter defined in this registration is "line", which has
skipping to change at page 9, line 13 skipping to change at page 8, line 37
Markdown variants are free to define additional parameters. Markdown variants are free to define additional parameters.
[[NB: This draft does not import all of text/plain's fragment [[NB: This draft does not import all of text/plain's fragment
identifier schemes, mainly because the utility of the other schemes identifier schemes, mainly because the utility of the other schemes
is far from obvious. Implementing line= is not difficult but char= is is far from obvious. Implementing line= is not difficult but char= is
more difficult since "character" has various meanings that will skew more difficult since "character" has various meanings that will skew
the numbering significantly as the content grows in length; the other the numbering significantly as the content grows in length; the other
integrity check things simply do not seem to be particularly integrity check things simply do not seem to be particularly
useful.]] useful.]]
4. Content Disposition and preview-type
The Content-Disposition header [RFC2183] conveys presentational
information about a MIME entity, using a type and set of parameters.
The parameter "preview-type" is defined here for Markdown content.
When present, "preview-type" indicates the Internet media type (and
parameters) of the preview output desired from the processor by the
author. With reference to the "paradigmatic use case" (i.e.,
collaborative Markdown editing) in Section 1.3, the output-type
parameter primarily affects the "right-hand" side of a Markdown
editor. There is no default value: when absent, a Markdown user agent
can render or display whatever it wants.
The value of this parameter is an Internet media type with optional
parameters. The syntax (including case sensitivity considerations) is
the same as specified in [RFC2045] for the Content-Type header (with
updates over time, e.g., [RFC2231] and [RFC6532]).
Implementations SHOULD anticipate and support HTML (text/html) and
XHTML (application/xhtml+xml) output, to the extent that a syntax
targets those markup languages. These types ought to be suitable for
the majority of current purposes. However, Markdown is increasingly
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
(e.g., [PANDOC]).
The reflexive media type "text/markdown" in this parameter value
means that the author does not want to invoke Markdown processing at
all: the receiver SHOULD present the Markdown source as-is.
The preview-type parameter can be used for other types of content,
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; syntax=Original; Content-Type: text/markdown; charset=UTF-8; variant=Original
output-type="application/xhtml+xml" Content-Disposition: attachment; filename=readme.md;
Content-Disposition: attachment; filename=readme.md preview-type="application/xhtml+xml"
Sample HTML 4 Markdown Sample HTML 4 Markdown
============= =============
This is some sample Markdown. [Hooray!][foo] This is some sample Markdown. [Hooray!][foo]
(Remember that link identifiers are not case-sensitive.) (Remember that link identifiers are not case-sensitive.)
Bulleted Lists Bulleted Lists
------- -------
skipping to change at page 10, line 6 skipping to change at page 10, line 17
has more information. has more information.
[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
Parameters subregistry of the Content Disposition Values and
Parameters registry.
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:
Identifier Identifier
Name Name
Description Description
Additional Parameters (optional)
Fragment Identifiers (optional)
References References
Contact Information Contact Information
Expiration Date (if provisional) Expiration Date (if provisional)
Variants that have additional media type parameters or fragment
identifier considerations SHOULD describe them in detail in the
Description field.
While the variant parameter is "plain US-ASCII" (see registration While the variant parameter is "plain US-ASCII" (see registration
template), the Identifier field (and by implication, all registered template), the Identifier field (and by implication, all registered
identifiers) SHALL conform to the ABNF: identifiers) SHALL conform to the ABNF:
ALPHA [*(ALPHA / DIGIT / "-" / "." / "_" / "~") (ALPHA / DIGIT)] ALPHA [*(%d33-126) (ALPHA / DIGIT)]
[[NB: Be less restrictive, maybe reuse some other common ABNF]]
For style and compatibility reasons, the Identifier field SHOULD
conform to the ABNF:
ALPHA 1*( ["-" / "." / "_" / "~"] 1*(ALPHA / DIGIT) )
I.e., the identifier MUST start with a letter and MAY contain I.e., the identifier MUST start with a letter and MAY contain
punctuation in the middle, but not at the end: the last character punctuation in the middle, but not at the end: the last character
MUST be alphanumeric. Since the identifier MAY be displayed to a MUST be alphanumeric. The second production uses the same characters
user--particularly in cases where the receiver does not recognize the as the "unreserved" rule of [RFC3986], and is designed to be
compatible with characters in other identification systems, e.g.,
filenames. Since the identifier MAY be displayed to a user--
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, References, and Contact Information fields The Name, Description, Additional Parameters, Fragment Identifiers,
SHALL be in a Unicode character set (e.g., UTF-8). References, and Contact Information fields SHALL be in a Unicode
character set (e.g., UTF-8).
6.2. Reserved Identifiers 6.2. Reserved Identifiers
The registry SHALL have the following identifiers RESERVED. No one is The registry SHALL have the following identifiers RESERVED. No one is
allowed to register them (or any case variations of them). allowed to register them (or any case variations of them).
Standard Standard
Common Common
Markdown Markdown
6.3. Standard of Review 6.3. Standard of Review
skipping to change at page 11, line 34 skipping to change at page 12, line 6
handled by listing the IETF as the contact organization, right?).]] handled by listing the IETF as the contact organization, right?).]]
All fields may be updated except the variant identifier, which is All fields may be updated except the variant identifier, which is
permanent: not even case may be changed. permanent: not even case may be changed.
6.4. Provisional Registration 6.4. Provisional Registration
Any registrant may make a provisional registration to reserve a Any registrant may make a provisional registration to reserve a
variant identifier. Only the variant identifier and contact variant identifier. Only the variant identifier and contact
information fields are required; the rest are optional. Provisional information fields are required; the rest are optional. Provisional
registrations expire after three months, after which time the variant registrations expire after three months, after which time the variant
identifier may be reused. identifier may be reused. To make a registration permanent, a
registrant simply needs to complete a permanent registration with the
same identifier as the provisional registration.
7. Security Considerations 7. Security Considerations
See the Security considerations entry in Section 2. See the Security considerations entry in Section 2.
8. References 8. References
8.1. Normative References 8.1. Normative References
[MARKDOWN] Gruber, J., "Daring Fireball: Markdown", December 2004, [MARKDOWN] Gruber, J., "Daring Fireball: Markdown", December 2004,
skipping to change at page 12, line 14 skipping to change at page 12, line 37
<http://daringfireball.net/linked/2011/08/05/markdown- <http://daringfireball.net/linked/2011/08/05/markdown-
uti>. 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.
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions: Character Sets, Languages, and
Continuations", RFC 2231, November 1997.
[RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media [RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media
Type", RFC 2854, June 2000. Type", RFC 2854, June 2000.
[RFC3778] Taft, E., Pravetz, J., Zilles, S., and L. Masinter, "The [RFC3778] Taft, E., Pravetz, J., Zilles, S., and L. Masinter, "The
application/pdf Media Type", RFC 3778, May 2004. 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 [RFC5147] Wilde, E. and M. Duerst, "URI Fragment Identifiers for the
text/plain Media Type", RFC 5147, April 2008. 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.
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
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
[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/>.
skipping to change at page 13, line 8 skipping to change at page 13, line 37
<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-seantek- [MDMTUSES] Leonard, S., "text/markdown Use Cases", draft-seantek-
text-markdown-use-cases-00 (work in progress), October text-markdown-use-cases-00 (work in progress), October
2014. 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,
<http://railfrog.com/>.
[RFC1468] Murai, J., Crispin, M., and E. van der Poel, "Japanese
Character Encoding for Internet Messages", RFC 1468, June
1993.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
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.
[FOUNTAIN] Maschwitz, S. and J. August, "Fountain | A markup language
for screenwriting.", 2014, <http://fountain.io/>.
[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-
03.txt. These technical changes were made: 04.txt. These technical changes were made:
1. Removed output-type optional parameter. 1. Added preview-type Content Disposition parameter.
2. Renamed syntax optional parameter to variant. 2. Updated example.
3. Defined variant optional parameter as discussed on mailing 3. Fleshed out more of the registration procedures.
list. 4. Simplified the text of the fragment identifiers.
4. Removed Section 3 (which may be replaced with Content- 5. Removed vestiges of the old syntax and output-type parameters.
Disposition/preview-type in the future).
5. Redid the fragment identifier considerations, simplifying the
specification considerably.
6. Discussed the meaning of "variant" in the context of Markdown. 6. Discussed the meaning of "variant" in the context of Markdown.
7. Redefined the IANA registry as "Markdown Variants" and
expanded its applicability outside of this particular media
type.
8. Drastically simplified the registration template.
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. 32 change blocks. 
119 lines changed or deleted 119 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/