[要約] RFC 7764は、Markdownの設計原則、安定戦略、および選択的な登録に関するガイダンスを提供しています。このRFCの目的は、Markdownの使用と開発に関する指針を提供し、一貫性と互換性を確保することです。
Internet Engineering Task Force (IETF) S. Leonard
Request for Comments: 7764 Penango, Inc.
Category: Informational March 2016
ISSN: 2070-1721
Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations
マークダウンに関するガイダンス：設計哲学、安定性戦略、および選択登録
Abstract
概要
This document elaborates upon the text/markdown media type for use with Markdown, a family of plain-text formatting syntaxes that optionally can be converted to formal markup languages such as HTML. Background information, local storage strategies, and additional syntax registrations are supplied.
このドキュメントでは、オプションでHTMLなどの正式なマークアップ言語に変換できるプレーンテキストフォーマット構文のファミリーであるMarkdownで使用するためのtext / markdownメディアタイプについて詳しく説明します。背景情報、ローカルストレージ戦略、および追加の構文登録が提供されます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7764.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7764で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Dive into Markdown . . . . . . . . . . . . . . . . . . . . . . 3
1.1. On Formats . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Markdown Design Philosophy . . . . . . . . . . . . . . . . 4
1.3. Uses of Markdown . . . . . . . . . . . . . . . . . . . . . 5
1.4. Uses of Labeling Markdown Content as text/markdown . . . . 6
1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Strategies for Preserving Media Type and Parameters . . . . . 7
2.1. Map to Filename and Attributes . . . . . . . . . . . . . . 7
2.2. Store Headers in Adjacent File . . . . . . . . . . . . . . 8
2.3. "Arm" Content with MIME Headers . . . . . . . . . . . . . . 8
2.4. Create a Local Batch Script . . . . . . . . . . . . . . . . 9
2.5. Process the Markdown in Advance . . . . . . . . . . . . . . 9
2.6. Rely on Context . . . . . . . . . . . . . . . . . . . . . . 9
2.7. Specific Strategies . . . . . . . . . . . . . . . . . . . . 9
2.7.1. Subversion . . . . . . . . . . . . . . . . . . . . . . 9
2.7.2. Git . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Registration Templates for Common Markdown Syntaxes . . . . . 10
3.1. MultiMarkdown . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. GitHub-Flavored Markdown . . . . . . . . . . . . . . . . . 11
3.3. Pandoc . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. Fountain (Fountain.io) . . . . . . . . . . . . . . . . . . 14
3.5. CommonMark . . . . . . . . . . . . . . . . . . . . . . . . 14
3.6. kramdown-rfc2629 (Markdown for RFCs) . . . . . . . . . . . 15
3.7. rfc7328 (Pandoc2rfc) . . . . . . . . . . . . . . . . . . . 16
3.8. PHP Markdown Extra . . . . . . . . . . . . . . . . . . . . 16
4. Examples for Common Markdown Syntaxes . . . . . . . . . . . . 17
4.1. MultiMarkdown . . . . . . . . . . . . . . . . . . . . . . . 17
4.2. GitHub Flavored Markdown . . . . . . . . . . . . . . . . . 18
4.3. Pandoc . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4. Fountain (Fountain.io) . . . . . . . . . . . . . . . . . . 20
4.5. CommonMark . . . . . . . . . . . . . . . . . . . . . . . . 21
4.6. kramdown-rfc2629 (Markdown for RFCs) . . . . . . . . . . . 22
4.7. rfc7328 (Pandoc2rfc) . . . . . . . . . . . . . . . . . . . 25
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 26
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1. Normative References . . . . . . . . . . . . . . . . . . . 26
7.2. Informative References . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28
This document serves as an informational companion to [RFC7763], the text/markdown media type registration. It should be considered jointly with [RFC7763].
このドキュメントは、テキスト/マークダウンメディアタイプ登録である[RFC7763]の情報を提供するものです。 [RFC7763]と一緒に検討する必要があります。
"Sometimes the truth of a thing is not so much in the think of it, but in the feel of it." -- Stanley Kubrick
「時々、物事の真実はそれについて考えることではなく、その感触にある。」 -スタンリーキューブリック
In computer systems, textual data is stored and processed using a continuum of techniques. On the one end is plain text: computer-encoded text that consists only of a sequence of code points from a given standard, with no other formatting or structural information [UNICODE]. Plain text provides /some/ fixed facilities for formatting instructions (namely, codes in the character set that have meanings other than "represent this character graphically on the output medium"); however, these facilities are not particularly extensible. Compare with Section 4.2.1 of [RFC6838]. 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).
コンピュータシステムでは、テキストデータは一連の技術を使用して保存および処理されます。一方はプレーンテキストです。コンピュータでエンコードされたテキストで、特定の規格のコードポイントのシーケンスのみで構成され、他のフォーマット情報や構造情報はありません[UNICODE]。プレーンテキストは、フォーマット指示のための/ some /固定機能を提供します（つまり、「この文字を出力媒体上でグラフィックで表す」以外の意味を持つ文字セットのコード）。ただし、これらの機能は特に拡張可能ではありません。 [RFC6838]のセクション4.2.1と比較してください。最近のアプリケーションがUS-ASCIIのほとんどの制御文字を処理する方法と同様に、アプリケーションは、これらの特殊文字を禁止するか、それらの指示された意味を無視することにより、これらの特殊文字の影響を無効にすることができます。このため、文字セットを解釈する任意のテキストリーダーまたはエディタを使用して、テキストを表示または操作できます。一部の文字が破損している場合、その破損がテキストを処理するコンピューターシステムの機能に影響を与えることはほとんどありません（人間の意味が変更されている場合でも）。
On the other end is binary data: a sequence of bits 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 bit is corrupted in a binary format, it may prevent an application from processing any of the data correctly.
もう一方の端はバイナリデータです。コンピュータアプリケーションが解釈して動作することを目的としたビットのシーケンスです。バイナリ形式は、非テキストデータを効率的に格納できるという点で柔軟性があります（おそらくテキストをまったく格納しないか、特定の種類のテキストのみを非常に特殊な目的でのみ格納します）。バイナリ形式では、形式を処理するためにアプリケーションを特別にコーディングする必要があります。部分的な相互運用は不可能です。さらに、バイナリ形式で1ビットでも破損すると、アプリケーションがデータを正しく処理できなくなる可能性があります。
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 data in that the non-textual information is encoded into textual characters that 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.
これらの両極端の間には、フォーマットされたテキスト、つまり、コンピュータプログラムによるテキストの解釈に影響を与える、特定の方法でコード化された非テキスト情報を含むテキストがあります。フォーマットされたテキストは、非テキスト情報が文字セットに定義されていない特別な意味が割り当てられているテキスト文字にエンコードされるという点で、プレーンテキストやバイナリデータとは異なります。通常のテキストエディターと標準キーボード（または他の標準入力メカニズム）を使用すると、ユーザーはこれらのテキスト文字を入力して非テキストの意味を表現できます。たとえば、「<」のような文字は「LESS-THAN SIGN」を意味しなくなりました。これは、ドキュメントに何らかの影響を与えるタグまたは要素の開始を意味します。
On the formal end of the formatted text 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 Standard Generalized Markup Language (SGML), HTML, XML, and LaTeX. 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).
フォーマットされたテキストスペクトルの正式な終わりはマークアップです。これは、注釈がテキストと構文的に区別できるような方法でドキュメントに注釈を付けるための言語のファミリです。マークアップ言語は（合理的に）十分に指定されており、（ほとんど）標準化された構文規則に従う傾向があります。マークアップ言語の例には、Standard Generalized Markup Language（SGML）、HTML、XML、およびLaTeXが含まれます。標準化されたルールは、マークアッププロセッサ間の相互運用性につながりますが、言語の新しい（人間の）ユーザーが有用な作業を行うためにこれらのルールを習得するためのスキル要件です。この面付けにより、技術者以外のユーザー（つまり、必要なスキル開発に投資したくない、または投資できないユーザー）がマークアップにアクセスできなくなります。
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
図1：テキストのデータストレージ形式における形式の程度
On the informal end of the spectrum are lightweight markup languages. In comparison with formal markup like XML, lightweight markup uses simple syntax, and is designed to be easy for humans to enter with basic text editors. Markdown, the subject of this document, is an /informal/ plain-text formatting syntax that is intentionally targeted at non-technical users (i.e., users upon whom little to no skill development is imposed) using unspecialized tools (i.e., text boxes). Jeff Atwood once described these informal markup languages as "humane" [HUMANE].
非公式な範囲には、軽量のマークアップ言語があります。 XMLのような正式なマークアップと比較して、軽量のマークアップは単純な構文を使用し、基本的なテキストエディターで人間が簡単に入力できるように設計されています。このドキュメントの主題であるMarkdownは、専門外のツール（つまり、テキストボックス）を使用して、技術者以外のユーザー（つまり、スキル開発がほとんどまたはまったく行われていないユーザー）を意図的に対象とする/非公式/プレーンテキストの書式構文です。 。 Jeff Atwoodはかつてこれらの非公式なマークアップ言語を「人道的」[人間]と表現していました。
Markdown specifically is a family of syntaxes that are based on the original work of John Gruber with substantial contributions from Aaron Swartz, released in 2004 [MARKDOWN]. Since its release, a number of web or web-facing applications have incorporated Markdown into their text-entry systems, frequently with custom extensions. Fed up with the complexity and security pitfalls of formal markup languages (e.g., HTML5) and proprietary binary formats (e.g., commercial word-processing software), yet unwilling to be confined to the restrictions of plain text, many users have turned to Markdown for document processing. Whole toolchains now exist to support Markdown for online and offline projects.
Markdownは特に、2004年にリリースされたAaron Swartzからの多大な貢献によりJohn Gruberのオリジナル作品に基づいた構文のファミリーです[MARKDOWN]。そのリリース以来、多くのWebまたはWeb向けアプリケーションがMarkdownをテキスト入力システムに組み込んでおり、多くの場合、カスタム拡張機能を備えています。形式的なマークアップ言語（HTML5など）や独自のバイナリ形式（商用のワープロソフトウェアなど）の複雑さとセキュリティの落とし穴にうんざりしているが、プレーンテキストの制限に制限されたくないため、多くのユーザーがMarkdownドキュメント処理。オンラインおよびオフラインプロジェクトのMarkdownをサポートするツールチェーン全体が存在するようになりました。
Informality is a bedrock premise of Gruber's design. Gruber created Markdown after disastrous experiences with strict XML and XHTML processing of syndicated feeds. In Mark Pilgrim's "thought experiment", several websites went down because one site included invalid XHTML in a blog post, which was automatically copied via trackbacks across other sites [DIN2MD]. These scenarios led Gruber to believe that clients (e.g., web browsers) SHOULD try to make sense of data that they receive, rather than rejecting data simply because it fails to adhere to strict, unforgiving standards. (In [DIN2MD], Gruber compared Postel's Law [RFC793] with the XML standard, which says: "Once a fatal error is detected [...] the processor MUST NOT continue normal processing" [XML1.0-5].) As a result, there is no such thing as "invalid" Markdown, there is no standard demanding adherence to the Markdown syntax, and 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]).
非形式性は、グルーバーのデザインの基盤となる前提です。 Gruberは、シンジケートフィードの厳密なXMLおよびXHTML処理による悲惨な経験の後でMarkdownを作成しました。 Mark Pilgrimの「思考実験」では、1つのサイトに無効なXHTMLがブログ投稿に含まれていて、他のサイトのトラックバックを介して自動的にコピーされたため、いくつかのWebサイトがダウンしました[DIN2MD]。これらのシナリオにより、Gruberは、クライアント（Webブラウザーなど）が、厳格で許されない標準に準拠していないという理由だけでデータを拒否するのではなく、受信したデータを理解する必要があると考えました。 （[DIN2MD]で、GruberはPostelの法則[RFC793]を、「致命的なエラーが検出されたら[...]プロセッサは通常の処理を継続してはならない」[XML1.0-5]と言うXML標準と比較しました。）その結果、「無効な」Markdownのようなものはなく、Markdown構文への標準的な要求の順守はありません。また、その開発を誘導または妨害する統治機関もありません。マークダウン構文の結果が「正しい」出力（作成者が希望する出力であり、規定されたルールシステムに準拠する出力ではない）にならない場合、Gruberの見解では、作成者は実験を続けるか、プロセッサを変更する必要があります。著者の特定のニーズに対処するため（[MARKDOWN] Readmeおよび[MD102b8] perldocを参照。[CATPICS]も参照）。
Since its introduction in 2004, Markdown has enjoyed remarkable success. Markdown works for users for three key reasons. First, the markup instructions (in text) look similar to the markup that they 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 [OCCASION], for screenplays [FOUNTAIN], and even for mathematical formulae [MATHDOWN]. 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.
Markdownは2004年の導入以来、目覚しい成功を収めてきました。 Markdownは、3つの主な理由でユーザーに役立ちます。まず、マークアップの手順（テキスト）は、それらが表すマークアップに似ています。したがって、構文を学習するための認知的負担は低くなります。第二に、構文が成功するかどうかの主要な決定要因は*コードの実行*です。 Markdownを標準化団体による一連の正式な宣言ではなく、表示可能な形式に変換するツールは、構文要素が重要かどうかの基礎となります。第3に、Markdownはインターネットミーム[INETMEME]のようなものになり、追加のコミュニティでMarkdownが検出されるとMarkdownが受信、再解釈、および再加工されます。 Markdownを学術的な執筆[OCCASION]、脚本[FOUNTAIN]、さらには数式[MATHDOWN]に使用しているコミュニティがあります。明らかに、脚本家は数学者向けの特別なMarkdown構文を使用していません。同様に、数学者は一般的な方法でキャラクターや小道具を識別する必要はありません。全体的な要点は、これらのコミュニティはすべて、Markdownの共通要素（2004年頃のHTMLの共通要素に根ざしている）を利用して、ニーズに最も適した方法で構築できることです。
The primary purpose of an Internet media type is to label "content" on the Internet, as distinct from "files". Content is any computer-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.
インターネットメディアタイプの主な目的は、「ファイル」とは異なり、インターネット上の「コンテンツ」にラベルを付けることです。コンテンツは、タイプ固有のメタデータ（パラメーター）およびタイプにとらわれないメタデータ（プロトコルに依存）と共に、オクテットの主要なシーケンスとして表すことができるコンピューターで読み取り可能な形式です。この説明から、ファイル名の最後に「.markdown」を追加することは、Markdownを識別するのに十分な手段ではないことは明らかです。ファイル名はファイルシステム内のファイルのプロパティですが、Markdownはデータベースやコンテンツ管理システム（CMS）に頻繁に存在し、ファイルのメタファーが適用されません。 1つのCMS [RAILFROG]はメディアタイプを使用して適切な処理を選択するため、Markdownを安全に相互運用して使用するには、メディアタイプが必要です。
Unlike complete HTML documents, [MDSYNTAX] provides no means to include metadata in 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 here or in [RFC7763]; however, by identifying Markdown with a media type, Markdown content can participate as a first-class citizen with a wide spectrum of metadata schemes.
完全なHTMLドキュメントとは異なり、[MDSYNTAX]はコンテンツストリームにメタデータを含める手段を提供しません。いくつかの派生フレーバーはメタデータ組み込みスキーム（例：[MULTIMD]）を発明しましたが、これらのスキームは特定の使用事例のみを扱います。一般に、メタデータは、カプセル化プロトコル、形式、または規則で補足手段を介して提供する必要があります。コンテンツとメタデータの関係は、ここや[RFC7763]で直接扱われていません。ただし、Markdownをメディアタイプで識別することにより、Markdownコンテンツは幅広いメタデータスキームを持つファーストクラスの市民として参加できます。
Finally, registering a media type through the IETF process is not trivial. Markdown can no longer be considered a "vendor"-specific innovation, but the registration requirements even in the vendor tree have proven to be overly burdensome for most Markdown implementers. Moreover, registering hundreds of Markdown variants with distinct media types would impede interoperability: virtually all Markdown content can be processed by virtually any Markdown processor, with varying degrees of success. The goal of [RFC7763] is to reduce all of these burdens by having one media type that accommodates diversity and eases registration.
最後に、IETFプロセスを通じてメディアタイプを登録することは簡単ではありません。 Markdownはもはや「ベンダー」固有のイノベーションと見なすことはできませんが、ほとんどのMarkdown実装者にとって、ベンダーツリーでの登録要件は非常に負担になることが証明されています。さらに、何百ものMarkdownバリアントを異なるメディアタイプで登録すると、相互運用性が妨げられます。事実上すべてのMarkdownコンテンツは、事実上あらゆるMarkdownプロセッサで処理でき、成功の度合いはさまざまです。 [RFC7763]の目標は、多様性に対応し、登録を容易にする1つのメディアタイプを持つことにより、これらの負担のすべてを軽減することです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Since Markdown signifies a family of related formats with varying degrees of formal documentation and implementation, this specification uses the term "variant" to identify such formats.
Markdownは、さまざまな程度の正式なドキュメントと実装を持つ関連フォーマットのファミリーを意味するため、この仕様では、「バリアント」という用語を使用してそのようなフォーマットを識別します。
The purpose of this document and [RFC7763] is to promote interoperability between different Markdown-related systems, preserving the author's intent. While [MARKDOWN] was designed by Gruber in 2004 as a simple way to write blog posts and comments, as of 2014 Markdown and its derivatives are rapidly becoming the formats of record for many communities and use cases. While an individual member of (or software tool for) a community can probably look at some "Markdown" and declare its meaning intuitively obvious, software systems in different communities (or different times) need help. [MDSYNTAX] does not have a signaling mechanism like <!DOCTYPE>, so tagging Markdown internally is simply out of the question. Once tags or metadata are introduced, the content is no longer "just" Markdown.
このドキュメントと[RFC7763]の目的は、異なるMarkdown関連システム間の相互運用性を促進し、作者の意図を保持することです。 [MARKDOWN]は、2004年にブログの投稿とコメントを作成する簡単な方法としてGruberによって設計されましたが、2014年以降、Markdownとその派生物は、多くのコミュニティとユースケースで急速にレコードのフォーマットになりつつあります。コミュニティの個々のメンバー（またはソフトウェアツール）はおそらく「Markdown」を見て、その意味を直感的に明白に宣言できますが、異なるコミュニティ（または異なる時期）のソフトウェアシステムには助けが必要です。 [MDSYNTAX]には<！DOCTYPE>のようなシグナリングメカニズムがないため、Markdownに内部的にタグを付けることは問題外です。タグまたはメタデータが導入されると、コンテンツは「単なる」マークダウンではなくなります。
Some commentators have suggested that an in-band signaling mechanism, such as in Markdown link definitions at the top of the content, could be used to signal the variant. Unfortunately, this signaling mechanism is incompatible with other Markdown variants (e.g., [PANDOC]) that expect their own kinds of metadata at the top of the file. Markdown content is just a stream of text; the semantics of that text can only be furnished by context.
一部のコメンテーターは、コンテンツの上部にあるMarkdownリンク定義などのインバンドシグナリングメカニズムを使用して、バリアントをシグナリングできることを示唆しています。残念ながら、このシグナリングメカニズムは、ファイルの先頭に独自の種類のメタデータを期待する他のMarkdownバリアント（[PANDOC]など）と互換性がありません。 Markdownコンテンツは単なるテキストのストリームです。そのテキストのセマンティクスは、コンテキストによってのみ提供できます。
The media type and variant parameter in [RFC7763] furnish this missing context, while allowing for additional extensibility. This section covers strategies for how an application might preserve metadata when it leaves the domain of IETF protocols.
[RFC7763]のメディアタイプとバリアントパラメータは、この拡張されたコンテキストを提供する一方で、追加の拡張性を可能にします。このセクションでは、アプリケーションがIETFプロトコルのドメインを離れたときにメタデータを保持する方法について説明します。
[RFC7763] only defines two parameters: the charset parameter
(required for all text/* media types) and the variant parameter.
[RFC6657] provides guidance on character-set parameter handling. The
variant parameter provides a simple identifier -- nothing less or
more. Variants are allowed to define additional parameters when sent
with the text/markdown media type; the variant can also introduce
control information into the textual content stream (such as via a
metadata block). Neither [RFC7763] nor this specification recommend
any particular approach. However, the philosophy behind [RFC7763] is
to preserve formats rather than create new ones, since supporting
existing toolchains is more realistic than creating novel ones that
lack traction in the Markdown community.
This strategy is to map the media type, variant, and parameters to "attributes" or "forks" in the local convention. Firstly, Markdown content saved to a file should have an appropriate file extension ending in .md or .markdown, which serves to disambiguate it from other kinds of files. The character repertoire of variant identifiers in [RFC7763] is designed to be compatible with most filename conventions. Therefore, a recommended strategy is to record the variant identifier as the prefix to the file extension. For example, for [PANDOC] content, a file could be named "example.pandoc.markdown".
この戦略は、メディアのタイプ、バリアント、およびパラメーターをローカル規約の「属性」または「フォーク」にマッピングすることです。まず、ファイルに保存されたMarkdownコンテンツには、末尾が.mdまたは.markdownである適切なファイル拡張子が必要です。これにより、他の種類のファイルと区別することができます。 [RFC7763]のバリアント識別子の文字レパートリーは、ほとんどのファイル名規則と互換性があるように設計されています。したがって、推奨される戦略は、ファイル拡張子のプレフィックスとしてバリアント識別子を記録することです。たとえば、[PANDOC]コンテンツの場合、ファイル名は「example.pandoc.markdown」になります。
Many filesystems are case-sensitive or case-preserving; however, file extensions tend to be all lowercase. This document takes no position on whether variant identifiers should be case-preserved or all lowercase when Markdown content is written to a file. However, when the variant identifier is read to influence operational behavior, it needs to be compared case-insensitively.
多くのファイルシステムは大文字と小文字を区別するか、または保持します。ただし、ファイル拡張子はすべて小文字になる傾向があります。このドキュメントでは、Markdownコンテンツをファイルに書き込むときに、バリアント識別子を大文字と小文字を区別して保持するか、すべて小文字にするかについては考慮されていません。ただし、操作の動作に影響を与えるためにバリアント識別子を読み取る場合は、大文字と小文字を区別せずに比較する必要があります。
Many modern filesystems support "extended attributes", "alternate data streams", or "resource forks". Some version control systems support named properties. If the variant defines additional parameters, these parameters should be stored in these resources, where the parameter name includes the name of the resource, and the parameter value is the value of the resource (data in the resource), preferably UTF-8 encoded (unless the parameter definition explicitly defines a different encoding or repertoire). The variant identifier itself should be stored in a resource with a name including the term "variant" (possibly including other decorations to avoid namespace collisions).
最新のファイルシステムの多くは、「拡張属性」、「代替データストリーム」、または「リソースフォーク」をサポートしています。一部のバージョン管理システムは、名前付きプロパティをサポートしています。バリアントが追加のパラメーターを定義する場合、これらのパラメーターはこれらのリソースに保存する必要があります。パラメーター名にはリソースの名前が含まれ、パラメーター値はリソースの値（リソース内のデータ）で、できればUTF-8でエンコードされます（パラメーター定義で明示的に別のエンコードまたはレパートリーを定義しない限り）。バリアント識別子自体は、「バリアント」という用語を含む名前でリソースに格納する必要があります（名前空間の衝突を回避するために他の装飾を含む可能性があります）。
This strategy is to save the Markdown content in a first file and to save the metadata (specifically the Content-Type header) in a second file with a filename that is rationally related to the first filename. For example, if the first file is named "readme.markdown", the second file could be named "readme.markdown.headers". (If stored in a database, the analogy would be to store the metadata in a second table with a field that is a key to the first table.) This header file has the media type message/global-headers [RFC6533] (".u8hdr" suggestion notwithstanding).
この戦略は、Markdownコンテンツを最初のファイルに保存し、メタデータ（特にContent-Typeヘッダー）を、最初のファイル名に合理的に関連するファイル名で2番目のファイルに保存することです。たとえば、最初のファイルの名前が「readme.markdown」の場合、2番目のファイルの名前は「readme.markdown.headers」になります。 （データベースに保存されている場合、類似点は、最初のテーブルのキーであるフィールドを持つ2番目のテーブルにメタデータを保存することです。）このヘッダーファイルには、メディアタイプmessage / global-headers [RFC6533]（ "。 u8hdr」の提案にもかかわらず）。
This strategy is to save the Markdown content along with its headers in a file, "arming" the content by prepending the MIME headers (specifically the Content-Type header). It should be appreciated that the file is no longer a "Markdown file"; rather, it is an Internet Message Format file (e.g., [RFC5322]) with a Markdown content part. Therefore, the file should have an Internet message extension (e.g., ".eml", ".msg", or ".u8msg"), not a Markdown extension (e.g., ".md" or ".markdown").
この戦略は、Markdownコンテンツをそのヘッダーと一緒にファイルに保存し、MIMEヘッダー（特にContent-Typeヘッダー）を付加することでコンテンツを「準備」することです。ファイルが「Markdownファイル」ではなくなったことを認識してください。むしろ、それはMarkdownコンテンツパーツを含むインターネットメッセージフォーマットファイル（[RFC5322]など）です。したがって、ファイルには、Markdown拡張子（「.md」や「.markdown」など）ではなく、インターネットメッセージ拡張子（「.eml」、「。msg」、「。u8msg」など）が必要です。
This strategy is to translate the processing instructions inferred from the Content-Type and other parameters (e.g., Content-Disposition) into a sequence of commands in the local convention, storing those commands in a batch script. For example, when a MIME-aware client stores some Markdown to disk, the client can save a Makefile in the same directory with commands that are appropriate (and safe) for the local system.
この戦略は、Content-Typeおよびその他のパラメーター（Content-Dispositionなど）から推論された処理命令をローカル規則の一連のコマンドに変換し、それらのコマンドをバッチスクリプトに格納することです。たとえば、MIME対応のクライアントが一部のMarkdownをディスクに保存する場合、クライアントは、ローカルシステムに適切（かつ安全）なコマンドを使用して、Makefileを同じディレクトリに保存できます。
This strategy is to process the Markdown into the formal markup, before a recipient receives it; this eliminates ambiguities. Once the Markdown is processed into (for example) valid XHTML, an application can save a file as "doc.xhtml" or can send MIME content as application/xhtml+xml with no further loss of metadata. While unambiguous, this process may not be reversible.
この戦略は、受信者がマークダウンを受け取る前に、マークダウンを正式なマークアップに処理することです。これにより、あいまいさがなくなります。 Markdownが（たとえば）有効なXHTMLに処理されると、アプリケーションはファイルを「doc.xhtml」として保存するか、MIMEコンテンツをapplication / xhtml + xmlとして送信し、メタデータをさらに失うことはありません。このプロセスは明確ですが、元に戻せない場合があります。
This last strategy is to use or create context to determine how to interpret the Markdown. For example, Markdown content that is of the Fountain.io type [FOUNTAIN] could be saved with the filename "script.fountain" instead of "script.markdown". Alternatively, scripts could be stored in a "/screenplays" directory while other kinds of Markdown could be stored elsewhere. For reasons that should be intuitively obvious, this method is the most error-prone. "Context" can be easily lost over time, and the trend of passing Markdown between systems -- taking them *out* of context -- is increasing.
この最後の戦略は、コンテキストを使用または作成して、Markdownを解釈する方法を決定することです。たとえば、Fountain.ioタイプ[FOUNTAIN]のMarkdownコンテンツは、「script.markdown」ではなく「script.fountain」というファイル名で保存できます。または、スクリプトを「/ screenplays」ディレクトリに保存し、他の種類のMarkdownを別の場所に保存することもできます。直感的に明白であるはずの理由により、この方法は最もエラーが発生しやすくなります。 「コンテキスト」は時間の経過とともに簡単に失われる可能性があり、システム間でMarkdownを通過させる（コンテキストから*削除*する）傾向が高まっています。
This subsection covers a preservation strategy in Subversion [SVN], a common client-server version control system.
このサブセクションでは、一般的なクライアントサーバーバージョン管理システムであるSubversion [SVN]の保存戦略について説明します。
Subversion supports named properties. The "svn:mime-type" property duplicates the entire Content-Type header, so parameters SHOULD be stored there (Section 2.1). The filename SHOULD be consistent with this Content-Type header, i.e., the extension SHOULD be the variant identifier plus ".markdown" (Section 2.1).
Subversionは名前付きプロパティをサポートしています。 "svn：mime-type"プロパティはContent-Typeヘッダー全体を複製するため、パラメーターをそこに格納する必要があります（セクション2.1）。ファイル名は、このContent-Typeヘッダーと一致している必要があります。つまり、拡張子は、バリアント識別子と「.markdown」（セクション2.1）である必要があります（SHOULD）。
This subsection covers a preservation strategy in Git [GIT], a common distributed version control system.
このサブセクションでは、一般的な分散バージョン管理システムであるGit [GIT]の保存戦略について説明します。
Versions of Git as of the time of this writing do not support arbitrary metadata storage; however, third-party projects add this support.
この記事の執筆時点でのGitのバージョンは、任意のメタデータストレージをサポートしていません。ただし、サードパーティプロジェクトはこのサポートを追加します。
If Git is used without a metadata storage service, then a reasonable strategy is to include the variant identifier in the filename (Section 2.1). The default text encoding SHOULD be UTF-8. For other or different properties, a header file SHOULD be recorded alongside the Markdown file (Section 2.2).
Gitがメタデータストレージサービスなしで使用される場合、妥当な戦略は、ファイル名にバリアント識別子を含めることです（セクション2.1）。デフォルトのテキストエンコーディングはUTF-8である必要があります（SHOULD）。他のまたは異なるプロパティの場合、ヘッダーファイルはMarkdownファイル（セクション2.2）と一緒に記録する必要があります（SHOULD）。
If a metadata storage service is used with Git, then use a convention that is most analogous to the service. For example, the "metastore" project emulates extended attributes (xattrs) of a POSIX-like system, so whatever "xattr" methodology is developed would be usable with metastore and Git.
メタデータストレージサービスをGitで使用する場合は、サービスに最も類似した規則を使用します。たとえば、「メタストア」プロジェクトはPOSIXのようなシステムの拡張属性（xattrs）をエミュレートするため、開発された「xattr」方法論はメタストアとGitで使用できます。
The purpose of this section is to register certain syntaxes in the "Markdown Variants" registry [RFC7763] because they illustrate particularly interesting use cases or are broadly applicable to the Internet community; thus, these syntaxes would benefit from the level of review associated with publication as IETF documents.
このセクションの目的は、特定の構文を「Markdown Variants」レジストリ[RFC7763]に登録することです。これらの構文は、特に興味深い使用例を示しているか、インターネットコミュニティに広く適用できるためです。したがって、これらの構文は、IETF文書としての公開に関連するレビューのレベルから利益を得るでしょう。
Identifier: MultiMarkdown
識別子：MultiMarkdown
Name: MultiMarkdown
名前：MultiMarkdown
Description: MultiMarkdown (MMD) is a superset of "Original". It adds multiple syntax features (tables, footnotes, and citations, to name a few) and is intended to output to various formats. Additionally, it builds in "smart" typography for various languages (proper left-and right-sided quotes, for example).
説明：MultiMarkdown（MMD）は、「オリジナル」のスーパーセットです。複数の構文機能（例として、表、脚注、引用）を追加し、さまざまな形式で出力することを目的としています。さらに、さまざまな言語の「スマート」なタイポグラフィが組み込まれています（たとえば、適切な左右の引用符）。
Additional Parameters: options: String with zero or more of the following tokens delimited by whitespace (WSP):
追加パラメーター：オプション：空白（WSP）で区切られた次のトークンの0個以上の文字列：
"memoir" / "beamer"
"full" / "snippet"
"process-html"
"random-footnote-identifiers"
"accept"
"reject"
"nosmart"
"nonotes"
"nolabels"
"nomask"
The meanings of these tokens are defined in the MultiMarkdown documentation.
これらのトークンの意味は、MultiMarkdownのドキュメントで定義されています。
References:
<http://fletcher.github.io/MultiMarkdown-4/syntax>
Contact Information:
(individual) Fletcher T. Penney <fletcher@fletcherpenney.net>
<http://fletcherpenney.net/multimarkdown/>
Identifier: GFM
識別子：GFM
Name: GitHub Flavored Markdown
名前：GitHubフレーバーマークダウン
Description: "Original" with the following differences: 1. Multiple underscores in words 2. URL (URI) autolinking 3. Strikethrough 4. Fenced code blocks 5. Syntax highlighting 6. Tables (- for rows; | for columns; : for alignment) 7. Only some HTML allowed; sanitization is integral to the format
説明：「元の」以下の違い：1.単語内の複数のアンダースコア2. URL（URI）の自動リンク3.取り消し線4.囲われたコードブロック5.構文の強調表示6.テーブル（-は行、|は列、：は配置） ）7.一部のHTMLのみが許可されます。消毒はフォーマットに不可欠です
References:
<https://help.github.com/articles/github-flavored-markdown/>
<https://github.com/github/markup/tree/master#html-sanitization>
Contact Information:
(corporate) GitHub, Inc. <https://github.com/contact>
Identifier: pandoc
識別子：pandoc
Name: Pandoc
名前：パンドック
Description: Markdown is designed to be easy to write and to read: the content should be publishable as-is, as plain text, without looking like it has been marked up with tags or formatting instructions. Yet whereas "Original" has HTML generation in mind, pandoc is designed for multiple output formats. Thus, while pandoc allows the embedding of raw HTML, it discourages it, and provides other, non-HTMLish ways of representing important document elements like definition lists, tables, mathematics, and footnotes.
説明：Markdownは、書き込みや読み取りが簡単にできるように設計されています。コンテンツは、タグやフォーマット指示でマークアップされているように見えなくても、プレーンテキストとしてそのまま公開できる必要があります。しかし、「オリジナル」はHTMLの生成を念頭に置いていますが、pandocは複数の出力フォーマット用に設計されています。したがって、pandocは未加工のHTMLの埋め込みを許可しますが、それを阻止し、定義リスト、テーブル、数学、脚注などの重要なドキュメント要素を表す、HTML以外の方法を提供します。
Additional Parameters: extensions: String with an optional starting syntax token, followed by a "+" and "-" delimited list of extension tokens. "+" preceding an extension token turns the extension on; "-" turns the extension off. The starting syntax tokens are "markdown", "markdown_strict", "markdown_phpextra", and "markdown_github". If no starting syntax token is given, "markdown" is assumed. The extension tokens include:
追加パラメータ：extensions：オプションの開始構文トークンを含む文字列、その後に「+」と「-」で区切られた拡張トークンのリスト。拡張トークンの前の「+」は拡張をオンにします。 「-」は拡張機能をオフにします。開始構文トークンは、「markdown」、「markdown_strict」、「markdown_phpextra」、および「markdown_github」です。開始構文トークンが指定されていない場合、「markdown」が想定されます。拡張トークンには次のものがあります。
Extensions to turn off (on by default):
オフにする拡張機能（デフォルトではオン）：
escaped_line_breaks blank_before_header header_attributes auto_identifiers implicit_header_references blank_before_blockquote fenced_code_blocks fenced_code_attributes line_blocks fancy_lists startnum definition_lists example_lists table_captions simple_tables multiline_tables grid_tables pipe_tables pandoc_title_block yaml_metadata_block all_symbols_escapable intraword_underscores strikeout superscript subscript inline_code_attributes tex_math_dollars raw_html markdown_in_html_blocks native_divs native_spans raw_tex latex_macros implicit_figures footnotes inline_notes citations
escaped_line_breaks blank_before_header header_attributes auto_identifiers implicit_header_references blank_before_blockquote fenced_code_blocks fenced_code_attributes line_blocks fancy_lists STARTNUM definition_lists example_lists table_captions simple_tables multiline_tables grid_tables pipe_tables pandoc_title_block yaml_metadata_block all_symbols_escapable intraword_underscores取り消し線、上付きの添え字inline_code_attributes tex_math_dollars raw_html markdown_in_html_blocks native_divs native_spans raw_tex latex_macros implicit_figures脚注inline_notes引用
Extensions to turn on (off by default):
オンにする拡張機能（デフォルトではオフ）：
lists_without_preceding_blankline hard_line_breaks ignore_line_breaks tex_math_single_backslash tex_match_double_backslash markdown_attribute mmd_title_block abbreviations autolink_bare_uris ascii_identifiers link_attributes mmd_header_identifiers compact_definition_lists
lists_without_preceding_blankline hard_line_breaks ignore_line_breaks tex_math_single_backslash tex_match_double_backslash markdown_attribute mmd_title_block abbreviations autolink_bare_uris ascii_identifiers link_attributes mmd_header_identifiers compact_definition_lists
Fragment Identifiers: Pandoc defines fragment identifiers using the <id> in the {#<id> .class ...} production (PHP Markdown Extra attribute block). This syntax works for Header Identifiers and Code Block Identifiers.
フラグメント識別子：Pandocは、{＃<id> .class ...}プロダクション（PHP Markdown Extra属性ブロック）の<id>を使用してフラグメント識別子を定義します。この構文は、ヘッダー識別子とコードブロック識別子で機能します。
References:
<http://johnmacfarlane.net/pandoc/README.html#pandocs-markdown>
Contact Information:
(individual) Prof. John MacFarlane <jgm@berkeley.edu>
<http://johnmacfarlane.net/>
Identifier: Fountain
識別子：噴水
Name: Fountain
名前：噴水
Description: Fountain is a simple markup syntax for writing, editing, and sharing screenplays in plain, human-readable text. Fountain allows you to work on your screenplay anywhere, on any computer or tablet, using any software that edits text files.
説明：Fountainは、人間が読めるプレーンテキストで脚本を作成、編集、共有するためのシンプルなマークアップ構文です。 Fountainを使用すると、テキストファイルを編集するソフトウェアを使用して、場所やコンピューター、タブレットを問わずに脚本を作成できます。
Fragment Identifiers: See <http://fountain.io/syntax#section-titlepage> and <http://fountain.io/syntax#section-sections>. In the following fragment identifiers, the <key> and <sec*> productions MUST have "/" characters percent-encoded.
フラグメント識別子：<http://fountain.io/syntax#section-titlepage>および<http://fountain.io/syntax#section-sections>を参照してください。次のフラグメント識別子では、<key>および<sec *>プロダクションは「/」文字をパーセントエンコードする必要があります。
#/ Title Page (acts as metadata). #/<key> Title Page; <key> is the key string. #<sec1> *("/" <secn>) Section or subsection. The <sec1>..<secn> productions are the text of the Section line, with whitespace trimmed from both ends. Subsections (sections with multiple # characters at the beginning of the line in the source) are addressed hierarchically by preceding the subsection with higher-order sections. If the section hierarchy "skips", e.g., # to ###, use a blank section name, e.g., #Section/ACT%20I//PATIO%20SCENE.
＃/タイトルページ（メタデータとして機能）。 ＃/ <key>タイトルページ; <key>はキー文字列です。 ＃<sec1> *（ "/" <secn>）セクションまたはサブセクション。 <sec1> .. <secn>プロダクションは、両端から空白が削除されたセクション行のテキストです。サブセクション（ソースの行の先頭に複数の＃文字を含むセクション）は、サブセクションの前に高次セクションを置くことにより、階層的にアドレス指定されます。 ＃＃から###などのセクション階層が「スキップ」する場合は、＃Section / ACT％20I // PATIO％20SCENEなどの空白のセクション名を使用します。
References:
<http://fountain.io/syntax>
Contact Information:
(individual) Stu Maschwitz <http://prolost.com/>
(individual) John August <http://johnaugust.com/>
Identifier: CommonMark
識別子：CommonMark
Name: CommonMark
名前：CommonMark
Description: CommonMark is a standard, unambiguous syntax specification for Markdown, along with a suite of comprehensive tests to validate Markdown implementations against this specification. The maintainers believe that CommonMark is necessary, even essential, for the future of Markdown.
説明：CommonMarkは、Markdownの標準的な明確な構文仕様であり、Markdownの実装をこの仕様に照らして検証する包括的なテストスイートです。メンテナーは、CommonMarkはMarkdownの将来のために必要であり、不可欠でさえあると信じています。
Compared to "Original", CommonMark is much longer and in a few instances contradicts "Original" based on seasoned experience. Although CommonMark specifically does not mandate any particular encoding for the input content, CommonMark draws in more of Unicode, UTF-8, and HTML (including HTML5) than "Original".
「オリジナル」と比較すると、CommonMarkははるかに長く、いくつかの例では、経験豊かな経験に基づく「オリジナル」と矛盾します。 CommonMarkは特に入力コンテンツの特定のエンコーディングを義務付けていませんが、CommonMarkは「オリジナル」よりも多くのUnicode、UTF-8、およびHTML（HTML5を含む）を使用します。
This registration always refers to the latest version or an unspecified version (receiver's choice). Version 0.13 of the CommonMark specification was released 2014-12-10.
この登録は常に最新バージョンまたは不特定のバージョン（受信者の選択）を参照します。 CommonMark仕様のバージョン0.13が2014-12-10にリリースされました。
References:
<http://spec.commonmark.org/>
Contact Information:
(individual) John MacFarlane <jgm@berkeley.edu>
(individual) David Greenspan <david@meteor.com>
(individual) Vicent Marti <vicent@github.com>
(individual) Neil Williams <neil@reddit.com>
(individual) Benjamin Dumke-von der Ehe <ben@stackexchange.com>
(individual) Jeff Atwood <jatwood@codinghorror.com>
Identifier: kramdown-rfc2629
識別：kramdown-rfc2629
Name: Markdown for RFCs
名前：RFCのマークダウン
Description: kramdown is a markdown parser by Thomas Leitner; it has a number of backends for generating HTML, LaTeX, and Markdown again. kramdown-rfc2629 is an additional backend to that: It allows the generation of XML2RFC XML markup (originally known as markup that is RFC 2629 compliant, now documented in RFC 7749).
説明：kramdownは、Thomas Leitnerによるマークダウンパーサーです。 HTML、LaTeX、Markdownを再び生成するためのバックエンドがいくつかあります。 kramdown-rfc2629は、そのための追加のバックエンドです。XML2RFCXMLマークアップ（元はRFC 2629に準拠したマークアップとして知られ、現在RFC 7749で文書化されています）の生成を可能にします。
References:
<https://github.com/cabo/kramdown-rfc2629>
Contact Information:
(individual) Carsten Bormann <cabo@tzi.org>
Identifier: rfc7328
識別：rfc7328
Name: Pandoc2rfc
名前：Pandoc2rfc
Description: Pandoc2rfc allows authors to write in "pandoc" that is then transformed to XML and given to xml2rfc. The conversions are, in a way, amusing, as we start off with (almost) plain text, use elaborate XML, and end up with plain text again.
説明：Pandoc2rfcを使用すると、作成者は "pandoc"で記述し、それをXMLに変換してxml2rfcに渡すことができます。変換は、ある意味、おもしろいです。（ほとんど）プレーンテキストから始めて、手の込んだXMLを使用し、最終的にプレーンテキストで終わります。
References:
RFC 7328
<https://github.com/miekg/pandoc2rfc>
Contact Information:
(individual) R. (Miek) Gieben <miek@google.com>
Identifier: Extra
識別子：追加
Name: Markdown Extra
名前：Markdown Extra
Description: Markdown Extra is an extension to PHP Markdown implementing some features currently not available with the plain Markdown syntax. Markdown Extra is available as a separate parser class in PHP Markdown Lib. Other implementations include Maruku (Ruby) and Python Markdown. Markdown Extra is supported in several content management systems, including Drupal, TYPO3, and MediaWiki.
説明：Markdown Extraは、単純なMarkdown構文では現在利用できないいくつかの機能を実装するPHP Markdownの拡張機能です。 Markdown Extraは、PHP Markdown Libの個別のパーサークラスとして使用できます。他の実装には、Maruku（Ruby）とPython Markdownが含まれます。 Markdown Extraは、Drupal、TYPO3、MediaWikiなど、いくつかのコンテンツ管理システムでサポートされています。
Fragment Identifiers: Markdown Extra defines fragment identifiers using the <id> in the {#<id> .class ...} production (attribute block). This syntax works for headers, fenced code blocks, links, and images.
フラグメント識別子：Markdown Extraは、{＃<id> .class ...}プロダクション（属性ブロック）の<id>を使用してフラグメント識別子を定義します。この構文は、ヘッダー、フェンスされたコードブロック、リンク、および画像に対して機能します。
References:
<https://michelf.ca/projects/php-markdown/extra/>
Contact Information:
(individual) Michel Fortin <michel.fortin@michelf.ca>
This section provides examples of the variants in Section 3.
このセクションでは、セクション3のバリアントの例を示します。
Title: Example of MultiMarkdown Keywords: IETF, example, footnotes
タイトル：MultiMarkdownキーワードの例：IETF、例、脚注
# MultiMarkdown Example #
＃MultiMarkdownの例＃
MultiMarkdown supports several cool features, as well as several output formats: * HTML * PDF * OpenDocument * OPML * LaTeX
MultiMarkdownは、いくつかの優れた機能といくつかの出力形式をサポートしています。* HTML * PDF * OpenDocument * OPML * LaTeX
## Footnotes ##
Footnotes are described in the MultiMarkdown Syntax Guide.[^somesamplefootnote]
脚注については、MultiMarkdown Syntax Guideで説明されています。[^ somesamplefootnote]
[^somesamplefootnote]: Here is the text of the footnote itself.
[^ somesamplefootnote]：脚注自体のテキストです。
Figure 1: MultiMarkdown Example
図1：MultiMarkdownの例
# Start Out #
＃ 始める ＃
GFM is like regular Markdown with a few extra features. For example,
http://www.example.com/ will get auto-linked. ~~This is strike-through
text, demarked by the double tildes.~~
```
function test() {
return "notice this feature?");
}
```
# Table Alignments #
＃テーブルの配置＃
| Left | Center | Right |
|:--------- |:-------:| ------:|
| cats | Paxton | $1600 |
| dogs | Ruff | $30 |
| zebras | Stripes | $20900 |
Figure 2: GitHub Flavored Markdown Example
図2：GitHubフレーバーマークダウンの例
% Pandoc User's Guide % John MacFarlane % August 30, 2014
％Pandocユーザーガイド％John MacFarlane％2014年8月30日
Synopsis {#syn}
========
pandoc [*options*] [*input-file*]...
pandoc [*オプション*] [*入力ファイル*] ...
Description {#desc}
===========
Pandoc is a [Haskell] library for converting from one markup format to another, and a command-line tool that uses this library.
Pandocは、あるマークアップ形式から別のマークアップ形式に変換するための[Haskell]ライブラリであり、このライブラリを使用するコマンドラインツールです。
#### Extension: `header_attributes` #### {#ext-header-attributes}
Headers can be assigned attributes using this syntax at the end of the line containing the header text:
ヘッダーには、ヘッダーテキストを含む行の最後に次の構文を使用して属性を割り当てることができます。
{#identifier .class .class key=value key=value}
Thus, for example, the following headers will all be assigned the identifier `foo`:
したがって、たとえば、次のヘッダーにはすべて識別子「foo」が割り当てられます。
# My header {#foo}
## My header ## {#foo}
My other header {#foo}
---------------
Figure 3: Pandoc Example
図3：Pandocの例
INT. BOXCAR - MOVING - DAY ?AGENT MORTIMER lies bleeding in the corner. The car ROCKS gently. Mortimer pulls out his cell phone and dials.
INT。 BOXCAR-MOVING-DAY？AGENT MORTIMERが隅に出血しています。車が優しく揺れる。モーティマーは携帯電話を引き出してダイヤルします。
MORTIMER? Come on. Pick up.
MORTIMER？いい加減にして。選び出す。
CUT TO:? ext. hotel bar - day? A fiercely gorgeous brunette sips the last of something from a rocks glass. This is REBECCA.
カット：？内線ホテルバー-日？激しくゴージャスなブルネットは、ロックグラスから何かの最後をすすり出します。これがレベッカです。
Behind her, a dark FIGURE approaches. She seems not to notice.
彼女の後ろで、暗い図が近づいています。彼女は気づかないようです。
REBECCA?(to Bartender) Rittenhouse, neat.
レベッカ？（バーテンダーへ）リッテンハウス、きちんと。
FIGURE (O.S.) ^ Ritenhouse, neat.
ふぃぐれ （お。Ｓ。） ＾ りてんほうせ、 ねあｔ。
She turns to find the source of the voice.
彼女は振り返って声の出所を見つけます。
FIGURE Excellent choice.
図優れた選択。
Before she can reply, her phone RINGS.?
彼女が返信する前に、電話が鳴ります。
> INTERCUT WITH:?
> INTERCUT WITH :?
.THE BOXCAR
.THE BOXCAR
Where MORTIMER is just barely holding on to life.
MORTIMERが辛うじて生き続けているところ。
Figure 4: Fountain Example
図4：噴水の例
CommonMark is like Markdown.
CommonMarkはMarkdownに似ています。
Here are some entity names that you can use with CommonMark: `
& © Æ Ď ¾ ℋ ⅆ
∲`
You can see more at [the CommonMark website](http://commonmark.org/ "CommonMark").
詳しくは、[CommonMark Webサイト]（http://commonmark.org/ "CommonMark"）を参照してください。
- foo *** - bar
- foo ***-バー
Tildes can be used for fenced code blocks:
チルダは、fencedコードブロックに使用できます。
~~~
<
>
~~~
Figure 5: CommonMark Example
図5：CommonMarkの例
---
title: STUN/TURN using PHP in Despair
abbrev: STuPiD-excerpt
docname: draft-hartke-xmpp-stupid-excerpt-00
date: 2009-07-05
category: info
ipr: trust200902 area: General workgroup: XMPP Working Group keyword: Internet-Draft
ipr：trust200902エリア：一般ワークグループ：XMPPワーキンググループキーワード：Internet-Draft
stand_alone: yes pi: [toc, sortrefs, symrefs]
stand_alone：はいpi：[toc、sortrefs、symrefs]
author: - ins: K. Hartke name: Klaus Hartke email: example@tzi.org
著者：-ins：K. Hartke名前：Klaus Hartkeメール：example@tzi.org
normative: RFC2119:
標準：RFC2119：
informative:
RFC5389:
STUNT:
target: http://www.example.com/oob
title: STUNT & out-of-band channels
author:
name: Robbie Hanson
ins: R. Hanson
date: 2007-09-17
--- abstract
NAT (Network Address Translator) Traversal may require TURN (Traversal Using Relays around NAT) functionality in certain cases that are not unlikely to occur. There is little incentive to deploy TURN servers, except by those who need them—who may not be in a position to deploy a new protocol on an Internet-connected node, in particular not one with deployment requirements as high as those of TURN.
NAT（Network Address Translator）トラバーサルでは、発生する可能性が低い特定のケースで、TURN（NATの周りにリレーを使用するトラバーサル）機能が必要になる場合があります。 TURNサーバーをデプロイするインセンティブはほとんどありませんが、インターネット接続ノードに新しいプロトコルをデプロイする立場にない場合や、特にTURNのデプロイメント要件ほど高いものがない場合を除きます。 。
--- middle
Introduction {#problems}
============
"STUN/TURN using PHP in Despair" is a highly deployable protocol for obtaining TURN-like functionality, while also providing the most important function of STUN {{RFC5389}}.
「DespairでPHPを使用したSTUN / TURN」は、TURNに似た機能を取得するための高度に展開可能なプロトコルであり、STUN {{RFC5389}}の最も重要な機能も提供します。
The Need for Standardization {#need}
----------------------------
Having one standard form of STuPiD service instead of one specific to each kind of client also creates an incentive for optimized implementations.
各種類のクライアントに固有のSTuPiDサービスではなく、1つの標準形式のSTuPiDサービスを使用すると、最適化された実装に対するインセンティブも生まれます。
~~~~~~~~~~
STuPiD ```````````````````````````````,
Script <----------------------------. ,
| ,
^ , | ,
| , | ,
(1) | , | , (3)
POST | , | , GET
| , | ,
| v | v
Peer A -----------------------> Peer B
(2)
out-of-band
Notification
~~~~~~~~~~
{: #figops title="STuPiD Protocol Operation"}
Terminology {#Terminology}
-----------
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
{{RFC2119}} and indicate requirement levels for compliant STuPiD
implementations.
--- back
Sample Implementation {#impl}
=====================
~~~~~~~~~~
<?php
header("Cache-Control: no-cache, must-revalidate");
header("Expires: Sat, 26 Jul 1997 05:00:00 GMT");
header("Content-Type: application/octet-stream");
?>
~~~~~~~~~~
{: #figimpl title="STuPiD Sample Implementation"}
Figure 6: Markdown for RFCs Example
図6：RFCの例のマークダウン
Pandoc2rfc expects multiple files as input. The following figure is example of "middle.mkd".
Pandoc2rfcは、入力として複数のファイルを想定しています。次の図は、「middle.mkd」の例です。
# Introduction
＃ 前書き
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc subcompact="no"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
This document presents a technique for using Pandoc syntax as a source format for documents in the Internet-Drafts (I-Ds) and Request for Comments (RFC) series.
このドキュメントでは、インターネットドラフト（I-D）およびリクエストオブコメント（RFC）シリーズのドキュメントのソース形式としてPandoc構文を使用するためのテクニックを紹介します。
This version is adapted to work with `xml2rfc` version 2.x.
このバージョンは、 `xml2rfc`バージョン2.xで動作するように適合されています。
Pandoc is an "almost plain text" format and therefore particularly well suited for editing RFC-like documents.
Pandocは「ほぼプレーンテキスト」形式であるため、RFCのようなドキュメントの編集に特に適しています。
> Note: this document is typeset in Pandoc.
>注：このドキュメントはPandocでタイプセットされています。
> NB: this is mostly text to test Pandoc2rfc, the canonical > documentation is [RFC 7328][p2r].
>注意：これは主にPandoc2rfcをテストするためのテキストです。正規のドキュメントは[RFC 7328] [p2r]です。
[p2r]: http://www.rfc-editor.org/info/rfc7328
# Pandoc to RFC
＃RFCへのパンドック
> Pandoc2rfc -- designed to do the right thing, until it doesn't.
> Pandoc2rfc-正しく機能しないように設計されています。
When writing [](#RFC4641) we directly wrote the XML. Needless to say it was tedious even though the XML of [xml2rfc](http://xml2rfc.ietf.org/) is very "light". The [latest version of xml2rfc version 2 can be found here](http://pypi.python.org/pypi/xml2rfc/).
[]（＃RFC4641）を書くとき、XMLを直接書きました。言うまでもなく、[xml2rfc]（http://xml2rfc.ietf.org/）のXMLは非常に「軽量」ですが、これは退屈な作業でした。 [xml2rfcバージョン2の最新バージョンはこちら]（http://pypi.python.org/pypi/xml2rfc/）です。
Figure 7: Pandoc2rfc Example (middle.mkd)
図7：Pandoc2rfcの例（middle.mkd）
IANA has registered the syntaxes specified in Section 3 in the "Markdown Variants" registry.
IANAは、セクション3で指定された構文を「Markdown Variants」レジストリに登録しました。
See the respective syntax descriptions and output media type registrations for their respective security considerations.
それぞれのセキュリティに関する考慮事項については、それぞれの構文の説明と出力メディアタイプの登録を参照してください。
[MARKDOWN] Gruber, J., "Daring Fireball: Markdown", December 2004, <http://daringfireball.net/projects/markdown/>.
[MARKDOWN] Gruber、J。、「Daring Fireball：Markdown」、2004年12月、<http://daringfireball.net/projects/markdown/>。
[MDSYNTAX] Gruber, J., "Daring Fireball: Markdown Syntax Documentation", <http://daringfireball.net/projects/markdown/syntax>.
[MDSYNTAX] Gruber、J。、「Daring Fireball：Markdown Syntax Documentation」、<http://daringfireball.net/projects/markdown/syntax>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <http://www.rfc-editor.org/info/rfc5322>.
[RFC5322] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、DOI 10.17487 / RFC5322、2008年10月、<http://www.rfc-editor.org/info/rfc5322>。
[RFC6657] Melnikov, A. and J. Reschke, "Update to MIME regarding "charset" Parameter Handling in Textual Media Types", RFC 6657, DOI 10.17487/RFC6657, July 2012, <http://www.rfc-editor.org/info/rfc6657>.
[RFC6657] Melnikov、A。およびJ. Reschke、「テキストメディアタイプの "charset"パラメータ処理に関するMIMEの更新」、RFC 6657、DOI 10.17487 / RFC6657、2012年7月、<http：//www.rfc-editor。 org / info / rfc6657>。
[RFC7763] Leonard, S., "The text/markdown Media Type", RFC 7763, DOI 10.17487/RFC7763, March 2016, <http://www.rfc-editor.org/info/rfc7763>.
[RFC7763]レナードS.、「テキスト/マークダウンメディアタイプ」、RFC 7763、DOI 10.17487 / RFC7763、2016年3月、<http://www.rfc-editor.org/info/rfc7763>。
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version 8.0", (Mountain View, CA: The Unicode Consortium, 2015. ISBN 978-1-936213-10-8), <http://www.unicode.org/versions/Unicode8.0.0/>.
[UNICODE] Unicodeコンソーシアム「The Unicode Standard、Version 8.0」（Mountain View、CA：The Unicode Consortium、2015. ISBN 978-1-936213-10-8）、<http://www.unicode.org /versions/Unicode8.0.0/>。
[HUMANE] Atwood, J., "Is HTML a Humane Markup Language?", May 2008, <http://blog.codinghorror.com/ is-html-a-humane-markup-language/>.
[人間] Atwood、J。、「HTMLは人道的なマークアップ言語ですか？」、2008年5月、<http://blog.codinghorror.com/ is-html-a-humane-markup-language />。
[DIN2MD] Gruber, J., "Dive Into Markdown", March 2004, <http://daringfireball.net/2004/03/dive_into_markdown>.
[DIN2MD] Gruber、J。、「Dive Into Markdown」、2004年3月、<http://daringfireball.net/2004/03/dive_into_markdown>。
[MD102b8] Gruber, J., "Subject: [ANN] Markdown.pl 1.0.2b8", message to the markdown-discuss mailing list, 9 May 2007, <http://six.pairlist.net/pipermail/markdown-discuss/ 2007-May/000615.html>, <http://daringfireball.net/projects/downloads/ Markdown_1.0.2b8.tbz>.
[MD102b8] Gruber、J。、「件名：[ANN] Markdown.pl 1.0.2b8」、markdown-discussメーリングリストへのメッセージ、2007年5月9日、<http://six.pairlist.net/pipermail/markdown-説明/ 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>.
[CATPICS]グルーバーJ.およびM.アーメント、「トークショー：Ep。88：「猫の写真」（サイド1）」、2014年7月、<http://daringfireball.net/thetalkshow/2014/07/19 / ep-088>。
[INETMEME] Solon, O., "Richard Dawkins on the internet's hijacking of the word 'meme'", June 2013, <http://www.wired.co.uk/news/archive/2013-06/20/ richard-dawkins-memes>, <http://www.webcitation.org/6HzDGE9Go>.
[INETMEME] Solon、O。、「インターネットでのリチャードドーキンスの「meme」という単語のハイジャック」、2013年6月、<http://www.wired.co.uk/news/archive/2013-06/20/ richard -dawkins-memes>、<http://www.webcitation.org/6HzDGE9Go>。
[MULTIMD] Penney, F., "MultiMarkdown", <http://fletcherpenney.net/multimarkdown/>.
[MULTIMD] Penney、F。、「MultiMarkdown」、<http://fletcherpenney.net/multimarkdown/>。
[PANDOC] MacFarlane, J., "Pandoc", <http://johnmacfarlane.net/pandoc/>.
[PANDOC] MacFarlane、J。、「Pandoc」、<http://johnmacfarlane.net/pandoc/>。
[RAILFROG] Railfrog Team, "Railfrog", April 2009, <http://railfrog.com/>.
[RAILFROG] Railfrogチーム、「Railfrog」、2009年4月、<http://railfrog.com/>。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<http://www.rfc-editor.org/info/rfc793>。
[RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", RFC 6533, DOI 10.17487/RFC6533, February 2012, <http://www.rfc-editor.org/info/rfc6533>.
[RFC6533] Hansen、T。、編、Newman、C。、およびA. Melnikov、「Internationalized Delivery Status and Disposition Notifications」、RFC 6533、DOI 10.17487 / RFC6533、2012年2月、<http：//www.rfc- editor.org/info/rfc6533>。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-editor.org/info/rfc6838>.
[RFC6838] Freed、N.、Klensin、J。、およびT. Hansen、「メディアタイプの仕様と登録手順」、BCP 13、RFC 6838、DOI 10.17487 / RFC6838、2013年1月、<http：//www.rfc- editor.org/info/rfc6838>。
[XML1.0-5] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", W3C Recommendation REC-xml-20081126, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126>.
[XML1.0-5] Bray、T.、Paoli、J.、Sperberg-McQueen、M.、Maler、E。、およびF. Yergeau、「Extensible Markup Language（XML）1.0（Fifth Edition）」、W3C勧告REC-xml-20081126、2008年11月、<http://www.w3.org/TR/2008/REC-xml-20081126>。
[OCCASION] Shieber, S., "Switching to Markdown for scholarly article production", August 2014, <http://blogs.law.harvard.edu/pamphlet/2014/08/29/ switching-to-markdown-for-scholarly-article-production/>.
[機会] Shieber、S。、「学術論文の作成のためのMarkdownへの切り替え」、2014年8月、<http://blogs.law.harvard.edu/pamphlet/2014/08/29/ Switching-to-markdown-for- scholarly-article-production />。
[FOUNTAIN] Maschwitz, S. and J. August, "Fountain | A markup language for screenwriting.", <http://fountain.io/>.
[FOUNTAIN] Maschwitz、S。およびJ. August、「Fountain |スクリーンライティング用のマークアップ言語」、<http://fountain.io/>。
[MATHDOWN] Cherniavsky-Paskin, B., "math in markdown", <https://github.com/cben/mathdown/wiki/math-in-markdown>.
[MATHDOWN] Cherniavsky-Paskin、B。、「math in markdown」、<https://github.com/cben/mathdown/wiki/math-in-markdown>。
[SVN] Apache Subversion, December 2015, <https://subversion.apache.org/>.
[SVN] Apache Subversion、2015年12月、<https://subversion.apache.org/>。
[GIT] Git, <http://git-scm.com/>.
[GIT]行って、<http://git-scm.com/>。
Author's Address
著者のアドレス
Sean Leonard Penango, Inc. 5900 Wilshire Boulevard 21st Floor Los Angeles, CA 90036 United States
Sean Leonard Penango、Inc. 5900 Wilshire Boulevard 21st Floor Los Angeles、CA 90036アメリカ
EMail: dev+ietf@seantek.com
URI: http://www.penango.com/