[要約] RFC 7763は、text/markdownメディアタイプの仕様を定義しています。このRFCの目的は、Markdown形式のテキストを正確に表現し、相互運用性を向上させることです。
Internet Engineering Task Force (IETF) S. Leonard
Request for Comments: 7763 Penango, Inc.
Category: Informational March 2016
ISSN: 2070-1721
The text/markdown Media Type
テキスト/マークダウンメディアタイプ
Abstract
概要
This document registers 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.
このドキュメントは、オプションで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/rfc7763.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7763で入手できます。
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. This Is Markdown! Or: Markup and Its Discontents . . . . . 2
1.2. Markdown Is About Writing and Editing . . . . . . . . . . . 3
1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Markdown Media Type Registration Application . . . . . . . . . 5
3. Fragment Identifiers . . . . . . . . . . . . . . . . . . . . . 8
3.1. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Content Disposition and preview-type . . . . . . . . . . . . . 9
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6.1. Markdown Variants . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
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]. (On the other end is binary data, which computer systems store and process with bit-for-bit accuracy.) Many of these standards include control characters that are used as in-band signaling to cause effects other than the addition of a symbol (or grapheme) to the text.
コンピュータシステムでは、テキストデータは一連の技術を使用して保存および処理されます。一方はプレーンテキストです。コンピュータでエンコードされたテキストで、特定の規格のコードポイントのシーケンスのみで構成され、他のフォーマットや構造情報はありません[UNICODE]。 （もう一方の端はバイナリデータであり、コンピューターシステムはビット単位の精度で保存および処理します。）これらの標準の多くには、記号の追加以外の効果を引き起こすインバンドシグナリングとして使用される制御文字が含まれています（または書記素）をテキストに。
Markup offers an alternative means to encode this signaling information by overloading certain graphic characters (see, e.g., [ISO646]) with additional meanings. Therefore, markup languages allow for annotating a document in a syntactically distinguishable way from the text, while keeping the annotations printable. Markup languages are (reasonably) well-specified and tend to follow (mostly) standardized syntax rules. Examples of formal markup languages include Standard Generalized Markup Language (SGML), HTML, XML, and LaTeX. Standardized rules lead to interoperability between markup processors, but they impose skill requirements on new users that lead to markup languages becoming less accessible to beginners. These rules also reify "validity": content that does not conform to the rules is treated differently (i.e., is rejected) than content that conforms.
マークアップは、特定のグラフィック文字（[ISO646]などを参照）を追加の意味でオーバーロードすることにより、このシグナリング情報をエンコードする代替手段を提供します。したがって、マークアップ言語では、注釈を印刷可能に保ちながら、テキストとは構文的に区別可能な方法でドキュメントに注釈を付けることができます。マークアップ言語は（合理的に）十分に指定されており、（ほとんど）標準化された構文規則に従う傾向があります。形式的なマークアップ言語の例には、標準の一般化されたマークアップ言語（SGML）、HTML、XML、およびLaTeXが含まれます。標準化されたルールはマークアッププロセッサ間の相互運用性につながりますが、初心者がマークアップ言語にアクセスしにくくなることにつながる新しいユーザーにスキル要件を課します。これらのルールは「有効性」も具体化します。ルールに準拠していないコンテンツは、準拠しているコンテンツとは異なる方法で処理されます（つまり、拒否されます）。
In contrast to formal markup languages, lightweight markup languages use simple syntaxes; they are designed to be easy for humans to enter and understand with basic text editors. Markdown, the subject of this document, began as an /informal/ plain-text formatting syntax [MDSYNTAX] and Perl script HTML/XHTML processor [MARKDOWN] targeted at non-technical users using unspecialized tools, such as plain-text email clients. [MDSYNTAX] explicitly rejects the notion of validity: there is no such thing as "invalid" Markdown. If the Markdown content does not result in the "right" output (defined as output that the author wants, not output that adheres to some dictated system of rules), the expectation is that the author should continue experimenting by changing the content or the processor to achieve the desired output.
形式的なマークアップ言語とは対照的に、軽量のマークアップ言語は単純な構文を使用します。基本的なテキストエディタを使用して、人間が簡単に入力して理解できるように設計されています。このドキュメントの主題であるMarkdownは、/テキスト形式の書式設定構文[MDSYNTAX]およびPerlスクリプトHTML / XHTMLプロセッサ[MARKDOWN]として始まり、プレーンテキストのメールクライアントなどの専門知識のないツールを使用する非技術的なユーザーを対象としています。 [MDSYNTAX]は有効性の概念を明示的に拒否します。「無効な」Markdownのようなものはありません。マークダウンコンテンツが「正しい」出力（作成者が必要とする出力であり、規定のルールシステムに準拠する出力ではない）にならない場合、作成者はコンテンツまたはプロセッサを変更して実験を続ける必要があります。望ましい出力を達成するため。
Since its development in 2004 [MARKDOWN], a number of web- and Internet-facing applications have incorporated Markdown into their text-entry systems, frequently with custom extensions. Markdown has thus evolved into a kind of Internet meme [INETMEME] as different communities encounter it and adapt the syntax for their specific use cases. Markdown now represents a family of related plain-text formatting syntaxes and implementations that, while broadly compatible with humans [HUMANE], are intended to produce different kinds of outputs that push the boundaries of mutual intelligibility between software systems.
2004年の開発[MARKDOWN]以降、多くのWebおよびインターネット向けアプリケーションがMarkdownをテキスト入力システムに組み込んでおり、その多くはカスタム拡張機能を備えています。マークダウンは、さまざまなコミュニティが遭遇し、構文を特定のユースケースに適合させることで、一種のインターネットミーム[INETMEME]に進化しました。 Markdownは、人間と広く互換性がある[HUMANE]ながら、ソフトウェアシステム間の相互了解度の境界を押し広げるさまざまな種類の出力を生成することを目的とした、関連するプレーンテキストフォーマット構文および実装のファミリーを表します。
To support identifying and conveying Markdown, this document defines a media type and parameters that indicate the Markdown author's intent on how to interpret the content. This registration draws particular inspiration from text/troff [RFC4263], which is a plain-text formatting syntax for typesetting based on tools from the 1960s ("RUNOFF") and 1970s ("nroff", et al.). In that sense, Markdown is a kind of troff for modern computing. A companion document [RFC7764] provides additional Markdown background, philosophy, local storage strategies, and variant registrations (including examples).
Markdownの識別と伝達をサポートするために、このドキュメントでは、コンテンツの解釈方法に関するMarkdown作成者の意図を示すメディアタイプとパラメーターを定義しています。この登録は、1960年代（ "RUNOFF"）および1970年代（ "nroff"など）のツールに基づく組版用の平文フォーマット構文であるtext / troff [RFC4263]から特にインスピレーションを得ています。その意味で、Markdownは現代のコンピューティングにとって一種のtroffです。関連ドキュメント[RFC7764]は、追加のMarkdownの背景、哲学、ローカルストレージ戦略、およびバリアント登録（例を含む）を提供します。
"HTML is a *publishing* format; Markdown is a *writing* format.
Thus, Markdown's formatting syntax only addresses issues that can
be conveyed in plain text." [MDSYNTAX]
The paradigmatic use case for text/markdown is the Markdown editor: an application that presents Markdown content (which looks like an email or other piece of plain-text writing) alongside a published format, so that an author can see results instantaneously and can tweak his or her input in real time. A significant number of Markdown editors have adopted "split-screen view" (or "live preview") technology that looks like Figure 1.
テキスト/マークダウンの典型的な使用例は、Markdownエディターです。Markdownのコンテンツ（電子メールやその他のプレーンテキストの文章のように見える）を公開済みの形式と一緒に表示するアプリケーションです。これにより、作成者は結果を即座に確認し、微調整できます。リアルタイムで彼または彼女の入力。かなりの数のMarkdownエディターが、図1のような「分割画面ビュー」（または「ライブプレビュー」）テクノロジーを採用しています。
+----------------------------------------------------------------------+
| File Edit (Cloud Stuff) (Fork Me on GitHub) Help |
+----------------------------------------------------------------------+
| [ such-and-such identifier ] [ useful statistics] |
+----------------------------------++----------------------------------+
| (plain text, with || (text/html, likely |
| syntax highlighting) || rendered to screen) |
| || |
|# Introduction ||<h1>Introduction</h1> |
| || |
|## Markdown Is About Writing and /|<h2>Markdown Is About Writing and |
/ Editing ||Editing</h2> |
| || |
|> HTML is a *publishing* format; ||<blockquote><p>HTML is a |
|> Markdown is a *writing* format. || <em>publishing</em> format; |
|> Thus, Markdown's formatting || Markdown is a <em>writing</em> |
|> syntax only addresses issues || format. Thus, Markdown's |
|> that can be conveyed in plain <> formatting syntax only addresses |
|> text. [MDSYNTAX][] || issues that can be conveyed in |
| || plain text. <a href="http://darin/
|The paradigmatic use case for |/gfireball.net/projects/markdown/sy/
|`text/markdown` is the Markdown |/ntax#html" title="Markdown: Syntax/
|editor: an application that |/: HTML">MDSYNTAX</a> |
|presents Markdown content ||</p></blockquote> |
|... || |
| ||<p>The paradigmatic use case for |
|[MDSYNTAX]: http://daringfireball./| <code>text/markdown</code> is the|
/net/projects/markdown/syntax#html || Markdown editor: an application |
|"Markdown: Syntax: HTML" || that presents Markdown content |
| || ...</p> |
+----------------------------------++----------------------------------+
LEGEND: "/" embedded in a vertical line represents a line-continuation marker, since a line break is not supposed to occur in that content.
凡例：垂直線に埋め込まれた「/」は、行継続マーカーを表します。これは、そのコンテンツで改行が発生することは想定されていないためです。
Figure 1: Markdown Split-Screen / Live Preview Editor
図1：Markdown分割画面/ライブプレビューエディター
To get the best results, implementations ought to produce and consume mutually intelligible and identifiable bits of Markdown. That way, users on diverse platforms can collaborate with their tools of choice. Those tools can be desktop-based (MarkdownPad, MultiMarkdown Composer); browser-based (Dillinger, Markable); integrated widgets (Discourse, GitHub); general-purpose editors (emacs, vi); or plain old "Notepad". Additionally, implementations ought to have common ways to identify particular areas of Markdown content when the Markdown becomes appreciably large (e.g., book chapters and Internet-Drafts -- not just blog posts). So that users have the option to use Markdown in MIME-capable systems to convey their works in progress, not just their finished products (for which full-blown markups ranging from text/html to application/pdf are appropriate), implementations ought to label such Markdown content with a common media type: text/markdown. This registration facilitates interoperability between these Markdown editors by conveying the syntax of the particular Markdown variant and the desired output format.
最良の結果を得るには、実装はMarkdownの相互に理解可能で識別可能なビットを生成および消費する必要があります。このようにして、さまざまなプラットフォームのユーザーは、選択したツールを使用してコラボレーションできます。これらのツールはデスクトップベース（MarkdownPad、MultiMarkdown Composer）にすることができます。ブラウザベース（Dillinger、Markable）;統合されたウィジェット（ディスコース、GitHub）;汎用エディター（emacs、vi）;またはプレーンな「メモ帳」。さらに、実装には、Markdownがかなり大きくなったときにMarkdownコンテンツの特定の領域を識別する一般的な方法が必要です（たとえば、ブログの投稿だけでなく、本の章やインターネットドラフト）。ユーザーがMIME対応システムでMarkdownを使用して、完成した製品（text / htmlからapplication / pdfまでの本格的なマークアップが適切である）だけでなく、進行中の作業を伝えるために、実装にはラベルを付ける必要があります。一般的なメディアタイプ（テキスト/マークダウン）を持つこのようなマークダウンコンテンツ。この登録により、特定のMarkdownバリアントの構文と目的の出力形式を伝達することにより、これらのMarkdownエディター間の相互運用が容易になります。
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は、さまざまな程度の正式なドキュメントと実装を持つ関連フォーマットのファミリーを意味するため、この仕様では、「バリアント」という用語を使用してそのようなフォーマットを識別します。
This section provides the media type registration application for the text/markdown media type (see Section 5.6 of [RFC6838]).
このセクションでは、text / markdownメディアタイプのメディアタイプ登録アプリケーションを提供します（[RFC6838]のセクション5.6を参照）。
Type name: text
タイプ名：テキスト
Subtype name: markdown
サブタイプ名：markdown
Required parameters:
必須パラメーター：
charset: Per Section 4.2.1 of [RFC6838], charset is REQUIRED. There is no default value because neither [MDSYNTAX] nor many popular implementations at the time of this registration do either. [MDSYNTAX] clearly describes Markdown as a "writing format"; its syntax rules operate on characters (specifically, on punctuation) rather than code points. Many Markdown processors will get along just fine by operating on characters in the US-ASCII repertoire (specifically punctuation), blissfully oblivious to other characters or codes.
charset：[RFC6838]のセクション4.2.1に従って、charsetが必要です。この登録時に[MDSYNTAX]も一般的な実装も行われていないため、デフォルト値はありません。 [MDSYNTAX]はMarkdownを「書き込みフォーマット」として明確に説明しています。その構文規則は、コードポイントではなく文字（特に句読点）に作用します。多くのMarkdownプロセッサは、US-ASCIIレパートリー（特に句読点）の文字を操作することで、他の文字やコードに気付かずにうまく行きます。
Optional parameters:
オプションのパラメーター：
variant: An optional identifier of the specific Markdown variant that the author intended. The value serves as a "hint" to the recipient, meaning that the recipient MAY interpret the Markdown as that variant, but is under no obligation to do so. When omitted, there is no hint; the interpretation is entirely up to the receiver and context. This identifier is plain US-ASCII and case-insensitive. To promote interoperability, identifiers can be registered in the registry defined in Section 6. If a receiver does not recognize the variant identifier, the receiver MAY present the identifier to a user to inform him or her of it.
バリアント：著者が意図した特定のMarkdownバリアントのオプションの識別子。値は受信者への「ヒント」として機能します。つまり、受信者はMarkdownをそのバリアントとして解釈してもかまいませんが、そうする義務はありません。省略した場合、ヒントはありません。解釈は完全にレシーバとコンテキスト次第です。この識別子はプレーンなUS-ASCIIで、大文字と小文字は区別されません。相互運用性を促進するために、セクション6で定義されたレジストリに識別子を登録できます。受信者がバリアント識別子を認識しない場合、受信者は識別子をユーザーに提示して通知することができます。
Other parameters MAY be included with the media type. The variant SHOULD define the semantics of such other parameters. Additionally, the variant MAY be registered under another media type; this text/markdown registration does not preclude other registrations.
他のパラメータは、メディアタイプに含まれる場合があります。バリアントは、そのような他のパラメーターのセマンティクスを定義する必要があります（SHOULD）。さらに、バリアントは別のメディアタイプで登録される場合があります。このテキスト/マークダウン登録は他の登録を妨げません。
Encoding considerations:
エンコードに関する考慮事項：
Markdown content is plain-text content; any octet sequence is valid as long as it conforms to the character codes of the charset parameter. See [RFC2046]. Markup characters in [MDSYNTAX] are limited to printable US-ASCII; however, other variants can define markup characters outside this range (including control characters such as NUL and characters encoded in multiple octets).
マークダウンコンテンツはプレーンテキストコンテンツです。 charsetパラメータの文字コードに準拠している限り、どのオクテットシーケンスも有効です。 [RFC2046]を参照してください。 [MDSYNTAX]のマークアップ文字は、印刷可能なUS-ASCIIに制限されています。ただし、他のバリアントはこの範囲外のマークアップ文字（NULなどの制御文字や複数のオクテットでエンコードされた文字を含む）を定義できます。
Security considerations:
セキュリティに関する考慮事項：
Markdown interpreted as plain text is relatively harmless. A text editor need only display the text. The editor SHOULD take care to handle control characters appropriately and to limit the effect of the Markdown to the text-editing area itself; malicious Unicode-based Markdown could, for example, surreptitiously change the directionality of the text. An editor for normal text would already take these control characters into consideration, however.
プレーンテキストとして解釈されるMarkdownは比較的無害です。テキストエディターは、テキストを表示するだけで済みます。エディタは、制御文字を適切に処理し、Markdownの効果をテキスト編集領域自体に制限するように注意する必要があります。たとえば、悪意のあるUnicodeベースのMarkdownは、テキストの方向性を不正に変更する可能性があります。ただし、通常のテキストのエディターでは、これらの制御文字がすでに考慮されています。
Markdown interpreted as a precursor to other formats, such as HTML, carries all of the security considerations as the target formats. For example, HTML can contain instructions to execute scripts, redirect the user to other web pages, download remote content, and upload personally identifiable information. Markdown also can contain islands of formal markup, such as HTML. These islands of formal markup may be passed as they are, transformed, or ignored (perhaps because the islands are conditional or incompatible) when the Markdown is processed. Since Markdown may have different interpretations depending on the tool and the environment, a better approach is to analyze (and sanitize or block) the output markup, rather than attempting to analyze the Markdown.
HTMLなどの他の形式の前兆として解釈されるMarkdownは、ターゲット形式としてすべてのセキュリティ上の考慮事項を備えています。たとえば、HTMLには、スクリプトの実行、ユーザーの別のWebページへのリダイレクト、リモートコンテンツのダウンロード、個人を特定できる情報のアップロードなどの指示を含めることができます。 Markdownには、HTMLなどの正式なマークアップのアイランドを含めることもできます。これらのフォーマルマークアップのアイランドは、Markdownの処理時にそのまま渡されるか、変換されるか、無視されます（アイランドが条件付きまたは互換性がないためと考えられます）。 Markdownの解釈はツールや環境によって異なる可能性があるため、Markdownを分析するよりも、出力マークアップを分析（およびサニタイズまたはブロック）する方が適切です。
Interoperability considerations:
相互運用性に関する考慮事項：
Markdown variations (some might say "innovations") are designed to be broadly compatible with humans ("humane"), but not necessarily with each other. Therefore, syntax in one Markdown derivative may be ignored or treated differently in another derivative. The overall effect is a general degradation of the output that increases with the quantity of variant-specific Markdown used in the text. When it is desirable to reflect the author's intent in the output, stick with the variant identified in the variant parameter, i.e., receivers SHOULD only accept Markdown variants that they explicitly know about, and senders SHOULD avoid use of variants that intended recipients are not known to understand.
マークダウンのバリエーション（「革新」と言う人もいます）は、人間（「人道的」）と広く互換性があるように設計されていますが、必ずしも互いに互換性があるとは限りません。したがって、あるMarkdown導関数の構文は無視されるか、別の導関数では異なる扱いを受けることがあります。全体的な影響は、テキストで使用されるバリアント固有のMarkdownの量とともに増加する出力の一般的な低下です。出力に著者の意図を反映することが望ましい場合は、バリアントパラメータで識別されたバリアントを使用します。つまり、受信者は明示的に知っているMarkdownバリアントのみを受け入れるべきであり、送信者は、意図された受信者が知られていないバリアントの使用を避けるべきです（SHOULD）。理解する。
Published specification: This specification; [MDSYNTAX].
公開された仕様：この仕様。 [MDSYNTAX]。
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Markdown conversion tools, Markdown WYSIWYG (What You See is What You Get) editors, and plain-text editors and viewers; markup processor targets indirectly use Markdown (e.g., web browsers for Markdown converted to HTML).
Markdown変換ツール、Markdown WYSIWYG（What You See is What You Get）エディター、プレーンテキストエディターとビューアー。マークアッププロセッサターゲットは、Markdownを間接的に使用します（たとえば、HTMLに変換されたMarkdownのWebブラウザ）。
Fragment identifier considerations:
フラグメント識別子の考慮事項：
See Section 3.
セクション3を参照してください。
Additional information:
追加情報：
Magic number(s): None File extension(s): .md, .markdown Macintosh file type code(s): TEXT. A uniform type identifier (UTI) of "net.daringfireball.markdown", which conforms to "public.plain-text", is RECOMMENDED [MDUTI]. See [RFC7764] for other considerations.
マジックナンバー：なしファイル拡張子：.md、.markdown Macintoshファイルタイプコード：TEXT。 「net.daringfireball.markdown」の統一型識別子（UTI）は「public.plain-text」に準拠しており、推奨[MDUTI]です。その他の考慮事項については、[RFC7764]を参照してください。
Person & email address to contact for further information:
詳細について連絡する人とメールアドレス：
Sean Leonard <dev+ietf@seantek.com>
Restrictions on usage: None.
使用制限：なし。
Author/Change controller: Sean Leonard <dev+ietf@seantek.com>
Intended usage: COMMON
使用目的：COMMON
Provisional registration? No Implementations SHOULD record the value of the variant parameter (and other parameters if defined by the variant) along with the Markdown content when the content leaves the domain of formats that are Internet media type capable. Strategies for doing so are discussed in [RFC7764].
仮登録？実装は、コンテンツがインターネットメディアタイプに対応するフォーマットのドメインを離れたときに、Markdownコンテンツと共にバリアントパラメーター（およびバリアントで定義されている場合は他のパラメーター）の値を記録する必要があります（SHOULD）。そうするための戦略は[RFC7764]で議論されています。
The Content-Disposition header (particularly the preview-type parameter) can be used with Markdown content. See Section 4.
Content-Dispositionヘッダー（特にpreview-typeパラメーター）は、Markdownコンテンツで使用できます。セクション4を参照してください。
[MARKDOWN] does not define any fragment identifiers, but some variants do, and many types of Markdown processor output (e.g., HTML or PDF) will have well-defined fragment identifiers. Which fragment identifiers are available for a given document are variant-defined.
[MARKDOWN]はフラグメント識別子を定義していませんが、一部のバリアントは定義しています。多くのタイプのMarkdownプロセッサ出力（HTMLやPDFなど）には、明確に定義されたフラグメント識別子があります。特定のドキュメントで使用できるフラグメント識別子は、バリアント定義です。
When encoded in a URI, characters that are outside of the fragment production of [RFC3986] are percent-encoded. The default encoding (character set) of percent-encoded octets in URIs is the same as the Markdown content, which is identified by the charset parameter or by other contextual means. Fragment identifiers SHOULD be considered case-sensitive, which maintains consistency with HTML. Variants MAY override the guidance in this paragraph.
URIでエンコードされると、[RFC3986]のフラグメント生成の外にある文字はパーセントエンコードされます。 URIのパーセントでエンコードされたオクテットのデフォルトのエンコーディング（文字セット）は、charsetパラメーターまたは他のコンテキスト手段によって識別されるMarkdownコンテンツと同じです。フラグメント識別子は、HTMLとの一貫性を維持する大文字と小文字を区別する必要があります。バリアントは、この段落のガイダンスをオーバーライドしてもよい（MAY）。
At least the first equals sign "=" SHOULD be percent-encoded to prevent ambiguity as described in the following section.
少なくとも最初の等号「=」は、次のセクションで説明するように、あいまいさを防ぐためにパーセントでエンコードする必要があります（SHOULD）。
Similar to application/pdf [RFC3778] and text/plain [RFC5147], this registration permits a parameter syntax for fragment identifiers. The syntax is a parameter name, the equals sign "=" (which MUST NOT be percent-encoded), and a parameter value. To the extent that multiple parameters can appear in a fragment production, the parameters SHALL be separated by the ampersand "&" (which MUST NOT be percent-encoded).
application / pdf [RFC3778]およびtext / plain [RFC5147]と同様に、この登録はフラグメント識別子のパラメーター構文を許可します。構文は、パラメーター名、等号 "="（パーセントでエンコードしてはなりません）、およびパラメーター値です。複数のパラメーターがフラグメント生成に現れることができる範囲で、パラメーターはアンパサンド "＆"で区切られる必要があります（これはパーセントでエンコードされてはいけません）。
The only parameter defined in this registration is "line", which has the same meaning as in [RFC5147], i.e., counting is zero-based. For example: "#line=10" identifies the eleventh line of Markdown input. Implementers should take heed that different environments and character sets may have a wide range of code sequences to divide lines.
この登録で定義されている唯一のパラメータは「行」であり、これは[RFC5147]と同じ意味を持ちます。つまり、カウントはゼロベースです。例： "＃line = 10"は、Markdown入力の11行目を識別します。実装者は、さまざまな環境や文字セットに、行を分割するための幅広いコードシーケンスがあることに注意する必要があります。
Markdown variants are free to define additional parameters.
Markdownバリアントは、追加のパラメーターを自由に定義できます。
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.
Content-Dispositionヘッダー[RFC2183]は、パラメータのタイプとセットを使用して、MIMEエンティティに関するプレゼンテーション情報を伝えます。ここでは、プレビュータイプのパラメーターがMarkdownコンテンツに対して定義されています。
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 preview-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.
存在する場合、preview-typeは、作成者がプロセッサから要求したプレビュー出力のインターネットメディアタイプ（およびパラメーター）を示します。セクション1.3の「パラダイムユースケース」（つまり、協調的なMarkdown編集）を参照すると、preview-typeパラメーターは主にMarkdownエディターの「右側」に影響します。デフォルト値はありません。存在しない場合、Markdownユーザーエージェントは必要なものを何でもレンダリングまたは表示できます。
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]).
このパラメーターの値は、オプションのパラメーターを持つインターネットメディアタイプです。構文（大文字と小文字の区別に関する考慮事項を含む）は、Content-Typeヘッダーの[RFC2045]で指定されているものと同じです（[RFC2231]や[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 Outline Processor Markup Language (OPML), and even to entire e-books (e.g., [PANDOC]).
実装は、構文がそれらのマークアップ言語をターゲットとする範囲で、HTML（text / html）およびXHTML（application / xhtml + xml）出力を予測してサポートする必要があります（SHOULD）。これらのタイプは、現在の目的の大部分に適しているはずです。ただし、Markdownは、HTMLがターゲット出力ではないワークフローにますます不可欠になっています。例は、TeXからPDF、アウトラインプロセッサマークアップ言語（OPML）、さらには電子書籍全体（[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.
このパラメーター値の再帰メディアタイプtext / markdownは、作成者がMarkdown処理をまったく呼び出さないことを意味します。受信者はMarkdownソースをそのまま提示する必要があります（SHOULD）。
The preview-type parameter can be used for other types of content, but the precise semantics are not defined here.
preview-typeパラメーターは他のタイプのコンテンツに使用できますが、正確なセマンティクスはここでは定義されていません。
The following is an example of Markdown as an email attachment:
以下は、電子メールの添付ファイルとしてのMarkdownの例です。
MIME-Version: 1.0
Content-Type: text/markdown; charset=UTF-8; variant=Original
Content-Disposition: attachment; filename=readme.md;
preview-type="application/xhtml+xml"
Sample HTML 4 Markdown
=============
This is some sample Markdown. [Hooray!][foo]
(Remember that link identifiers are not case-sensitive.)
Bulleted Lists
-------
Here are some bulleted lists...
いくつかの箇条書きリストがあります...
* One Potato * Two Potato * Three Potato
* 1つのジャガイモ* 2つのジャガイモ* 3つのジャガイモ
- One Tomato - Two Tomato - Three Tomato
- 1つのトマト-2つのトマト-3つのトマト
More Information
-----------
[.markdown, .md](http://daringfireball.net/projects/markdown/) has more information.
[.markdown、.md]（http://daringfireball.net/projects/markdown/）に詳細情報があります。
[fOo]: http://example.com/loc 'Will Not Work with Markdown.pl-1.0.1'
IANA has registered the media type text/markdown using the application provided in Section 2 of this document.
IANAは、このドキュメントのセクション2で提供されるアプリケーションを使用して、メディアタイプのテキスト/マークダウンを登録しました。
IANA has registered preview-type in the "Content Disposition Parameters" subregistry of the "Content Disposition Values and Parameters" registry, with the following description: "Internet media type (and parameters) of the preview output desired from a processor by the author of the MIME content".
IANAは、「コンテンツディスポジションの値とパラメータ」レジストリの「コンテンツディスポジションパラメータ」サブレジストリにプレビュータイプを登録しました。以下の説明が含まれています。「作成者がプロセッサから要求したプレビュー出力のインターネットメディアタイプ（およびパラメータ） MIMEコンテンツ」。
IANA has established a registry called "Markdown Variants". While the registry has been created in the context of the text/markdown media type, the registry is intended for broad community use, so protocols and systems that do not rely on Internet media types can still tag Markdown content with a common variant identifier. Each entry in this registry shall consist of basic information about the variant: Identifier: unique identifier for the variant Name: the commonly known name of the variant Description: a prose description of the variant, including how it differs from other variants such as Original Additional Parameters*: additional Content-Type parameters Fragment Identifiers*: additional fragment identifier syntaxes and semantics References: URIs or other references to documentation Contact Information: whom to contact (email, URI, phone, address, etc.) Expiration Date^: when this provisional registration expires
IANAは「Markdown Variants」と呼ばれるレジストリを確立しています。レジストリはtext / markdownメディアタイプのコンテキストで作成されていますが、レジストリは幅広いコミュニティでの使用を目的としているため、インターネットメディアタイプに依存しないプロトコルとシステムは、Markdownコンテンツに共通のバリアント識別子でタグ付けできます。このレジストリの各エントリは、バリアントに関する基本情報で構成されます。識別子：バリアントの一意の識別子名前：バリアントの一般に知られている名前説明：バリアントの散文の説明。パラメータ*：追加のContent-Typeパラメータフラグメント識別子*：追加のフラグメント識別子の構文とセマンティクス参照：URIまたはドキュメントへの他の参照連絡先情報：連絡先（メール、URI、電話、アドレスなど）有効期限^：これがいつ仮登録期限切れ
* (optional) ^ (if provisional)
* （オプション）^（仮の場合）
While the variant parameter is "plain US-ASCII" (see registration template), the Identifier field (and by implication, all registered identifiers) SHALL conform to the ABNF [RFC5234]:
バリアントパラメータは「プレーンUS-ASCII」（登録テンプレートを参照）ですが、識別子フィールド（および暗黙的に、すべての登録済み識別子）はABNF [RFC5234]に準拠する必要があります。
ALPHA [*VCHAR (ALPHA / DIGIT)]
ALPHA [* VCHAR（ALPHA / DIGIT）]
For style and compatibility reasons, the Identifier field SHOULD conform to the ABNF:
スタイルと互換性の理由から、識別子フィールドはABNFに準拠する必要があります（SHOULD）。
ALPHA *( ["-" / "." / "_" / "~"] 1*(ALPHA / DIGIT) )
That is, the identifier MUST start with a letter and MAY contain punctuation in the middle, but not at the end: the last character MUST be alphanumeric. The second production uses the same characters 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 vernacular name of the variant.
つまり、識別子は文字で開始する必要があり、途中に句読点を含めることはできますが、最後にはできません。最後の文字は英数字でなければなりません。 2番目のプロダクションは[RFC3986]の「予約されていない」ルールと同じ文字を使用し、ファイル名などの他の識別システムの文字と互換性があるように設計されています。識別子はユーザーに表示される可能性があるため（特に、受信者が識別子を認識しない場合）、識別子はバリアントの固有名詞と合理的に関連付けられる必要があります（SHOULD）。
The Name, Description, Additional Parameters, Fragment Identifiers, References, and Contact Information fields SHALL be in a Unicode character set (e.g., UTF-8).
名前、説明、追加パラメーター、フラグメント識別子、参照、および連絡先フィールドは、Unicode文字セット（UTF-8など）である必要があります。
The registry includes the registration in Section 6.1.4 (Original Markdown). [RFC7764] includes additional registrations.
レジストリには、セクション6.1.4（元のマークダウン）での登録が含まれています。 [RFC7764]には追加の登録が含まれています。
The registry has the following identifiers RESERVED, as they have engendered some controversy in the Markdown community. No one is allowed to register them (or any case variations of them). These identifiers are not and cannot be registered: Standard Common Markdown
Markdownコミュニティでいくつかの論争が生じているため、レジストリには次の識別子が予約されています。それらを登録することはできません（またはそれらのケースバリエーション）。これらの識別子は登録されておらず、登録することもできません。StandardCommon Markdown
The registry includes the following text in the note field: The variant names Standard, Common, and Markdown are reserved and cannot be registered.
レジストリのメモフィールドに次のテキストが含まれています。バリアント名Standard、Common、Markdownは予約されているため、登録できません。
Registrations are made on a First Come, First Served [RFC5226] basis by anyone with a need to interoperate. While documentation is required, any level of documentation is sufficient; thus, neither Specification Required nor Expert Review are warranted. The checks prescribed by this section can be performed automatically.
登録は、相互運用が必要な人が先着順[RFC5226]で行います。文書化は必須ですが、あらゆるレベルの文書で十分です。したがって、「必要な仕様」も「エキスパートレビュー」も保証されません。このセクションで規定されているチェックは、自動的に実行できます。
All references (including contact information) MUST be verified as functional at the time of the registration.
すべての参照（連絡先情報を含む）は、登録時に機能していることを確認する必要があります。
As a special "escape valve", registrations can be updated with IETF Review [RFC5226]. All fields may be updated except the variant identifier, which is permanent: not even case may be changed.
特別な「エスケープバルブ」として、IETFレビュー[RFC5226]で登録を更新できます。永続的なバリアント識別子を除くすべてのフィールドが更新される可能性があります。大文字と小文字が変更されることはありません。
Any registrant may make a provisional registration to reserve a variant identifier. Only the variant identifier and contact information fields are required; the rest are optional. Provisional registrations expire after three months, after which time the variant 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.
登録者は、バリアント識別子を予約するために仮登録を行うことができます。バリアント識別子と連絡先情報フィールドのみが必須です。残りはオプションです。仮登録は3か月後に有効期限が切れます。その後、バリアント識別子を再利用できます。登録を永続化するには、登録者は仮登録と同じ識別子で永続登録を完了する必要があります。
The registry includes this initial variant. A conforming implementation that processes the variant parameter MUST recognize this variant (although the processing behavior is not defined here).
レジストリには、この最初の亜種が含まれています。バリアントパラメーターを処理する準拠実装は、このバリアントを認識しなければなりません（ただし、ここでは処理動作は定義されていません）。
Identifier: Original
識別子：オリジナル
Name: Markdown Description: Gruber's original Markdown syntax.
名前：Markdown説明：Gruberの元のMarkdown構文。
References: [MARKDOWN] [MDSYNTAX]
参照：[MARKDOWN] [MDSYNTAX]
Contact Information:
(individual) John Gruber <http://daringfireball.net/>
<comments@daringfireball.net>
See the Security considerations entry in Section 2.
セクション2のセキュリティに関する考慮事項のエントリを参照してください。
[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", December 2004, <http://daringfireball.net/projects/markdown/syntax>.
[MDSYNTAX] Gruber、J。、「Daring Fireball：Markdown Syntax Documentation」、2004年12月、<http://daringfireball.net/projects/markdown/syntax>。
[MDUTI] Gruber, J., "Daring Fireball: Uniform Type Identifier for Markdown", August 2011, <http://daringfireball.net/linked/2011/08/05/ markdown-uti>.
[MDUTI] Gruber、J。、「Daring Fireball：Uniform Type Identifier for Markdown」、2011年8月、<http://daringfireball.net/linked/2011/08/05/ markdown-uti>。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <http://www.rfc-editor.org/info/rfc2045>.
[RFC2045] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、DOI 10.17487 / RFC2045、1996年11月、<http：//www.rfc- editor.org/info/rfc2045>。
[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>。
[RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, DOI 10.17487/RFC2183, August 1997, <http://www.rfc-editor.org/info/rfc2183>.
[RFC2183] Troost、R.、Dorner、S。、およびK. Moore、編、「インターネットメッセージでのプレゼンテーション情報の伝達：Content-Dispositionヘッダーフィールド」、RFC 2183、DOI 10.17487 / RFC2183、1997年8月、<http ：//www.rfc-editor.org/info/rfc2183>。
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, DOI 10.17487/RFC2231, November 1997, <http://www.rfc-editor.org/info/rfc2231>.
[RFC2231] Freed、N。およびK. Moore、「MIMEパラメータ値とエンコードされたワード拡張：文字セット、言語、および継続」、RFC 2231、DOI 10.17487 / RFC2231、1997年11月、<http：//www.rfc- editor.org/info/rfc2231>。
[RFC3778] Taft, E., Pravetz, J., Zilles, S., and L. Masinter, "The application/pdf Media Type", RFC 3778, DOI 10.17487/RFC3778, May 2004, <http://www.rfc-editor.org/info/rfc3778>.
[RFC3778] Taft、E.、Pravetz、J.、Zilles、S。、およびL. Masinter、「The application / pdf Media Type」、RFC 3778、DOI 10.17487 / RFC3778、2004年5月、<http：// www。 rfc-editor.org/info/rfc3778>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<http：/ /www.rfc-editor.org/info/rfc3986>。
[RFC5147] Wilde, E. and M. Duerst, "URI Fragment Identifiers for the text/plain Media Type", RFC 5147, DOI 10.17487/RFC5147, April 2008, <http://www.rfc-editor.org/info/rfc5147>.
[RFC5147]ワイルド、E.、M。デュエルスト、「text / plainメディアタイプのURIフラグメント識別子」、RFC 5147、DOI 10.17487 / RFC5147、2008年4月、<http://www.rfc-editor.org/info / rfc5147>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、Ed。、およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http：//www.rfc-editor .org / info / rfc5234>。
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 2012, <http://www.rfc-editor.org/info/rfc6532>.
[RFC6532] Yang、A.、Steele、S。、およびN. Freed、「Internationalized Email Headers」、RFC 6532、DOI 10.17487 / RFC6532、2012年2月、<http://www.rfc-editor.org/info/ rfc6532>。
[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>。
[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 />。
[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>。
[ISO646] International Organization for Standardization, "Information technology - ISO 7-bit coded character set for information interchange", ISO Standard 646, 1991.
[ISO646]国際標準化機構、「情報技術-情報交換用のISO 7ビットコード化文字セット」、ISO標準646、1991。
[PANDOC] MacFarlane, J., "Pandoc", 2014, <http://johnmacfarlane.net/pandoc/>.
[PANDOC] MacFarlane、J。、「Pandoc」、2014、<http://johnmacfarlane.net/pandoc/>。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <http://www.rfc-editor.org/info/rfc2046>.
[RFC2046] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、RFC 2046、DOI 10.17487 / RFC2046、1996年11月、<http://www.rfc-editor.org / info / rfc2046>。
[RFC4263] Lilly, B., "Media Subtype Registration for Media Type text/troff", RFC 4263, DOI 10.17487/RFC4263, January 2006, <http://www.rfc-editor.org/info/rfc4263>.
[RFC4263]リリーB.、「メディアタイプtext / troffのメディアサブタイプ登録」、RFC 4263、DOI 10.17487 / RFC4263、2006年1月、<http://www.rfc-editor.org/info/rfc4263>。
[RFC7764] Leonard, S., "Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations", RFC 7764, DOI 10.17487/RFC7764, March 2016, <http://www.rfc-editor.org/info/rfc7764>.
[RFC7764] Leonard、S。、「Markdownに関するガイダンス：設計哲学、安定性戦略、および選択登録」、RFC 7764、DOI 10.17487 / RFC7764、2016年3月、<http://www.rfc-editor.org/info/ rfc7764>。
[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/>。
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/