[要約] RFC 4263は、メディアタイプtext/troffのメディアサブタイプの登録に関する仕様です。このRFCの目的は、text/troffメディアタイプの正確な定義と、その使用方法の一貫性を確保することです。
Network Working Group B. Lilly
Request for Comments: 4263 January 2006
Category: Informational
Media Subtype Registration for Media Type text/troff
メディアタイプのテキスト/トロフのメディアサブタイプ登録
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
A text media subtype for tagging content consisting of juxtaposed text and formatting directives as used by the troff series of programs and for conveying information about the intended processing steps necessary to produce formatted output is described.
並置されたテキストとフォーマットディレクティブで構成されるコンテンツのタグ付けのテキストメディアサブタイプは、TROFFシリーズのプログラムで使用され、フォーマットされた出力を生成するために必要な処理手順に関する情報を伝えるための説明について説明します。
Table of Contents
目次
1. Introduction................................................... 2
2. Requirement Levels............................................. 3
3. Scope of Specification......................................... 3
4. Registration Form.............................................. 3
5. Acknowledgements............................................... 8
6. Security Considerations........................................ 8
7. Internationalization Considerations............................ 8
8. IANA Considerations............................................ 9
Appendix A. Examples.............................................. 10
A.1. Data Format............................................... 10
A.2. Simple Diagram............................................ 11
Appendix B. Disclaimers........................................... 12
Normative References.............................................. 13
Informative References............................................ 13
It is sometimes desirable to format text in a particular way for presentation. One approach is to provide formatting directives in juxtaposition to the text to be formatted. That approach permits reading the text in unformatted form (by ignoring the formatting directives), and it permits relatively simple repurposing of the text for different media by making suitable alterations to the formatting directives or the environment in which they operate. One particular series of related programs for formatting text in accordance with that model is often referred to generically as "troff", although that is also the name of a particular lineage of programs within that generic category for formatting text specifically for typesetter and typesetter-like devices. A related formatting program within the generic "troff" category, usually used for character-based output such as (formatted) plain text, is known as "nroff". For the purpose of the media type defined here, the entire category will be referred to simply by the generic "troff" name. Troff as a distinct set of programs first appeared in the early 1970s [N1.CSTR54], based on the same formatting approach used by some earlier programs ("runoff" and "roff"). It has been used to produce documents in various formats, ranging in length from short memoranda to books (including tables, diagrams, and other non-textual content). It remains in wide use as of the date of this document; this document itself was prepared using the troff family of tools per [I1.RFC2223] and [I2.Lilly05].
プレゼンテーションのために特定の方法でテキストをフォーマットすることが望ましい場合があります。1つのアプローチは、フォーマットされるテキストに並置されたフォーマットディレクティブを提供することです。このアプローチでは、テキストをフォーマットディレクティブを無視することでテキストを読み取ることができ、フォーマットディレクティブまたはそれらが動作する環境に適切な変更を加えることにより、異なるメディアのテキストを比較的単純な再利用できます。そのモデルに従ってテキストをフォーマットするための特定の一連の関連プログラムは、しばしば一般的に「トラフ」と呼ばれますが、それは、タイプセッターとタイプセッターのようなデバイス専用のテキストをフォーマットするためのその一般的なカテゴリ内のプログラムの特定の系統の名前でもあります。一般的に（フォーマットされた）プレーンテキストなどの文字ベースの出力に使用される一般的な「troff」カテゴリ内の関連するフォーマットプログラムは、「nroff」として知られています。ここで定義されているメディアタイプの目的のために、カテゴリ全体は、一般的な「troff」名で単純に言及されます。いくつかの以前のプログラム（「Runoff」と「Roff」）で使用されているのと同じフォーマットアプローチに基づいて、1970年代初頭[N1.CSTR54]に最初に登場したプログラムの異なるセットとしてのTroffが最初に登場しました。短いメモから本（表、図、その他の非テキストコンテンツを含む）までの長さの範囲で、さまざまな形式のドキュメントを作成するために使用されています。このドキュメントの日付は広く使用されています。このドキュメント自体は、[I1.RFC2223]および[I2.Lilly05]ごとにツールのトラフファミリーを使用して準備されました。
The basic format (juxtaposed text and formatting directives) is extensible and has been used for related formatting of text and graphical document content. Formating is usually controlled by a set of macros; a macro package is a set of related formatting tools, written in troff format (although compressed binary representations have also been used) and using basic formatting directives to extend and manage formatting capabilities for document authors. There are a number of preprocessors that transform a textual description of some content into the juxtaposed text and formatting directives necessary to produce some desired output. Preprocessors exist for formatting of tables of text and non-textual material, mathematical equations, chemical formulae, general line drawings, graphical representation of data (in plotted coordinate graphs, bar charts, etc.), representations of data formats, and representations of the abstract mathematical construct known as a graph (consisting of nodes and edges). Many such preprocessors use the same general type of input format as the formatters, and such input is explicitly within the scope of the media type described in this document.
基本形式（並置されたテキストとフォーマットディレクティブ）は拡張可能であり、テキストおよびグラフィカルなドキュメントコンテンツの関連するフォーマットに使用されています。フォーミングは通常、一連のマクロによって制御されます。マクロパッケージは、TROFF形式で記述された関連するフォーマットツールのセットであり（圧縮されたバイナリ表現も使用されていますが）、基本的なフォーマットディレクティブを使用して、ドキュメント著者のフォーマット機能を拡張および管理します。一部のコンテンツのテキスト説明を並置されたテキストに変換し、目的の出力を生成するために必要な指令のフォーマットを変換する多くのプリプロセッサーがあります。テキストと非テキストの素材、数学的方程式、化学式、一般的な線図、データのグラフィカルな表現（プロットされた座標グラフ、棒グラフなど）、データ形式の表現、およびグラフとして知られる抽象的数学的構成の表現（節とエッジの構成）の表現のために、前処理者が存在します。そのような前処理者の多くは、フォーマッターと同じ一般的なタイプの入力形式を使用しており、そのような入力は、このドキュメントで説明されているメディアタイプの範囲内で明示的にあります。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in [N2.BCP14].
このドキュメントの「必須」、「必要はない」、「そうでなければ」、「すべきではない」、「はない」、「推奨」、および「5月」は、[N2.BCP14]で説明されているように解釈されます。
The described media type refers to input that may be processed by preprocessors and by a page formatter. It is intended to be used where content has some text that may be comprehensible (either as text per se or as a readable description of non-text content) without machine processing of the content. Where there is little or no comprehensible text content, this media type SHOULD NOT be used. For example, while output of the "pic" preprocessor certainly consists of troff-compatible sequences of formatting directives, the sheer number of individual directives interspersed with any text that might be present makes comprehension difficult, whereas the preprocessor input language (as described in the "Published Specification" section of the registration below) may provide a concise and comprehensible description of graphical content. Preprocessor output that includes a large proportion of formatting directives would best be labeled as a subtype of the application media type. If particular preprocessor input content describes only graphical content with little or no text, and which is not readily comprehensible from a textual description of the graphical elements, a subtype of the image media type would be appropriate. The purpose of labeling media content is to provide information about that content to facilitate use of the content. Use of a particular label requires some common sense and judgment, and SHOULD NOT be mechanically applied to content in the absence of such judgment.
記載されているメディアタイプは、プリプロセッサやページフォーマッタによって処理される可能性のある入力を指します。コンテンツの機械処理なしで、コンテンツに理解可能なテキスト（テキスト自体として、または非テキストコンテンツの読み取り可能な説明として）がある場合に使用することを目的としています。理解可能なテキストコンテンツがほとんどまたはまったくない場合、このメディアタイプは使用しないでください。たとえば、「PIC」前処理器の出力は、フォーマット指令のトラフ互換シーケンスで構成されていることは確かですが、存在する可能性のあるテキストが散在する個々のディレクティブの数は理解が困難になりますが、プレプロセッサの入力言語（以下の登録の「公開された仕様」セクションで説明されているように）は、グラフィカルの内容とわかりやすい説明を提供する場合があります。フォーマットディレクティブの大部分を含むプリプロセッサ出力は、アプリケーションメディアタイプのサブタイプとして最適にラベル付けされます。特定のプリプロセッサ入力コンテンツが、テキストがほとんどまたはまったくないグラフィカルコンテンツのみを記述し、グラフィカル要素のテキストの説明から容易に理解できない場合、画像メディアタイプのサブタイプが適切です。メディアコンテンツにラベルを付ける目的は、コンテンツの使用を容易にするためにそのコンテンツに関する情報を提供することです。特定のラベルを使用するには、常識と判断が必要であり、そのような判断がなければ、コンテンツに機械的に適用すべきではありません。
The registration procedure and form are specified in [I3.RFC4288].
登録手順とフォームは[i3.RFC4288]で指定されています。
Type name: text
タイプ名：テキスト
Subtype name: troff
サブタイプ名：troff
Required parameters: none
必要なパラメーター：なし
Optional parameters:
オプションのパラメーター：
charset: Must be a charset registered for use with MIME text types [N3.RFC2046], except where transport protocols are explicitly exempted from that restriction. Specifies the charset of the media content. With traditional source content, this will be the default "US-ASCII" charset. Some recent versions of troff processing software can handle Unicode input charsets; however, there may be interoperability issues if the input uses such a charset (see "Interoperability considerations" below).
charset：輸送プロトコルがその制限から明示的に免除される場合を除き、MIMEテキストタイプ[n3.RFC2046]で使用するために登録されたcharsetでなければなりません。メディアコンテンツのcharsetを指定します。従来のソースコンテンツを使用すると、これはデフォルトの「US-ASCII」チャーセットになります。TROFF処理ソフトウェアの最近のバージョンでは、Unicode入力充電器を処理できます。ただし、入力がそのようなcharSetを使用している場合、相互運用性の問題がある場合があります（以下の「相互運用性の考慮事項」を参照）。
process: Human-readable additional information for formatting, including environment variables, preprocessor arguments and order, formatter arguments, and postprocessors. The parameter value may need to be quoted or encoded as provided for by [N4.RFC2045] as amended by [N5.RFC2231] and [N6.Errata]. Generating implementations must not encode executable content and other implementations must not attempt any execution or other interpretation of the parameter value, as the parameter value may be prose text. Implementations SHOULD present the parameter (after reassembly of continuation parameters, etc.) as information related to the media type, particularly if the media content is not immediately available (e.g., as with message/external-body composite media [N3.RFC2046]).
プロセス：環境変数、プリプロセッサの引数と順序、フォーマッター引数、およびポストプロセッサを含む、フォーマットのための人間読み取り可能な追加情報。[n5.rfc2231]および[n6.errata]によって修正されたように、[n4.rfc2045]によって規定されているように、パラメーター値を引用またはエンコードする必要があります。実装の生成は実行可能なコンテンツをエンコードしてはなりません。その他の実装は、パラメーター値が散文テキストである可能性があるため、パラメーター値の実行やその他の解釈を試みてはなりません。実装は、特にメディアコンテンツがすぐに利用できない場合（メッセージ/外部ボディ複合メディア[n3.RFC2046]など）、メディアタイプに関連する情報として（継続パラメーターなどの再組み立て後）パラメーターを提示する必要があります。
resources: Lists any additional files or programs that are required for formatting (e.g., via .cf, .nx, .pi, .so, and/or .sy directives).
リソース：フォーマットに必要な追加のファイルまたはプログラムをリストします（例：.cf、.nx、.pi、.so、および/または.syディレクティブを介して）。
versions: Human-readable indication of any known specific versions of preprocessors, formatter, macro packages, postprocessors, etc., required to process the content.
バージョン：コンテンツの処理に必要な、既知の特定のバージョンの既知の特定のバージョン、フォーマッタ、マクロパッケージ、ポストプロセッサなどの既知の特定のバージョンの人間が読み取ることができます。
Encoding considerations:
考慮事項のエンコード：
7bit is adequate for traditional troff provided line endings are canonicalized per [N3.RFC2046]. Transfer of this media type content via some transport mechanisms may require or benefit from encoding into a 7bit range via a suitable encoding method such as the ones described in [N4.RFC2045]. In particular, some lines in this media type might begin or end with whitespace, and that leading and/or trailing whitespace might be discarded or otherwise mangled if the media type is not encoded for transport.
7ビットは、[n3.rfc2046]ごとにラインエンディングが標準化されている場合、従来のトロフに適しています。いくつかのトランスポートメカニズムを介したこのメディアタイプのコンテンツの転送は、[n4.RFC2045]に記載されているような適切なエンコード方法を介して7ビット範囲にエンコードすることを必要とするか、利益を必要とする場合があります。特に、このメディアタイプのいくつかの行は、ホワイトスペースで開始または終了する場合があり、メディアタイプが輸送用にエンコードされていない場合、その先頭および/または末尾の空白が破棄されるか、その他の方法でマングルされる場合があります。
8bit may be used with Unicode characters represented as a series of octets using the utf-8 charset [I4.RFC3629], where transport methods permit 8bit content and where content line length is suitable. Transport encoding considerations for robustness may also apply, and if a suitable 8bit encoding mechanism is standardized, it might be applicable for protection of media during transport.
8ビットは、UTF-8チャーセット[I4.RFC3629]を使用して一連のオクテットとして表されるユニコード文字で使用できます。ここでは、輸送方法が8ビットコンテンツを許可し、コンテンツラインの長さが適切です。堅牢性に関する輸送エンコーディングの考慮事項も適用される場合があり、適切な8ビットエンコードメカニズムが標準化されている場合、輸送中のメディアの保護に適用できる場合があります。
binary may be necessary when raw Unicode is used or where line lengths exceed the allowable maximum for 7bit and 8bit content [N4.RFC2045], and may be used in environments (e.g., HTTP [I5.RFC2616]) where Unicode characters may be transferred via a non-MIME charset such as UTF-16 [I6.RFC2781].
生のユニコードが使用されている場合、またはラインの長さが7ビットおよび8ビットコンテンツ[N4.RFC2045]の許容最大値を超える場合、環境で使用される場合（例：HTTP [i5.RFC2616]）、Unicode文字はUTF-16 [I6.RFC2781]などの非MIMEチャーセットを介して転送される場合があります。
framed encoding MAY be used, but is not required and is not generally useful with this media type.
フレームエンコードが使用される場合がありますが、必要ではなく、このメディアタイプでは一般的に役立ちません。
Restrictions on usage: none
使用に関する制限：なし
Security considerations: Some troff directives (.sy and .pi) can cause arbitrary external programs to be run. Several troff directives (.so, .nx, and .cf) may read external files (and/or devices on systems that support device input via file system semantics) during processing. Several preprocessors have similar features. Some implementations have a "safe" mode that disables some of these features. Formatters and preprocessors are programmable, and it is possible to provide input which specifies an infinite loop, which could result in denial of service, even in implementations that restrict use of directives that access external resources. Users of this media type SHOULD be vigilant of the potential for damage that may be caused by careless processing of media obtained from untrusted sources.
セキュリティ上の考慮事項：一部のTROFFディレクティブ（.syおよび.pi）は、任意の外部プログラムを実行する可能性があります。いくつかのTROFFディレクティブ（.SO、.NX、および.CF）は、処理中に外部ファイル（およびファイルシステムセマンティクスを介してデバイス入力をサポートするシステム上のデバイス）を読み取ることができます。いくつかのプリプロセッサには、同様の機能があります。一部の実装には、これらの機能の一部を無効にする「安全」モードがあります。フォーマッタと前処理者はプログラム可能であり、外部リソースにアクセスするディレクティブの使用を制限する実装であっても、無限のループを指定する入力を提供することができます。このメディアタイプのユーザーは、信頼できないソースから得られたメディアの不注意な処理によって引き起こされる可能性のある損害の可能性を警戒する必要があります。
Processing of this media type other than by facilities that strip or ignore potentially dangerous directives, and processing by preprocessors and/or postprocessors, SHOULD NOT be invoked automatically (i.e., without user confirmation). In some cases, as this is a text media type (i.e., it contains text that is comprehensible without processing), it may be sufficient to present the media type with no processing at all. However, like any other text media, this media type may contain control characters, and implementers SHOULD take precautions against untoward consequences of sending raw control characters to display devices.
潜在的に危険な指令を剥奪または無視する施設以外のこのメディアタイプの処理、および前処理者やポストプロセッサーによる処理は、自動的に呼び出されるべきではありません（つまり、ユーザー確認なし）。場合によっては、これはテキストメディアタイプであるため（つまり、処理せずに理解できるテキストが含まれています）、メディアタイプをまったく処理せずに提示するだけで十分かもしれません。ただし、他のテキストメディアと同様に、このメディアタイプにはコントロール文字が含まれている場合があり、実装者は生のコントロール文字を送信してデバイスを表示するという不快な結果に対して予防策を講じる必要があります。
Users of this media type SHOULD carefully scrutinize suggested command lines associated with the "process" parameter, contained in comments within the media, or conveyed via external mechanisms, both for attempts at social engineering and for the effects of ill-considered values of the parameter. While some implementations may have "safe" modes, those using this media type MUST NOT presume that they are available or active.
このメディアタイプのユーザーは、メディア内のコメントに含まれる「プロセス」パラメーターに関連する提案されたコマンドラインを注意深く精査するか、ソーシャルエンジニアリングの試みとパラメーターの不合理な値の効果の両方について、外部メカニズムを介して伝えます。いくつかの実装には「安全な」モードがあるかもしれませんが、このメディアタイプを使用している人は、それらが利用可能またはアクティブであると推定してはなりません。
Comments may be included in troff source; comments are not formatted for output. However, they are of course readable in the troff document source. Authors should be careful about information placed in comments, as such information may result in a leak of information, or may have other undesirable consequences.
コメントはTroffソースに含まれる場合があります。コメントは出力に対してフォーマットされていません。ただし、もちろん、Troffドキュメントソースで読みやすいです。著者は、そのような情報が情報のリークをもたらす可能性があるか、他の望ましくない結果をもたらす可能性があるため、コメントに入れられた情報に注意する必要があります。
While it is possible to overlay text with graphics or otherwise produce formatting instructions that would visually obscure text when formatted, such measures do not prevent extracting text from the document source, and might be ineffective in obscuring text when formatted electronically, e.g., as PostScript or PDF.
テキストをグラフィックスでオーバーレイするか、フォーマット時にテキストを視覚的に不明瞭にするフォーマット命令を作成することは可能ですが、そのような手段はドキュメントソースからテキストの抽出を妨げず、ポストスクリプトまたはPDFとして電子的にフォーマットされた場合、テキストを不明瞭にするのに効果的でない可能性があります。
Interoperability considerations: Recent implementations of formatters, macro packages, and preprocessors may include some extended capabilities that are not present in earlier implementations. Use of such extensions obviously limits the ability to produce consistent formatted output at sites with implementations that do not support those extensions. Use of any such extensions in a particular document using this media type SHOULD be indicated via the "versions" parameter value.
相互運用性の考慮事項：フォーマッタ、マクロパッケージ、およびプレプレセッサーの最近の実装には、以前の実装には存在しない拡張機能が含まれる場合があります。このような拡張機能を使用すると、明らかに、これらの拡張機能をサポートしない実装を備えたサイトで一貫したフォーマット出力を生成する機能が制限されます。このメディアタイプを使用して特定のドキュメントでこのような拡張機能を使用すると、「バージョン」パラメーター値を介して示す必要があります。
As mentioned in the Introduction, macro packages are troff documents, and their content may be subject to copyright. That has led to multiple independent implementations of macro packages, which may exhibit gross or subtle differences with some content.
導入部で述べたように、マクロパッケージはtroffドキュメントであり、そのコンテンツは著作権の影響を受ける可能性があります。これにより、マクロパッケージの複数の独立した実装が発生しました。これは、一部のコンテンツで粗いまたは微妙な違いを示す可能性があります。
Some preprocessors or postprocessors might be unavailable at some sites. Where some implementation is available, there may be differences in implementation that affect the output produced. For example, some versions of the "pic" preprocessor provide the capability to fill a bounded graphical object; others lack that capability. Of those that support that feature, there are differences in whether a solid fill is represented by a value of 0.0 vs. 1.0. Some implementations support only gray-scale output; others support color.
一部のサイトでは、一部のサイトでは前処理者またはポストプロセッサが利用できない場合があります。いくつかの実装が利用可能な場合、生成された出力に影響を与える実装に違いがあるかもしれません。たとえば、「PIC」プリプロセッサの一部のバージョンは、境界のあるグラフィカルオブジェクトを埋める機能を提供します。他の人はその能力を欠いています。その特徴をサポートするもののうち、固体フィルが0.0対1.0の値で表されるかどうかに違いがあります。一部の実装は、グレースケールの出力のみをサポートしています。他の人は色をサポートしています。
Preprocessors or postprocessors may depend on additional programs such as awk, and implementation differences (including bugs) may lead to different results on different systems (or even on the same system with a different environment).
前処理者またはポストプロセッサは、AWKなどの追加のプログラムに依存する場合があり、実装の違い（バグを含む）は、異なるシステム（または異なる環境を持つ同じシステム）で異なる結果につながる可能性があります。
There is a wide variation in the capabilities of various presentation media and the devices used to prepare content for presentation. Indeed, that is one reason that there are two basic formatter program types (nroff for output where limited formatting control is available, and troff where a greater range of control is possible). Clearly, a document designed to use complex or sophisticated formatting might not be representable in simpler media or with devices lacking certain capabilities. Often it is possible to produce a somewhat inferior approximation; colors might be represented as gray-scale values, accented characters might be produced by overstriking, italics might be represented by underlining, etc.
さまざまなプレゼンテーションメディアの機能と、プレゼンテーション用のコンテンツを準備するために使用されるデバイスに大きなバリエーションがあります。実際、それが2つの基本的なフォーマッタプログラムタイプがある理由の1つです（制限されたフォーマット制御が利用可能な出力のnroff、およびより幅広い制御が可能な場所でのtroff）。明らかに、複雑または洗練されたフォーマットを使用するように設計されたドキュメントは、より単純なメディアや特定の機能がないデバイスでは表現できない場合があります。多くの場合、やや劣った近似を生成することが可能です。色はグレースケールの値として表される可能性があり、アクセントされた文字は過剰なストライキによって生成される可能性があり、斜体は下線などによって表される可能性があります。
Various systems store text with different line ending codings. For the purpose of transferring this media type between systems or between applications using MIME methods, line endings MUST use the canonical CRLF line ending per [N3.RFC2046].
さまざまなシステムがテキストを保存し、異なる行の終了コーディングを備えています。このメディアタイプをシステム間またはMIMEメソッドを使用してアプリケーション間で転送する目的では、ラインエンディングは[n3.RFC2046]ごとに標準CRLFラインを使用する必要があります。
Published specification: [N1.CSTR54]
公開された仕様：[n1.cstr54]
Applications which use this media type: The following applications in each sub-category are examples. The lists are not intended to be exhaustive.
このメディアタイプを使用するアプリケーション：各サブカテゴリの以下のアプリケーションは例です。リストは網羅的であることを意図していません。
Preprocessors: tbl [I7.CSTR49], grap [I8.CSTR114], pic [I9.CSTR116], chem [I10.CSTR122], eqn [I11.eqn], dformat [I12.CSTR142]
前執行機関：TBL [I7.CSTR49]、GRAP [I8.CSTR 114]、PIC [I9.CSTR116]、化学[I10.CSTR122]、EQN [I11.EQN]、形式[I12.CSTR 142]
Formatters: troff, nroff, Eroff, sqtroff, groff, awf, cawf
フォーマッター：Troff、Nroff、Eroff、SQTroff、Groff、AWF、CAWF
Format converters: deroff, troffcvt, unroff, troff2html, mm2html
フォーマットコンバーター：deroff、troffcvt、unroff、troff2html、mm2html
Macro packages: man [I13.UNIXman1], me [I14.me], mm [I15.DWBguide], ms [I16.ms], mv [I15.DWBguide], rfc [I2.Lilly05]
マクロパッケージ：man [i13.unixman1]、me [i14.me]、mm [i15.dwbguide]、ms [i16.ms]、mv [i15.dwbguide]、rfc [i2.lilly05]
Additional information:
追加情報：
Magic number(s): None; however, the content format is distinctive (see "Published specification").
マジックナンバー：なし;ただし、コンテンツ形式は独特です（「公開された仕様」を参照）。
File extension(s): Files do not require any specific "extension". Many are in use as a convenience for mechanized processing of files, some associated with specific macro packages or preprocessors; others are ad hoc. File names are orthogonal to the nature of the content. In particular, while a file name or a component of a name may be useful in some types of automated processing of files, the name or component might not be capable of indicating subtleties such as proportion of textual (as opposed to image or formatting directive) content. This media type SHOULD NOT be assigned a relationship with any file "extension" where content may be untrusted unless there is provision for human judgment that may be used to override that relationship for individual files. Where appropriate, a file name MAY be suggested by a suitable mechanism such as the one specified in [I17.RFC2183] as amended by [N5.RFC2231] and [N6.Errata].
ファイル拡張子：ファイルは特定の「拡張機能」を必要としません。多くは、特定のマクロパッケージまたは前処理者に関連付けられているファイルの機械化処理の便利さとして使用されています。その他はアドホックです。ファイル名は、コンテンツの性質に直交します。特に、ファイル名のファイル名またはコンポーネントは、ファイルの一部の種類の自動処理に役立つ場合がありますが、名前またはコンポーネントは、テキストの割合（画像や指令の書式設定とは対照的に）コンテンツなどの微妙さを示すことができない場合があります。このメディアタイプには、個々のファイルの関係をオーバーライドするために使用される可能性のある人間の判断の規定がない限り、コンテンツが信頼できないファイル「拡張機能」との関係を割り当てるべきではありません。必要に応じて、[n5.rfc2231]および[n6.errata]によって修正された[i17.rfc2183]で指定されているような適切なメカニズムによって、ファイル名が提案される場合があります。
Macintosh File Type Code(s): unknown
Macintoshファイルタイプコード：不明
Person & email address to contact for further information: Bruce Lilly blilly@erols.com
詳細については、個人とメールアドレスをお問い合わせください：Bruce Lilly Blilly@erols.com
Intended usage: COMMON
意図された使用法：共通
Author/Change controller: IESG
著者/変更コントローラー：IESG
Consistency: The media has provision for comments; these are sometimes used to convey recommended processing commands, to indicate required resources, etc. To avoid confusing recipients, senders SHOULD ensure that information specified in optional parameters is consistent with any related information that may be contained within the media content.
一貫性：メディアにはコメントの規定があります。これらは、推奨される処理コマンドを伝達したり、必要なリソースなどを指定するために使用される場合があります。受信者を混乱させるために、送信者は、オプションのパラメーターで指定された情報がメディアコンテンツに含まれる可能性のある関連情報と一致することを確認する必要があります。
The author would like to acknowledge the helpful comments provided by members of the ietf-types mailing list.
著者は、IETFタイプのメーリングリストのメンバーから提供された有用なコメントを認めたいと思います。
Security considerations are discussed in the media registration. Additional considerations may apply when the media subtype is used in some contexts (e.g., MIME [I18.RFC2049]).
セキュリティ上の考慮事項は、メディア登録で議論されています。一部のコンテキストでメディアサブタイプが使用される場合（MIME [I18.RFC2049]）、追加の考慮事項が適用される場合があります。
The optional charset parameter may be used to indicate the charset of the media type content. In some cases, that content's charset might be carried through processing for display of text. In other cases, combinations of octets in particular sequences are used to represent glyphs that cannot be directly represented in the content charset. In either of those categories, the language(s) of the text might not be evident from the character content, and it is RECOMMENDED that a suitable mechanism (e.g., [I19.RFC3282]) be used to convey text language where such a mechanism is available [I20.BCP18]. Where multiple languages are used within a single document, it may be necessary or desirable to indicate the languages to readers directly via explicit indication of language in the content. In still other cases, the media type content (while readable and comprehensible in text form) represents symbolic or graphical information such as mathematical equations or chemical formulae, which are largely global and language independent.
オプションのcharsetパラメーターを使用して、メディアタイプのコンテンツのcharsetを示すことができます。場合によっては、そのコンテンツのチャーセットは、テキストの表示のために処理を通じて運ばれる場合があります。それ以外の場合、特定のシーケンスでのオクテットの組み合わせは、コンテンツのcharsetで直接表現できないグリフを表すために使用されます。これらのカテゴリのいずれかで、テキストの言語は文字コンテンツからは明らかではなく、適切なメカニズム（[i19.RFC3282]など）を使用して、そのようなメカニズムが利用可能なテキスト言語を伝えることをお勧めします[I20.BCP18]。単一のドキュメント内で複数の言語が使用されている場合、コンテンツ内の言語の明示的な表示を介して、読者に言語を直接示すことが必要または望ましい場合があります。他の場合、メディアタイプのコンテンツ（読みやすく、テキスト形式では理解できますが）は、数学的方程式や化学式などの象徴的またはグラフィカルな情報を表します。
IANA shall enter and maintain the registration information in the media type registry as directed by the IESG.
IANAは、IESGの指示に従って、メディアタイプレジストリに登録情報を入力して維持するものとします。
The input:
入力：
Content-Type: text/troff ; process="dformat | pic -n | troff -ms"
Here's what an IP packet header looks like:
IPパケットヘッダーがどのように見えるかは次のとおりです。
.begin dformat style fill off style bitwid 0.20 style recspread 0 style recht 0.33333 noname 0-3 \0Version 4-7 IHL 8-15 \0Type of Service 16-31 Total Length noname 0-15 Identification 16-18 \0Flags 19-31 Fragment Offset noname 0-7 Time to Live 8-15 Protocol 16-31 Header Checksum noname 0-31 Source Address noname 0-31 Destination Address noname 0-23 Options 24-31 Padding .end
.begin dformatスタイルの充填スタイルBitwid 0.20スタイルRecspread 0スタイルRecht 0.33333 NonAMe 0-3 \ 0version 4-7 Ihl 8-15 \ 0タイプのサービス16-31合計長さ16-18 \ 0flags 19-31 Frags offert nonmam 31宛先アドレスNONAM 0-23オプション24-31パディング.END
produces as output:
出力として生成：
Here's what an IP packet header looks like:
IPパケットヘッダーがどのように見えるかは次のとおりです。
+-------+-------+---------------+-------------------------------+
|Version| IHL |Type of Service| Total Length |
0------34------78-------------1516----+-----------------------31+
| Identification |Flags| Fragment Offset |
0---------------+-------------1516--1819----------------------31+
| Time to Live | Protocol | Header Checksum |
0--------------78-------------1516----------------------------31+
| Source Address |
0-------------------------------------------------------------31+
| Destination Address |
0-----------------------------------------------+-------------31+
| Options | Padding |
0---------------------------------------------2324------------31+
The input:
入力：
Content-Type: text/troff ; process="use pic -n then troff -ms"
The SMTP design can be pictured as:
SMTPの設計は、次のように描くことができます。
.DS B
.PS
boxwid = 0.8
# arrow approximation that looks acceptable in troff and nroff
define myarrow X A: [ move right 0.055;\
"<" ljust;line right ($1 - 0.1);">" rjust;\
move right 0.045 ]\
X
User: box ht 0.333333 "User"
FS: box ht 0.666667 "File" "System" with .n at User.s -0, 0.333333
Client: box ht 1.333333 wid 1.1 "Client\-" "SMTP" \
with .sw at FS.se +0.5, 0
"SMTP client" rjust at Client.se -0, 0.166667
move to User.e ; myarrow(0.5)
move to FS.e ; myarrow(0.5)
move to Client.e ; SMTP: myarrow(1.8)
Server: box ht 1.333333 wid 1.1 "Server\-" "SMTP" \
with .sw at Here.x, Client.s.y
box invis ht 0.5 "SMTP" "Commands/Replies" with .s at SMTP.c
box invis ht 0.25 "and Mail" with .n at SMTP.c
"SMTP server" ljust at Server.sw -0, 0.166667
move to Server.e.x, FS.e.y ; myarrow(0.5)
FS2: box ht 0.666667 "File" "System" \
with .sw at Server.se.x +0.5, FS.s.y
.PE
.DE
produces as output:
出力として生成：
The SMTP design can be pictured as:
SMTPの設計は、次のように描くことができます。
+-------+ +----------+ +----------+
| User |<-->+ | | |
+-------+ | | SMTP | |
| |Commands/Replies | |
+-------+ | Client- |<--------------->+ Server- | +-------+
| | | SMTP | and Mail | SMTP | | |
| File |<-->+ | | |<-->+ File |
|System | | | | | |System |
+-------+ +----------+ +----------+ +-------+
SMTP client SMTP server
This document has exactly one (1) author.
このドキュメントには、ちょうど1人の著者がいます。
In spite of the fact that the author's given name may also be the surname of other individuals, and the fact that the author's surname may also be a given name for some females, the author is, and has always been, male.
著者の名前が他の個人の姓である可能性があるという事実にもかかわらず、著者の姓も一部の女性の名前である可能性があるという事実は、著者は常に男性であり、常にそうでした。
The presence of "/SHE", "their", and "authors" (plural) in the boilerplate sections of this document is irrelevant. The author of this document is not responsible for the boilerplate text.
このドキュメントのボイラープレートセクションに「/he」、「shey」、および "Authors」（複数）の存在は無関係です。このドキュメントの著者は、ボイラープレートテキストについて責任を負いません。
Comments regarding the silliness, lack of accuracy, and lack of precision of the boilerplate text should be directed to the IESG, not to the author.
愚かさ、精度の欠如、およびボイラープレートのテキストの精度の欠如に関するコメントは、著者ではなくIESGに向けられるべきです。
Normative References
引用文献
[N1.CSTR54] Ossanna, Joseph F., "NROFF/TROFF User's Manual", Computing Science Technical Report No.54, Bell Laboratories, Murray Hill, New Jersey, 1976.
[N1.CSTR54] Ossanna、Joseph F.、「Nroff/Troff User's Manual」、Computing Science Technical Report No.54、Bell Laboratories、Murray Hill、New Jersey、1976
[N2.BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[N2.BCP14] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[N3.RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[N3.RFC2046] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[N4.RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[N4.RFC2045] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[N5.RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[N5.RFC2231] Freed、N。およびK. Moore、「MIMEパラメーター値とエンコードされた単語拡張機能：文字セット、言語、および継続」、RFC 2231、1997年11月。
[N6.Errata] RFC-Editor errata page, http://www.rfc-editor.org/errata.html
[n6.errata] rfc-editor errataページ、http：//www.rfc-editor.org/errata.html
Informative References
参考引用
[I1.RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[I1.RFC2223] Postel、J。およびJ. Reynolds、「RFC著者への指示」、RFC 2223、1997年10月。
[I2.Lilly05] Lilly, B., "Writing Internet-Drafts and Requests For Comments using troff and nroff", Work in Progress, May 2005.
[I2.Lilly05] Lilly、B。、「TroffとNroffを使用したインターネットドラフトとコメントのリクエストを書く」、2005年5月の進行中。
[I3.RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[I3.RFC4288] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。
[I4.RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[i4.RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[I5.RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[I5.RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、 "Hypertext Transfer Protocol-HTTP/1.1"、RFC 2616、1999年6月。
[I6.RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[i6.rfc2781] Hoffman、P。and F. Yergeau、「UTF-16、ISO 10646のエンコーディング」、RFC 2781、2000年2月。
[I7.CSTR49] Lesk, M. E., "TBL - A Program for Setting Tables", Bell Laboratories Computing Science Technical Report #49, Murray Hill, New Jersey, 1976.
[I7.CSTR49] Lesk、M。E.、「TBL-テーブルの設定プログラム」、Bell Laboratories Computing Science Technical Report＃49、Murray Hill、New Jersey、1976。
[I8.CSTR114] Bentley, Jon L. and Kernighan, Brian W., "Grap - A Language for Typesetting Graphs Tutorial and User Manual", Computing Science Technical Report No.114, AT&T Bell Laboratories, Murray Hill, New Jersey, 1991.
[I8.CSTR114] Bentley、Jon L.およびKernighan、Brian W.、「Grap-グラフのタイプセットチュートリアルとユーザーマニュアルの言語」、Computing Science Technical Report No.114、AT＆T Bell Laboratories、Murray Hill、New Jersey、1991。
[I9.CSTR116] Kernighan, Brian W., "Pic - A Graphics Language for Typesetting User Manual", Computing Science Technical Report No.116, AT&T Bell Laboratories, Murray Hill, New Jersey, 1991.
[i9.cstr116] Kernighan、Brian W.、「Pic-タイプセットユーザーマニュアルのグラフィック語」、Computing Science Technical Report No.116、AT＆T Bell Laboratories、Murray Hill、New Jersey、1991。
[I10.CSTR122] Bentley, Jon L., Jelinski, Lynn W., and Kernighan, Brian W., "Chem - A Program for Typesetting Chemical Diagrams: User Manual", Computing Science Technical Report No.122, AT&T Bell Laboratories, Murray Hill, New Jersey, 1992.
[I10.CSTR122] Bentley、Jon L.、Jelinski、Lynn W.、およびKernighan、Brian W.、「化学プログラム：化学図：ユーザーマニュアル：ユーザーマニュアル」、コンピューティングサイエンステクニカルレポートNo.122、AT＆T Bell Laboratories、AT＆T Bell Laboratories、Murray Hill、New Jersey、1992。
[I11.eqn] Kernighan, Brian W, and Cherry, Lorinda L., "A System for Typesetting Mathematics", Communications of the ACM 18, 182-193, 1975.
[i11.eqn] Kernighan、Brian W、およびCherry、Lorinda L.、「タイプセット数学のシステム」、ACM 18、182-193、1975の通信。
[I12.CSTR142] Bentley, Jon L. "DFORMAT - A Program for Typesetting Data Formats", Computing Science Technical Report No.142, AT&T Bell Laboratories, Murray Hill, New Jersey, 1988.
[I12.CSTR142] Bentley、Jon L.
[I13.UNIXman1] AT&T Bell Laboratories, "UNIX TIME-SHARING SYSTEM (VOLUME 1) : UNIX Programmer's Manual", Holt, Rinehart, & Winston, 1979
[i13.unixman1] AT＆T Bell Laboratories、「UNIXタイムシェアリングシステム（第1巻）：UNIXプログラマーマニュアル」、Holt、Rinehart、＆Winston、1979
[I14.me] Allman, Eric P., "Writing Papers With NROFF Using -me", USD:19, University of California, Berkeley, Berkeley, California, 1997.
[I14.ME] Allman、Eric P.、「-Meを使用したNroffとの論文の執筆」、USD：19、カリフォルニア大学、バークレー、バークレー、カリフォルニア、1997年。
[I15.DWBguide] AT&T Bell Laboratories, "Unix System V Documenter's Workbench User's Guide", Prentice Hall, 1989
[i15.dwbguide] AT＆T Bell Laboratories、「UNIX System Vドキュメンターズワークベンチユーザーガイド」、1989年プレンティスホール
[I16.ms] Lesk, M. E., "Typing Documents on the UNIX System: Using the -ms Macros with Troff and Nroff", 1978, in "UNIX TIME-SHARING SYSTEM (VOLUME 2) : UNIX Programmer's Manual", Holt, Rinehart, & Winston, 1979
[I16.MS] Lesk、M。E.、「UNIXシステムのドキュメントの入力：TROFFとNROFFで-MSマクロを使用する」、1978年、「UNIXタイムシェアリングシステム（第2巻）：UNIXプログラマーマニュアル」、Holt、Rinehart、＆Winston、1979
[I17.RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[I17.RFC2183] Troost、R.、Dorner、S。、およびK. Moore、「インターネットメッセージのプレゼンテーション情報の通信：コンテンツ拡散ヘッダーフィールド」、RFC 2183、1997年8月。
[I18.RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[I18.RFC2049] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート5：適合基準と例」、RFC 2049、1996年11月。
[I19.RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[i19.rfc3282] Alvestrand、H。、「コンテンツ言語ヘッダー」、RFC 3282、2002年5月。
[I20.BCP18] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[I20.BCP18] Alvestrand、H。、「キャラクターセットと言語に関するIETFポリシー」、BCP 18、RFC 2277、1998年1月。
Author's Address
著者の連絡先
Bruce Lilly
ブルース・リリー
EMail: blilly@erols.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスが利用可能になる可能性がある範囲に関連する可能性があると主張される可能性のある他の権利の範囲に関してはありません。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果、http://ww.ietf.org/IPRでIETFオンラインIPRリポジトリから取得できます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。