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).




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.


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
1. Introduction
1. はじめに

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].

プレゼンテーションのための特定の方法でテキストの書式を設定することが望ましい場合があります。一つのアプローチは、テキストに並べてフォーマットするフォーマットディレクティブを提供することです。そのアプローチは、(フォーマット指示を無視して)フォーマットされていない形でテキストを読む許可し、それがフォーマットディレクティブまたはそれらが動作する環境に適切な変更を行うことにより、異なる媒体のためのテキストの比較的簡単な再利用を可能にします。それは、具体的植字と植字工、等のためのテキストをフォーマットすることの一般的なカテゴリー内のプログラムの特定の系統の名前でもあるが、そのモデルに合わせてテキストをフォーマットするための関連プログラムの一つの特定のシリーズは、多くの場合、総称して「のtroff」と呼ばれていますデバイス。通常、このような(フォーマット済み)プレーンテキストとして、文字ベースの出力のために使用される一般的な「troffの」カテゴリ内の関連する書式設定のプログラムは、「nroffの」として知られています。ここで定義されたメディアタイプのために、全体のカテゴリは一般的な「troffの」名前だけで簡単に参照されます。プログラムの別個のセットとしてのtroffは、まずいくつかの以前のプログラム(「流出」および「のroff」)によって使用されるのと同じフォーマットアプローチに基づいて、1970年代初頭[N1.CSTR54]で登場しました。 (表、図、およびその他の非テキストコンテンツを含む)の書籍に短いメモの長さの範囲の、さまざまな形式でドキュメントを生成するために使用されてきました。それは、この文書の日付現在の幅広い使用のまま。この文書自体は[I2.Lilly05] [I1.RFC2223]あたりおよびツールのtroffのファミリーを用いて調製しました。

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.


2. Requirement Levels

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in [N2.BCP14].

キーワード "MUST"、 "NOT MUST"、 "SHOULD NOT"、 "RECOMMENDED"、 "SHOULD" とは、この文書の[N2.BCP14]で説明されるように解釈される "場合があります"。

3. Scope of Specification

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」プリプロセッサの出力は確かフォーマットディレクティブのtroffの互換配列から成りながら、例えば、個々のディレクティブの膨大な数が存在する可能性のあるテキストが散在は、理解が困難で説明したように、プリプロセッサの入力言語(一方「公開明細書」は、以下の登録の部分)は、グラフィック・コンテンツの簡潔で分かりやすい説明を提供することができます。フォーマットディレクティブの大部分を含んでプリプロセッサの出力は最高のアプリケーションメディアタイプのサブタイプとして分類されるだろう。特定のプリプロセッサ入力内容がほとんど又は全くテキストでのみグラフィック・コンテンツを記述し、かつ容易に理解グラフィック要素のテキスト記述からでない場合は、画像メディアタイプのサブタイプが適切であろう。ラベリングメディアコンテンツの目的は、コンテンツの利用を容易にするために、そのコンテンツに関する情報を提供することです。特定のラベルの使用は、いくつかの常識や判断力を必要とし、機械的な判断力のない状態でコンテンツに適用されるべきではありません。

4. Registration Form

The registration procedure and form are specified in [I3.RFC4288].


Type name: text


Subtype name: 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).

文字セットは:トランスポートプロトコルを明示的にその制限を免除されている場合を除いて、MIMEのテキストタイプ[N3.RFC2046]で使用するために登録された文字セットでなければなりません。メディアコンテンツの文字セットを指定します。伝統的なソースコンテンツでは、これはデフォルトの「US-ASCII」文字セットになります。 troffの処理ソフトウェアの最近のバージョンでは、Unicode文字セットの入力を処理することができます。入力は、このような文字セットを使用しています(下の「相互運用性に関する考慮事項」を参照)場合は、相互運用性の問題があるかもしれません。

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]).

プロセス:環境変数、プリプロセッサの引数と順序、フォーマッタの引数、およびポストプロセッサを含む書式設定のための人間可読な付加的な情報、。パラメータ値は[N4.RFC2045] [N6.Errata]及び[N5.RFC2231]によって修正されるようによって提供として引用または符号化する必要があるかもしれません。生成実装は、実行可能なコンテンツをエンコードしてはならず、パラメータ値は散文テキストとすることができるように、他の実装では、任意の実行またはパラメータ値の他の解釈を試みてはなりません。実装は、メディアコンテンツが利用可能でない場合は特に、メディアタイプに関連する情報として(継続パラメータ等の再組立後の)パラメータを提示しなければならない(メッセージ/外部ボディ複合メディアと同様に、例えば、[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).


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.


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.


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].

バイナリは、Unicode文字を転送することができる場合、生のUnicodeを使用する場合に必要であるか、または線の長さが7ビットと8ビットの内容〔N4.RFC2045]の許容最大値を超え、かつ環境で使用することができる場合(例えば、HTTP [I5.RFC2616])してもよいです【I6.RFC2781ようなUTF-16などの非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.


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.


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.


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.


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.


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).


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.


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]


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.CSTR114]、PIC [I9.CSTR116]、CHEM [I10.CSTR122]、EQN [I11.eqn]、DFORMAT [I12.CSTR142]

Formatters: troff, nroff, Eroff, sqtroff, groff, awf, cawf


Format converters: deroff, troffcvt, unroff, troff2html, mm2html


Macro packages: man [I13.UNIXman1], me [], mm [I15.DWBguide], ms [], mv [I15.DWBguide], rfc [I2.Lilly05]

マクロパッケージ:男は[I13.UNIXman1]、私[]、MMは[I15.DWBguide]、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].

ファイルの拡張子(S):ファイルの任意の特定の「拡張子」を必要としません。多くはファイル、マクロパッケージまたはプリプロセッサの特定に関連したいくつかの機械加工の利便として使用されています。他の人はアドホックです。ファイル名は、コンテンツの性質に直交しています。ファイル名または名前のコンポーネントは、ファイルの自動処理のいくつかのタイプにおいて有用であり得るが、特に、名前または成分(画像またはフォーマット指示とは対照的に)そのようなテキストの割合として機微を指示することができないかもしれませんコンテンツ。個々のファイルのような関係を上書きするために使用することができる人間の判断のための規定がない限り、このメディアタイプは、コンテンツが信頼できない可能性がある任意のファイル「拡張子」との関係を割り当てるべきではありません。適切な場合、ファイル名は、および[N6.Errata] [N5.RFC2231]によって修正ようI17.RFC2183]で指定されたもののような適切な機構によって示唆されるかもしれません。

Macintosh File Type Code(s): unknown


Person & email address to contact for further information: Bruce Lilly


Intended usage: COMMON


Author/Change controller: 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.


5. Acknowledgements

The author would like to acknowledge the helpful comments provided by members of the ietf-types mailing list.


6. Security Considerations

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])。

7. Internationalization Considerations

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.


8. IANA Considerations
8. IANAの考慮事項

IANA shall enter and maintain the registration information in the media type registry as directed by the IESG.


Appendix A. Examples


A.1. Data Format


The input:


Content-Type: text/troff ; process="dformat | pic -n | troff -ms"

コンテンツタイプ:テキスト/ troffの。プロセス= "DFORMAT | PICの-n |のtroff -ms"

Here's what an IP packet header looks like:


.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スタイルオフ塗りつぶしスタイルは0.20スタイルrecspread 0スタイルrechtをbitwid 0.33333 NONAME 0-3 \ 0VERSION 4-7 IHL 8-15 \ 0Typeサービス16-31全長のNONAME 0-15識別16-18 \ 0Flagsの19-31フラグメントオフセット8-15プロトコル16-31ヘッダチェックサムのNONAME 0-31ソースアドレスNONAME 0-31宛先アドレスNONAME 0-23オプション24-31パディング.ENDを生きてNONAME 0-7時間

produces as output:


Here's what an IP packet header looks like:


   |Version| IHL   |Type of Service|         Total Length          |
   |        Identification         |Flags|    Fragment Offset      |
   | Time to Live  |   Protocol    |       Header Checksum         |
   |                        Source Address                         |
   |                     Destination Address                       |
   |                   Options                     |   Padding     |

A.2. Simple Diagram


The input:


Content-Type: text/troff ; process="use pic -n then troff -ms"

コンテンツタイプ:テキスト/ troffの。プロセスは=「のtroff -msその後、-nの写真を使用して」

The SMTP design can be pictured as:


.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 +0.5, 0 "SMTP client" rjust at -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 +0.5, FS.s.y .PE .DE

.DS B .PSはboxwid = 0.8位のtroffおよびmyarrow XAを定義NROFFに許容される見え近似を矢印:移動右0.055; \ "<" として、ljust、行右($ 1から0.1); ">" RJUST; \移動右0.045 ] \ Xユーザー:ボックスHT 0.333333 "ユーザー" FS:ボックスHT 0.666667 "ファイル" "システム" User.s -0で.Nと、0.333333クライアント:ボックスHT 1.333333 WID 1.1 "クライアント\ - " "SMTP" \と 0.5で.sw、 -0で0 "SMTPクライアント" RJUST、User.eに0.166667移動。 myarrow(0.5)FS.eへ移動します。 myarrow(0.5)Client.eへ移動します。 SMTP:myarrow(1.8)サーバー:ボックスHT 1.333333 WID 1.1 "サーバー\ - " "Here.xで.swと\、Client.syボックスINVIS HT 0.5" "SMTP SMTP" SMTPで.Sと "コマンド/回答" Server.sw -0、Server.ex、FS.eyに0.166667移動でSMTP.c "SMTPサーバ" として、ljustで.Nとの.cボックスINVIS HT 0.25 "とメール"; myarrow(0.5) 0.5、FS.s.y .PE .DEで.swの箱HT 0.666667 "ファイル" "システム" \

produces as output:


The SMTP design can be pictured as:


   +-------+    +----------+                 +----------+
   | User  |<-->+          |                 |          |
   +-------+    |          |      SMTP       |          |
                |          |Commands/Replies |          |
   +-------+    | Client-  |<--------------->+ Server-  |    +-------+
   |       |    |  SMTP    |    and Mail     |  SMTP    |    |       |
   | File  |<-->+          |                 |          |<-->+ File  |
   |System |    |          |                 |          |    |System |
   +-------+    +----------+                 +----------+    +-------+
                SMTP client                  SMTP server

Appendix B. Disclaimers


This document has exactly one (1) author.


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.

この文書の定型セクション内の「/ SHE」、「その」、および「著者」(複数)の存在は無関係です。本書の著者は、ボイラープレート・テキストのための責任を負いません。

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.


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、ジョセフ・F、 "NROFF / TROFFユーザーズマニュアル"、コンピューティング科学技術研究報告No.54、ベル研究所、マリーヒル、ニュージャージー州、1976年。

[N2.BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[N2.BCP14]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]解放され、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]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション(MIME)第一部:インターネットメッセージ本体のフォーマット"、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.

、RFC 2231、1997年11月:[N5.RFC2231]、N.、およびK.ムーア、 "文字セット、言語、および継続のMIMEパラメータ値およびエンコードされたWordの拡張機能を" フリード。

[N6.Errata] RFC-Editor errata page,

[N6.Errata] RFC-エディタの正誤表ページ、

Informative References


[I1.RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.

【I1.RFC2223]ポステル、J.、およびJ.レイノルズ、RFC 2223、1997年10月 "RFC作者への指示"。

[I2.Lilly05] Lilly, B., "Writing Internet-Drafts and Requests For Comments using troff and nroff", Work in Progress, May 2005.


[I3.RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.

[I3.RFC4288]解放され、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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、「ハイパーテキスト転送プロトコル - 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]ホフマン、P.及び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 - テーブルを設定するためのプログラム"、ベル研究所コンピューティング科学技術報告書#49、マレー・ヒル、ニュージャージー州、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]ベントレー、ジョンL.とカーニハン、ブライアンW.、「GRAP - 組版グラフチュートリアルのための言語およびユーザーマニュアル」、コンピューティング科学技術レポートNo.114、AT&Tベル研究所、マリーヒル、ニュージャージー州、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.

、コンピューティング科学技術レポートNo.116、AT&Tベル研究所、マリーヒル、ニュージャージー州、1991年 - 「組版ユーザーマニュアル用グラフィックス言語ピック」[I9.CSTR116]カーニハン、ブライアンW.、。

[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]ベントレー、ジョンL.、Jelinski、リンW.、およびカーニハン、ブライアンW.、 "CHEM - 組版化学図のためのプログラム:ユーザーマニュアル"、コンピューティング科学技術レポートNo.122、AT&Tベル研究所、マレーヒル、ニュージャージー州、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]カーニハン、ブライアンW、及びチェリー、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]ベントレー、ジョンL.「DFORMAT - 組版データ形式のためのプログラム」、コンピューティング科学技術報告書142号、AT&Tベル研究所、マリーヒル、ニュージャージー州、1988。

[I13.UNIXman1] AT&T Bell Laboratories, "UNIX TIME-SHARING SYSTEM (VOLUME 1) : UNIX Programmer's Manual", Holt, Rinehart, & Winston, 1979

[I13.UNIXman1] AT&Tベル研究所、 "UNIXタイムシェアリングシステム(VOLUME 1):UNIXプログラマーズマニュアル"、ホルト、ラインハート、&ウィンストン、1979

[] Allman, Eric P., "Writing Papers With NROFF Using -me", USD:19, University of California, Berkeley, Berkeley, California, 1997.

[]オールマン、エリック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ベル研究所、 "UNIX System VのDocumenterのWorkbenchユーザーズ・ガイド"、プレンティス・ホール、1989

[] 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

[] Lesk、ME、 "UNIXシステムでのタイピングドキュメント:troffのとNROFFを使用した-msマクロの使用" で、1978年、 "UNIXタイムシェアリングシステム(VOLUME 2):UNIXプログラマーズマニュアル"、ホルト、ラインハート、&​​ウィンストン、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.、ドルナー、S.、およびK.ムーア、 "インターネット・メッセージでプレゼンテーション情報を伝える:コンテンツ-Dispositionヘッダーフィールド"、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]解放され、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




Full Copyright Statement


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に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。


この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、(もしあれば)後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

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


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は、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。



Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).