idnits 2.17.1
draft-ietf-appsawg-text-markdown-12.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (October 17, 2015) is 3107 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
** Obsolete normative reference: RFC 3778 (Obsoleted by RFC 8118)
** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126)
Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Applications Area Working Group S. Leonard
3 Internet-Draft Penango, Inc.
4 Intended Status: Informational October 17, 2015
5 Expires: April 19, 2016
7 The text/markdown Media Type
8 draft-ietf-appsawg-text-markdown-12
10 Abstract
12 This document registers the text/markdown media type for use with
13 Markdown, a family of plain text formatting syntaxes that optionally
14 can be converted to formal markup languages such as HTML.
16 Status of this Memo
18 This Internet-Draft is submitted in full conformance with the
19 provisions of BCP 78 and BCP 79.
21 Internet-Drafts are working documents of the Internet Engineering
22 Task Force (IETF). Note that other groups may also distribute
23 working documents as Internet-Drafts. The list of current Internet-
24 Drafts is at http://datatracker.ietf.org/drafts/current/.
26 Internet-Drafts are draft documents valid for a maximum of six months
27 and may be updated, replaced, or obsoleted by other documents at any
28 time. It is inappropriate to use Internet-Drafts as reference
29 material or to cite them other than as "work in progress."
31 Copyright Notice
33 Copyright (c) 2015 IETF Trust and the persons identified as the
34 document authors. All rights reserved.
36 This document is subject to BCP 78 and the IETF Trust's Legal
37 Provisions Relating to IETF Documents
38 (http://trustee.ietf.org/license-info) in effect on the date of
39 publication of this document. Please review these documents
40 carefully, as they describe your rights and restrictions with respect
41 to this document. Code Components extracted from this document must
42 include Simplified BSD License text as described in Section 4.e of
43 the Trust Legal Provisions and are provided without warranty as
44 described in the Simplified BSD License.
46 Table of Contents
48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
49 1.1. This Is Markdown! Or: Markup and Its Discontents . . . . . 2
50 1.2. Markdown Is About Writing and Editing . . . . . . . . . . . 3
51 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 5
52 2. Markdown Media Type Registration Application . . . . . . . . . 5
53 3. Fragment Identifiers . . . . . . . . . . . . . . . . . . . . . 8
54 3.1. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 8
55 4. Content Disposition and preview-type . . . . . . . . . . . . . 8
56 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
58 6.1. Markdown Variants . . . . . . . . . . . . . . . . . . . . . 10
59 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 12
60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
61 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
62 8.2. Informative References . . . . . . . . . . . . . . . . . . 14
63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
65 1. Introduction
67 1.1. This Is Markdown! Or: Markup and Its Discontents
69 In computer systems, textual data is stored and processed using a
70 continuum of techniques. On the one end is plain text: computer-
71 encoded text that consists only of a sequence of code points from a
72 given standard, with no other formatting or structural information
73 [UNICODE]. (On the other end is binary data, which computer systems
74 store and process with bit-for-bit accuracy.) Many of these standards
75 include control characters that are used as in-band signaling to
76 cause effects other than the addition of a symbol (or grapheme) to
77 the text.
79 Markup offers an alternative means to encode this signaling
80 information by overloading certain graphic characters (see, e.g.,
81 [ISO646]) with additional meanings. Therefore, markup languages allow
82 for annotating a document in a syntactically distinguishable way from
83 the text, while keeping the annotations printable. Markup languages
84 are (reasonably) well-specified and tend to follow (mostly)
85 standardized syntax rules. Examples of formal markup languages
86 include SGML, HTML, XML, and LaTeX. Standardized rules lead to
87 interoperability between markup processors, but impose skill
88 requirements on new users that lead to markup languages becoming less
89 accessible to beginners. These rules also reify "validity": content
90 that does not conform to the rules is treated differently (i.e., is
91 rejected) than content that conforms.
93 In contrast to formal markup languages, lightweight markup languages
94 use simple syntaxes; they are designed to be easy for humans to enter
95 and understand with basic text editors. Markdown, the subject of this
96 document, began as an /informal/ plain text formatting syntax
97 [MDSYNTAX] and Perl script HTML/XHTML processor [MARKDOWN] targeted
98 at non-technical users using unspecialized tools, such as plain text
99 e-mail clients. [MDSYNTAX] explicitly rejects the notion of validity:
100 there is no such thing as "invalid" Markdown. If the Markdown content
101 does not result in the "right" output (defined as output that the
102 author wants, not output that adheres to some dictated system of
103 rules), the expectation is that the author should continue
104 experimenting by changing the content or the processor to achieve the
105 desired output.
107 Since its development in 2004 [MARKDOWN], a number of web- and
108 Internet-facing applications have incorporated Markdown into their
109 text entry systems, frequently with custom extensions. Markdown has
110 thus evolved into a kind of Internet meme [INETMEME] as different
111 communities encounter it and adapt the syntax for their specific use
112 cases. Markdown now represents a family of related plain text
113 formatting syntaxes and implementations that, while broadly
114 compatible with humans [HUMANE], are intended to produce different
115 kinds of outputs that push the boundaries of mutual intelligibility
116 between software systems.
118 To support identifying and conveying Markdown, this document defines
119 a media type and parameters that indicate the Markdown author's
120 intent on how to interpret the content. This registration draws
121 particular inspiration from text/troff [RFC4263], which is a plain
122 text formatting syntax for typesetting based on tools from the 1960s
123 ("RUNOFF") and 1970s ("nroff", et. al.). In that sense, Markdown is a
124 kind of troff for modern computing. A companion document [MDMTGUID]
125 provides additional Markdown background, philosophy, local storage
126 strategies, and variant registrations (including examples).
128 1.2. Markdown Is About Writing and Editing
130 "HTML is a *publishing* format; Markdown is a *writing* format.
131 Thus, Markdown's formatting syntax only addresses issues
132 that can be conveyed in plain text." [MDSYNTAX]
134 The paradigmatic use case for text/markdown is the Markdown editor:
135 an application that presents Markdown content (which looks like an e-
136 mail or other piece of plain text writing) alongside a published
137 format, so that an author can see results instantaneously and can
138 tweak his or her input in real-time. A significant number of Markdown
139 editors have adopted "split-screen view" (or "live preview")
140 technology that looks like Figure 1:
142 +----------------------------------------------------------------------+
143 | File Edit (Cloud Stuff) (Fork Me on GitHub) Help |
144 +----------------------------------------------------------------------+
145 | [ such-and-such identifier ] [ useful statistics] |
146 +----------------------------------++----------------------------------+
147 | (plain text, with || (text/html, likely |
148 | syntax highlighting) || rendered to screen) |
149 | || |
150 |# Introduction ||
Introduction
|
151 | || |
152 |## Markdown Is About Writing and /|Markdown Is About Writing and |
153 / Editing ||Editing
|
154 | || |
155 |> HTML is a *publishing* format; ||HTML is a |
156 |> Markdown is a *writing* format. || publishing format; |
157 |> Thus, Markdown's formatting || Markdown is a writing |
158 |> syntax only addresses issues || format. Thus, Markdown's |
159 |> that can be conveyed in plain <> formatting syntax only addresses |
160 |> text. [MDSYNTAX][] || issues that can be conveyed in |
161 | || plain text. MDSYNTAX |
165 |presents Markdown content ||
|
166 |... || |
167 | ||The paradigmatic use case for |
168 |[MDSYNTAX]: http://daringfireball./| text/markdown
is the|
169 /net/projects/markdown/syntax#html || Markdown editor: an application |
170 |"Markdown: Syntax: HTML" || that presents Markdown content |
171 | || ...
|
172 +----------------------------------++----------------------------------+
174 LEGEND: "/" embedded in a vertical line represents a line-continuation
175 marker, since a line break is not supposed to occur in that content.
177 Figure 1: Markdown Split-Screen/Live Preview Editor
179 To get the best results, implementations ought to produce and consume
180 mutually intelligible and identifiable bits of Markdown. That way, users
181 on diverse platforms can collaborate with their tools of choice. Those
182 tools can be desktop-based (MarkdownPad, MultiMarkdown Composer),
183 browser-based (Dillinger, Markable), integrated widgets (Discourse,
184 GitHub), general-purpose editors (emacs, vi), or plain old "Notepad".
185 Additionally, implementations ought to have common ways to identify
186 particular areas of Markdown content when the Markdown becomes
187 appreciably large (e.g., book chapters and Internet-Drafts--not just
188 blog posts). So that users have the option to use Markdown in MIME-
189 capable systems to convey their works in progress, not just their
190 finished products (for which full-blown markups ranging from text/html
191 to application/pdf are appropriate), implementations ought to label such
192 Markdown content with a common media type: text/markdown. This
193 registration facilitates interoperability between these Markdown editors
194 by conveying the syntax of the particular Markdown variant and the
195 desired output format.
197 1.3. Definitions
199 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
200 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
201 document are to be interpreted as described in [RFC2119].
203 Since Markdown signifies a family of related formats with varying
204 degrees of formal documentation and implementation, this
205 specification uses the term "variant" to identify such formats.
207 2. Markdown Media Type Registration Application
209 This section provides the media type registration application for the
210 text/markdown media type (see [RFC6838], Section 5.6).
212 Type name: text
214 Subtype name: markdown
216 Required parameters:
218 charset: Per Section 4.2.1 of [RFC6838], charset is REQUIRED. There
219 is no default value because neither [MDSYNTAX] nor many popular
220 implementations at the time of this registration do either.
221 [MDSYNTAX] clearly describes Markdown as a "writing format"; its
222 syntax rules operate on characters (specifically, on punctuation)
223 rather than code points. Many Markdown processors will get along
224 just fine by operating on characters in the US-ASCII repertoire
225 (specifically punctuation), blissfully oblivious to other
226 characters or codes.
228 Optional parameters:
230 variant: An optional identifier of the specific Markdown variant
231 that the author intended. The value serves as a "hint" to the
232 recipient, meaning that the recipient MAY interpret the Markdown
233 as that variant, but is under no obligation to do so. When
234 omitted, there is no hint; the interpretation is entirely up to
235 the receiver and context. This identifier is plain US-ASCII and
236 case-insensitive. To promote interoperability, identifiers can be
237 registered in the registry defined in Section 6. If a receiver
238 does not recognize the variant identifier, the receiver MAY
239 present the identifier to a user to inform him or her of it.
241 Other parameters MAY be included with the media type. The variant
242 SHOULD define the semantics of such other parameters. Additionally,
243 the variant MAY be registered under another media type; this
244 text/markdown registration does not preclude other registrations.
246 Encoding considerations:
248 Markdown content is plain text content; any octet sequence is valid
249 as long as it conforms to the character codes of the charset
250 parameter. See [RFC2046]. Markup characters in [MDSYNTAX] are
251 limited to printable US-ASCII; however, other variants can define
252 markup characters outside this range (including control characters
253 such as NUL and characters encoded in multiple octets).
255 Security considerations:
257 Markdown interpreted as plain text is relatively harmless. A text
258 editor need only display the text. The editor SHOULD take care to
259 handle control characters appropriately, and to limit the effect of
260 the Markdown to the text editing area itself; malicious Unicode-
261 based Markdown could, for example, surreptitiously change the
262 directionality of the text. An editor for normal text would already
263 take these control characters into consideration, however.
265 Markdown interpreted as a precursor to other formats, such as HTML,
266 carries all of the security considerations as the target formats.
267 For example, HTML can contain instructions to execute scripts,
268 redirect the user to other webpages, download remote content, and
269 upload personally identifiable information. Markdown also can
270 contain islands of formal markup, such as HTML. These islands of
271 formal markup may be passed as-is, transformed, or ignored (perhaps
272 because the islands are conditional or incompatible) when the
273 Markdown is processed. Since Markdown may have different
274 interpretations depending on the tool and the environment, a better
275 approach is to analyze (and sanitize or block) the output markup,
276 rather than attempting to analyze the Markdown.
278 Interoperability considerations:
280 Markdown variations (some might say "innovations") are designed to
281 be broadly compatible with humans ("humane"), but not necessarily
282 with each other. Therefore, syntax in one Markdown derivative may
283 be ignored or treated differently in another derivative. The
284 overall effect is a general degradation of the output that
285 increases with the quantity of variant-specific Markdown used in
286 the text. When it is desirable to reflect the author's intent in
287 the output, stick with the variant identified in the variant
288 parameter, i.e., receivers SHOULD only accept Markdown variants
289 that they explicitly know about, and senders SHOULD avoid use of
290 variants that intended recipients are not known to understand.
292 Published specification: This specification; [MDSYNTAX].
294 Applications that use this media type:
296 Markdown conversion tools, Markdown WYSIWYG editors, and plain text
297 editors and viewers; markup processor targets indirectly use
298 Markdown (e.g., web browsers for Markdown converted to HTML).
300 Fragment identifier considerations:
302 See Section 3.
304 Additional information:
306 Magic number(s): None
307 File extension(s): .md, .markdown
308 Macintosh file type code(s):
309 TEXT. A uniform type identifier (UTI) of
310 "net.daringfireball.markdown", which conforms to "public.plain-
311 text", is RECOMMENDED [MDUTI]. See [MDMTGUID] for other
312 considerations.
314 Person & email address to contact for further information:
316 Sean Leonard
318 Restrictions on usage: None.
320 Author/Change controller: Sean Leonard
322 Intended usage: COMMON
324 Provisional registration? No
326 Implementations SHOULD record the value of the variant parameter (and
327 other parameters if defined by the variant) along with the Markdown
328 content when the content leaves the domain of Internet media type-
329 capable formats. Strategies for doing so are discussed in [MDMTGUID].
331 The Content-Disposition header (particularly the preview-type
332 parameter) can be used with Markdown content. See Section 4.
334 3. Fragment Identifiers
336 [MARKDOWN] does not define any fragment identifiers, but some
337 variants do, and many types of Markdown processor output (e.g., HTML
338 or PDF) will have well-defined fragment identifiers. Which fragment
339 identifiers are available for a given document are variant-defined.
341 When encoded in a URI, characters that are outside of the fragment
342 production of [RFC3986] are percent-encoded. The default encoding
343 (character set) of percent-encoded octets in URIs is the same as the
344 Markdown content, which is identified by the charset parameter or by
345 other contextual means. Fragment identifiers SHOULD be considered
346 case-sensitive, which maintains consistency with HTML. Variants MAY
347 override the guidance in this paragraph.
349 At least the first equals sign "=" SHOULD be percent-encoded to
350 prevent ambiguity as described in the following section.
352 3.1. Parameters
354 Similar to application/pdf [RFC3778] and text/plain [RFC5147], this
355 registration permits a parameter syntax for fragment identifiers. The
356 syntax is a parameter name, the equals sign "=" (which MUST NOT be
357 percent-encoded), and a parameter value. To the extent that multiple
358 parameters can appear in a fragment production, the parameters SHALL
359 be separated by the ampersand "&" (which MUST NOT be percent-
360 encoded).
362 The only parameter defined in this registration is "line", which has
363 the same meaning as [RFC5147] (i.e., counting is zero-based). For
364 example: "#line=10" identifies the eleventh line of Markdown input.
365 Implementers should take heed that different environments and
366 character sets may have a wide range of code sequences to divide
367 lines.
369 Markdown variants are free to define additional parameters.
371 4. Content Disposition and preview-type
373 The Content-Disposition header [RFC2183] conveys presentational
374 information about a MIME entity, using a type and set of parameters.
375 The parameter "preview-type" is defined here for Markdown content.
377 When present, "preview-type" indicates the Internet media type (and
378 parameters) of the preview output desired from the processor by the
379 author. With reference to the "paradigmatic use case" (i.e.,
380 collaborative Markdown editing) in Section 1.3, the preview-type
381 parameter primarily affects the "right-hand" side of a Markdown
382 editor. There is no default value: when absent, a Markdown user agent
383 can render or display whatever it wants.
385 The value of this parameter is an Internet media type with optional
386 parameters. The syntax (including case sensitivity considerations) is
387 the same as specified in [RFC2045] for the Content-Type header (with
388 updates over time, e.g., [RFC2231] and [RFC6532]).
390 Implementations SHOULD anticipate and support HTML (text/html) and
391 XHTML (application/xhtml+xml) output, to the extent that a syntax
392 targets those markup languages. These types ought to be suitable for
393 the majority of current purposes. However, Markdown is increasingly
394 becoming integral to workflows where HTML is not the target output;
395 examples range from TeX, to PDF, to OPML, and even to entire e-books
396 (e.g., [PANDOC]).
398 The reflexive media type "text/markdown" in this parameter value
399 means that the author does not want to invoke Markdown processing at
400 all: the receiver SHOULD present the Markdown source as-is.
402 The "preview-type" parameter can be used for other types of content,
403 but the precise semantics are not defined here.
405 5. Example
407 The following is an example of Markdown as an e-mail attachment:
409 MIME-Version: 1.0
410 Content-Type: text/markdown; charset=UTF-8; variant=Original
411 Content-Disposition: attachment; filename=readme.md;
412 preview-type="application/xhtml+xml"
414 Sample HTML 4 Markdown
415 =============
417 This is some sample Markdown. [Hooray!][foo]
418 (Remember that link identifiers are not case-sensitive.)
420 Bulleted Lists
421 -------
423 Here are some bulleted lists...
425 * One Potato
426 * Two Potato
427 * Three Potato
428 - One Tomato
429 - Two Tomato
430 - Three Tomato
432 More Information
433 -----------
435 [.markdown, .md](http://daringfireball.net/projects/markdown/)
436 has more information.
438 [fOo]: http://example.com/loc 'Will Not Work with Markdown.pl-1.0.1'
440 6. IANA Considerations
442 IANA is asked to register the media type text/markdown using the
443 application provided in Section 2 of this document.
445 IANA is asked to register "preview-type" in the Content Disposition
446 Parameters subregistry of the Content Disposition Values and
447 Parameters registry, with the following description: "Internet media
448 type (and parameters) of the preview output desired from a processor
449 by the author of the MIME content".
451 6.1. Markdown Variants
453 IANA is also asked to establish a registry called "Markdown
454 Variants". While the registry is being created in the context of the
455 text/markdown media type, the registry is intended for broad
456 community use, so protocols and systems that do not rely on Internet
457 media types can still tag Markdown content with a common variant
458 identifier. Each entry in this registry shall consist of basic
459 information about the variant:
461 Identifier: unique identifier for the variant
462 Name: the commonly known name of the variant
463 Description: a prose description of the variant,
464 including how it differs from other
465 variants such as Original
466 Additional Parameters*: additional Content-Type parameters
467 Fragment Identifiers*: additional fragment identifier
468 syntaxes and semantics
469 References: URIs or other references to documentation
470 Contact Information: whom to contact (email, URI, phone,
471 address, etc.)
472 Expiration Date^: when this provisional
473 registration expires
475 * (optional)
476 ^ (if provisional)
478 While the variant parameter is "plain US-ASCII" (see registration
479 template), the Identifier field (and by implication, all registered
480 identifiers) SHALL conform to the ABNF [RFC5234]:
482 ALPHA [*VCHAR (ALPHA / DIGIT)]
484 For style and compatibility reasons, the Identifier field SHOULD
485 conform to the ABNF:
487 ALPHA *( ["-" / "." / "_" / "~"] 1*(ALPHA / DIGIT) )
489 I.e., the identifier MUST start with a letter and MAY contain
490 punctuation in the middle, but not at the end: the last character
491 MUST be alphanumeric. The second production uses the same characters
492 as the "unreserved" rule of [RFC3986], and is designed to be
493 compatible with characters in other identification systems, e.g.,
494 filenames. Since the identifier MAY be displayed to a user--
495 particularly in cases where the receiver does not recognize the
496 identifier--the identifier SHOULD be rationally related to the
497 vernacular name of the variant.
499 The Name, Description, Additional Parameters, Fragment Identifiers,
500 References, and Contact Information fields SHALL be in a Unicode
501 character set (e.g., UTF-8).
503 The registry includes the registration in Section 6.1.4 (Original
504 Markdown). [MDMTGUID] includes additional registrations.
506 6.1.1. Reserved Identifiers
508 The registry has the following identifiers RESERVED, as they have
509 engendered some controversy in the Markdown community. No one is
510 allowed to register them (or any case variations of them). These
511 identifiers are not and cannot be registered:
512 Standard
513 Common
514 Markdown
516 The registry includes the following text in the note field:
517 The variant names Standard, Common, and Markdown are reserved and
518 cannot be registered.
520 6.1.2. Standard of Review
522 Registrations are made on a First-Come, First-Served [RFC5226] basis
523 by anyone with a need to interoperate. While documentation is
524 required, any level of documentation is sufficient; thus, neither
525 Specification Required nor Expert Review are warranted. The checks
526 prescribed by this section can be performed automatically.
528 All references (including contact information) MUST be verified as
529 functional at the time of the registration.
531 As a special "escape valve", registrations can be updated with IETF
532 Review [RFC5226]. All fields may be updated except the variant
533 identifier, which is permanent: not even case may be changed.
535 6.1.3. Provisional Registration
537 Any registrant may make a provisional registration to reserve a
538 variant identifier. Only the variant identifier and contact
539 information fields are required; the rest are optional. Provisional
540 registrations expire after three months, after which time the variant
541 identifier may be reused. To make a registration permanent, a
542 registrant simply needs to complete a permanent registration with the
543 same identifier as the provisional registration.
545 6.1.4. Original Markdown
547 The registry includes this initial variant. A conforming
548 implementation that processes the variant parameter MUST recognize
549 this variant (although the processing behavior is not defined here).
551 Identifier: Original
553 Name: Markdown
555 Description:
556 Gruber's original Markdown syntax.
558 References:
559 [MARKDOWN]
560 [MDSYNTAX]
562 Contact Information:
563 (individual) John Gruber
564
566 7. Security Considerations
568 See the Security considerations entry in Section 2.
570 8. References
571 8.1. Normative References
573 [MARKDOWN] Gruber, J., "Daring Fireball: Markdown", December 2004,
574 .
576 [MDSYNTAX] Gruber, J., "Daring Fireball: Markdown Syntax
577 Documentation", December 2004,
578 .
580 [MDUTI] Gruber, J., "Daring Fireball: Uniform Type Identifier for
581 Markdown", August 2011,
582 .
585 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
586 Extensions (MIME) Part One: Format of Internet Message
587 Bodies", RFC 2045, November 1996.
589 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
590 Requirement Levels", BCP 14, RFC 2119, March 1997.
592 [RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating
593 Presentation Information in Internet Messages: The
594 Content-Disposition Header Field", RFC 2183, August 1997.
596 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
597 Word Extensions: Character Sets, Languages, and
598 Continuations", RFC 2231, November 1997.
600 [RFC3778] Taft, E., Pravetz, J., Zilles, S., and L. Masinter, "The
601 application/pdf Media Type", RFC 3778, May 2004.
603 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
604 Resource Identifier (URI): Generic Syntax", STD 66, RFC
605 3986, January 2005.
607 [RFC5147] Wilde, E. and M. Duerst, "URI Fragment Identifiers for the
608 text/plain Media Type", RFC 5147, April 2008.
610 [RFC5226] Narten, T., and H. Alvestrand, "Guidelines for Writing an
611 IANA Considerations Section in RFCs", RFC 5226, May 2008.
613 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
614 Syntax Specifications: ABNF", STD 68, RFC 5234, January
615 2008.
617 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
618 Email Headers", RFC 6532, February 2012.
620 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
621 Specifications and Registration Procedures", BCP 13, RFC
622 6838, January 2013.
624 8.2. Informative References
626 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
627 Extensions (MIME) Part Two: Media Types", RFC 2046,
628 November 1996.
630 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version
631 8.0.0", The Unicode Consortium, August 2015.
633 [ISO646] International Organization for Standardization,
634 "Information technology - ISO 7-bit coded character set
635 for information interchange", ISO Standard 646, 1991.
637 [HUMANE] Atwood, J., "Is HTML a Humane Markup Language?", May 2008,
638 .
641 [INETMEME] Solon, O., "Richard Dawkins on the internet's hijacking of
642 the word 'meme'", June 2013,
643 , .
646 [MDMTGUID] Leonard, S., "Guidance on Markdown: Design Philosophies,
647 Stability Strategies, and Select Registrations", draft-
648 ietf-appsawg-text-markdown-use-cases-07 (work in
649 progress), September 2015.
651 [PANDOC] MacFarlane, J., "Pandoc", 2014,
652 .
654 [RFC4263] Lilly, B., "Media Subtype Registration for Media Type
655 text/troff", RFC 4263, January 2006.
657 Author's Address
659 Sean Leonard
660 Penango, Inc.
661 5900 Wilshire Boulevard
662 21st Floor
663 Los Angeles, CA 90036
664 USA
666 EMail: dev+ietf@seantek.com
667 URI: http://www.penango.com/