RFC4263 日本語訳

4263 Media Subtype Registration for Media Type text/troff. B. Lilly. January 2006. (Format: TXT=33371 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                           B. Lilly
Request for Comments: 4263                                  January 2006
Category: Informational

コメントを求めるワーキンググループB.リリー要求をネットワークでつないでください: 4263 2006年1月のカテゴリ: 情報

          Media Subtype Registration for Media Type text/troff

メディアTypeテキスト/troffのためのメディアSubtype Registration

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)インターネット協会(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

1. 序論… 2 2. 要件レベル… 3 3. 仕様の範囲… 3 4. 登録フォーム… 3 5. 承認… 8 6. セキュリティ問題… 8 7. 国際化問題… 8 8. IANA問題… 9 付録A.の例… 10 A.1。 データの形式… 10 A.2。 簡単なダイヤグラム… 11 付録B.注意書き… 12 標準の参照… 13 有益な参照… 13

Lilly                        Informational                      [Page 1]

RFC 4263                 Media Type text/troff              January 2006

リリーInformational[1ページ]RFC4263メディアTypeテキスト/troff2006年1月

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

それは時々プレゼンテーションのための特定の方法で形式テキストに望ましいです。 1つのアプローチはフォーマットされるために並置における形式指示をテキストに提供することです。 そのアプローチは、非フォーマットされたフォーム(形式指示を無視するのによる)でテキストを読むことを許可します、そして、それは異なったメディアのために適当な変更を形式指示かそれらが作動する環境にすることによって、テキストの比較的簡単な再決意を許可します。 そのモデルに従った形式テキストのための関連するプログラムの1つの特定のシリーズがしばしば一般的に"troff"と呼ばれます、また、それは特に植字工のための形式テキストのためのそのジェネリックカテゴリの中のプログラムと植字工のようなデバイスの特定の家系の名前ですが。 通常、(フォーマットされます)プレーンテキストなどのキャラクタベースの出力に使用されるジェネリック"troff"カテゴリの中の関連するフォーマット・プログラムは"nroff"として知られています。 ここで定義されたメディアタイプの目的について、全体のカテゴリは単にジェネリック"troff"名によって言及されるでしょう。 異なったセットのプログラムとしてのTroffは最初に1970年代前半の[N1.CSTR54]に現れました、いくつかの以前のプログラム(「決勝戦」と"roff")で使用される同じ形式アプローチに基づいて。 それは様々な形式で書類を提示するのに使用されました、短いメモから本まで長さのねらいを定めて(テーブル、ダイヤグラム、および他の非原文の内容を含んでいて)。 それはこのドキュメントの日付付けで広い使用のままで残っています。 このドキュメント自体は、[I1.RFC2223]と[I2.Lilly05]あたりのツールの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.

基本形式(テキストと形式指示を並置する)は、広げることができて、テキストとグラフィカルなドキュメント内容の関連する形式に使用されました。 通常、フォーマットは1セットのマクロによって制御されます。 マクロ・パッケージは1セットの関連する形式ツールです、troff形式(また、圧縮された2進法表示は使用されましたが)で書かれていて、ドキュメント作者のために形式能力を広げて、管理するのに基本的な形式指示を使用して。 何らかの内容の原文の記述を並置されたテキストに変える多くのプリプロセッサと何らかの必要な出力を起こすのに必要な形式指示があります。 プリプロセッサはグラフとして知られているテキストと非原文の物質的で、数学の方程式、化学公式、一般的な線画のテーブル、データ(企まれたコーディネートしているグラフ、棒グラフなどにおける)のグラフ表示、データ形式の表現、および抽象的な数学の構造物の表現の形式のために存在しています(ノードと縁から成って)。 そのような多くのプリプロセッサが同じ一般型のフォーマッタへの入力フォーマットを使用します、そして、そのような入力はメディアタイプの範囲の中で明らかに本書では説明されます。

Lilly                        Informational                      [Page 2]

RFC 4263                 Media Type text/troff              January 2006

リリーInformational[2ページ]RFC4263メディアTypeテキスト/troff2006年1月

2.  Requirement Levels

2. 要件レベル

   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」“SHOULD"、「」、「推薦された」、およびこのドキュメントの「5月」は[N2.BCP14]で説明されるように解釈されることになっているべきです。

3.  Scope of Specification

3. 仕様の範囲

   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.

説明されたメディアタイプはプリプロセッサとページフォーマッタによって処理されるかもしれない入力について言及します。 内容が何らかの内容のマシン処理なしで分かりやすいかもしれない(そういうもののテキストとした、または、非テキスト内容の読み込み可能な記述とした)テキストを持っているところで使用されるのは意図しています。 ほとんど分かりやすいテキスト内容がない、このメディアタイプSHOULD NOTがあるところに、いてください。使用されます。 例えば、「映画」プリプロセッサの出力は確かに形式指示のtroffコンパチブル系列から成りますが、どんな存在するかもしれないテキストでも点在した個々の指示の全くの数で読解は難しくなりますが、プリプロセッサ入力言語(下の登録の「広められた仕様」セクションで説明されるように)はグラフィカルな内容の簡潔で分かりやすい記述を提供するかもしれません。 アプリケーションメディアタイプの「副-タイプ」として形式指示の大部分を含んでいるプリプロセッサ出力をラベルするだろうというのは最も良いです。 特定のプリプロセッサ投入含有量がテキストでまずグラフィカルな内容だけについて説明しないかどうかと、どれがグラフィカルな要素の原文の記述、イメージメディアタイプの「副-タイプ」から容易に何か分かりやすいかは、適切でないでしょう。 メディアを内容に分類する目的は内容の使用を容易にするためにその内容の情報を提供することです。 特定のラベルの使用は何らかの常識と判断を必要とします、そして、そのような判断がないとき内容に適用されて、SHOULD NOTが機械的に必要です。

4.  Registration Form

4. 登録用紙

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

登録手順とフォームは[I3.RFC4288]で指定されます。

   Type name: text

型名: テキスト

   Subtype name: troff

Subtypeは以下を命名します。 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

charset: 登録されたcharsetがMIMEとの使用であったに違いないなら、テキストは[N3.RFC2046]をタイプします、トランスポート・プロトコルがその制限から明らかに免除されているところを除いて。 メディア内容のcharsetを指定します。 伝統的なソース内容で、これはそうでしょう。

Lilly                        Informational                      [Page 3]

RFC 4263                 Media Type text/troff              January 2006

リリーInformational[3ページ]RFC4263メディアTypeテキスト/troff2006年1月

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

デフォルト「米国-ASCII」charset。 troff処理ソフトウェアのいくつかの最近のバージョンがユニコード入力charsetsを扱うことができます。 しかしながら、入力がそのような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]によって備えられるように、引用されるか、またはコード化される必要があるかもしれません。 実装を生成すると、実行可能な内容はコード化されてはいけません、そして、他の実装はパラメタ価値のどんな実行の、または、他の解釈も試みてはいけません、パラメタ値が散文テキストであるかもしれないので。 情報がメディアタイプに関係づけたように実装SHOULDはパラメタ(継続パラメタなどの再アセンブリの後の)を提示します、特にメディア内容がすぐに利用可能でないなら(例えば、外部のメッセージ/ボディーの合成メディア[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.

系列結末が[N3.RFC2046]単位でcanonicalizedされるなら、伝統的なtroffに、7ビットは適切です。 [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 charset[I4.RFC3629](輸送メソッドは可能にします、そして、満足している行長は8ビットの内容が適当である)を使用することで使用されるかもしれません。 また、丈夫さのために問題をコード化する輸送は適用されるかもしれません、そして、メカニズムをコード化する適当な8ビットが標準化されるなら、メディアの保護に、輸送の間、適切であるかもしれません。

Lilly                        Informational                      [Page 4]

RFC 4263                 Media Type text/troff              January 2006

リリーInformational[4ページ]RFC4263メディアTypeテキスト/troff2006年1月

      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]に噛み付いて、ユニコード文字がUTF-16[I6.RFC2781]などの非MIME charsetを通して移されるかもしれない環境(例えば、HTTP[I5.RFC2616])で使用されるかもしれないのが必要であるかもしれません。

      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)が処理の間、外部のファイル(そして/または、ファイルシステム意味論でデバイス入力をサポートするシステムの上のデバイス)を読むかもしれません。 数台のプリプロセッサには、同様の特徴があります。 いくつかの実装には、これらの特徴のいくつかを無効にする「安全な」モードがあります。 フォーマッタとプリプロセッサはプログラマブルです、そして、サービスの否定をもたらすことができた無限ループを指定する入力を提供するのは可能です、外部のリソースにアクセスする指示の使用を制限する実装でさえ。 このメディアのユーザはSHOULDをタイプします。信頼できないソースから得られたメディアの不注意な処理でもたらされるかもしれない損害の可能性は用心深くいてください。

      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.

処理して、施設以外の潜在的に危険な指示を剥取るか、または無視するこのメディアタイプ、およびプリプロセッサ、そして/または、ポストプロセッサ、SHOULD NOTによる処理では、自動的(すなわち、ユーザ確認なしで)に呼び出されてください。 いくつかの場合、全く処理なしでメディアにタイプを提示するのは、これがテキストメディアタイプ(すなわち、それは処理なしで分かりやすいテキストを含んでいる)であるので、十分であるかもしれません。 しかしながら、いかなる他のテキストメディアのようにも、このメディアタイプは制御文字を含むかもしれません、そして、implementers SHOULDはデバイスを表示するために生の制御文字を送る不運な結果に対して予防策を講します。

      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.

SHOULDが慎重に精査するこのメディアタイプのユーザはソーシャルエンジニアリングへの試みとパラメタのほとんど考えられなかった値の効果のための「プロセス」パラメタに関連づけられるか、メディアの中にコメントに含まれているか、または外部のメカニズムで伝えられたコマンドラインを勧めました。 いくつかの実装には「安全な」モードがあるかもしれない間、このメディアタイプを使用する人は、それらが利用可能であるか、またはアクティブであると推定してはいけません。

      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

コメントはtroffソースに含まれるかもしれません。 コメントは出力のためにフォーマットされません。 しかしながら、それらはもちろんtroffドキュメントソースで読み込み可能です。 作者は慎重であるはずです。

Lilly                        Informational                      [Page 5]

RFC 4263                 Media Type text/troff              January 2006

リリーInformational[5ページ]RFC4263メディアTypeテキスト/troff2006年1月

      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.

グラフィックスでテキストをかぶせたか、またはそうでなければ、フォーマットされると目視によりテキストをあいまいにする書式設定命令を起こすのが可能である間、そのような測定は、ドキュメントソースからテキストを抜粋するのを防がないで、電子的にフォーマットされるとテキストをあいまいにするのにおいて効力がないかもしれません、例えば、ポストスクリプトか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.

相互運用性問題: フォーマッタ、マクロ・パッケージ、およびプリプロセッサの最近の実装は以前の実装にいくつかの存在していない拡張能力を含むかもしれません。 そのような拡張子の使用は明らかにサイトでそれらの拡大をサポートしない実装で一貫したフォーマット付き出力を起こす能力を制限します。 このメディアを使用する特定のドキュメントにおけるどんなそのような拡張子の使用もSHOULDをタイプします。「バージョン」パラメタ価値で、示されます。

      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.

Introductionで言及されるように、マクロ・パッケージは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.

いくつかのプリプロセッサかポストプロセッサがいくつかのサイトで入手できないかもしれません。 何らかの実装が入手できるところに、起こされた出力に影響する実装の違いがあるかもしれません。 例えば、「映画」プリプロセッサのいくつかのバージョンが境界があるグラフィカルなオブジェクトをいっぱいにする能力を提供します。 他のものはその能力を欠いています。 その特徴をサポートするものには、確実な中詰めが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

様々なプレゼンテーションメディアの能力の広い変化があります、そして、デバイスはプレゼンテーションのために以前はよく内容を準備していました。 本当に、それは2つの基本的なフォーマッタプログラムタイプ(出力のための限られた形式コントロールが利用可能であるnroff、および、より大きい範囲のコントロールが可能であるtroff)がある1つの理由です。 明確に、より簡単なメディアかデバイスが、ある能力を欠いていて、複雑であるか洗練された形式を使用するように設計されたドキュメントは「表-可能」でないかもしれません。 しばしば、いくらか劣った近似を起こすのは可能です。 アクセント記号付き文字、グレー・スケールが評価するように色は表されるかもしれません。

Lilly                        Informational                      [Page 6]

RFC 4263                 Media Type text/troff              January 2006

リリーInformational[6ページ]RFC4263メディアTypeテキスト/troff2006年1月

      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]

広められた仕様: [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]、映画[I9.CSTR116]、chem[I10.CSTR122]、eqn[I11.eqn]、dformat[I12.CSTR142]

      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]

マクロ・パッケージ: 男性[I13.UNIXman1]、私、[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").

マジックナンバー(s): なにも。 しかしながら、満足している形式は特有です(「広められた仕様」を見てください)。

      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): ファイルはどんな特定の「拡大」も必要としません。 多くがファイル、特定のマクロ・パッケージに関連しているいくつかまたはプリプロセッサの機械化された処理のための便利として使用中です。 他のものは臨時です。 ファイル名は内容の本質と直交しています。 ファイル名か名前の成分が何人かのタイプのファイルの自動化された処理で役に立つかもしれない間、名前かコンポーネントが原文(イメージか形式指示と対照的に)の内容の割合などの微妙さを特に、示すことができないかもしれません。 このメディアはどんなファイルとの割り当てられたa関係も個々のファイルのためにその関係をくつがえすのに使用されるかもしれない人間の判断への支給がない場合内容が信頼されていないかもしれない「拡大」であったならSHOULD NOTをタイプします。 適切であるところでは、ファイル名が[N5.RFC2231]と[N6.Errata]によって修正されるように[I17.RFC2183]で指定されたものなどの適当なメカニズムによって示されるかもしれません。

Lilly                        Informational                      [Page 7]

RFC 4263                 Media Type text/troff              January 2006

リリーInformational[7ページ]RFC4263メディアTypeテキスト/troff2006年1月

      Macintosh File Type Code(s): unknown

マッキントッシュファイルタイプは(s)をコード化します: 未知

   Person & email address to contact for further information:
      Bruce Lilly
      blilly@erols.com

詳細のために連絡する人とEメールアドレス: ブルースリリー 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.

一貫性: メディアには、コメントへの支給があります。 これらは、お勧めの処理命令を伝えて、必要なリソースなどを示すのに時々使用されます。 受取人を混乱させるのを避けるために、送付者SHOULDは、任意のパラメタで指定された情報がメディア内容の中に含まれているどんな関連情報とも一致しているのを確実にします。

5.  Acknowledgements

5. 承認

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

作者はietf-タイプメーリングリストのメンバーによって提供された役に立つコメントを承諾したがっています。

6.  Security Considerations

6. セキュリティ問題

   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

7. 国際化問題

   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はテキストのディスプレイのための処理で運ばれるかもしれません。 他の場合では、特定の系列における、八重奏の組み合わせは、満足しているcharsetに直接表すことができないglyphsを表すのに使用されます。 それらのカテゴリのどちらかでは、テキストの言語はキャラクタ内容から明白でないかもしれません、そして、適当なメカニズム(例えば、[I19.RFC3282])がそのようなメカニズムが利用可能であるテキスト言語[I20.BCP18]を伝えるのに使用されるのは、RECOMMENDEDです。 複数の言語がただ一つのドキュメントの中に使用されるところでは、直接内容における、言語の明白なしるしを通して言語を読者に示すのは、必要であるか、または望ましいかもしれません。 まだ他の場合では、メディアタイプ内容(テキストフォームで読み込み可能であって、分かりやすいのですが)は数学の方程式や化学公式や、どれが主にグローバルであるか、そして、言語独立者などのシンボリックであるかグラフィカルな情報を表します。

Lilly                        Informational                      [Page 8]

RFC 4263                 Media Type text/troff              January 2006

リリーInformational[8ページ]RFC4263メディアTypeテキスト/troff2006年1月

8.  IANA Considerations

8. IANA問題

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

IANAは指示されるとしてのIESGによるメディアタイプ登録でレジスト情報を入力して、維持するものとします。

Lilly                        Informational                      [Page 9]

RFC 4263                 Media Type text/troff              January 2006

リリーInformational[9ページ]RFC4263メディアTypeテキスト/troff2006年1月

Appendix A.  Examples

付録A.の例

A.1.  Data Format

A.1。 データの形式

   The input:

入力:

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

コンテントタイプ: テキスト/troff。 プロセス="dformat"| 映画-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 %%BODY%%Version
       4-7 IHL
       8-15 %%BODY%%Type of Service
       16-31 Total Length
      noname
       0-15 Identification
       16-18 %%BODY%%Flags
       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スタイル中詰めオフスタイルbitwid0.20スタイルrecspread0はLive8-15プロトコル16-31Header Checksum noname0-31Source Address noname0-31Destination Address noname0-23Options24-31Padding .endへのService16-31Total Length noname0-15Identification16-18%%BODY%%Flags19-31Fragment Offset noname0-7Timeの0.33333noname0-3円の0Version4-7IHL8-15%%BODY%%Typeでrechtを流行に合わせます。

   produces as output:

出力されるように、生産します:

   Here's what an IP packet header looks like:

ここに、IPパケットのヘッダーが似ているものがあります:

Lilly                        Informational                     [Page 10]

RFC 4263                 Media Type text/troff              January 2006

リリーInformational[10ページ]RFC4263メディアTypeテキスト/troff2006年1月

   +-------+-------+---------------+-------------------------------+
   |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+

+-------+-------+---------------+-------------------------------+ |バージョン| IHL|サービスのタイプ| 全長| 0------34------78-------------1516----+-----------------------31+ | 識別|旗| 断片オフセット| 0---------------+-------------1516--1819----------------------31+ | 生きる時間| プロトコル| ヘッダーチェックサム| 0--------------78-------------1516----------------------------31+ | ソースアドレス| 0-------------------------------------------------------------31+ | 送付先アドレス| 0-----------------------------------------------+-------------31+ | オプション| 詰め物| 0---------------------------------------------2324------------31+

A.2.  Simple Diagram

A.2。 簡単なダイヤグラム

   The input:

入力:

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

コンテントタイプ: テキスト/troff。 プロセス=は「映画-nの当時の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

#.DS B.PS boxwid=0.8に、troffで許容できるように見える矢の近似とnroffはmyarrow X A:を定義します。 正しい0.055を動かしてください; \"<"ljust、[正しい0.045に正しい(1--0.1ドル)(">"rjust)の\移動を裏打ちしてください]\Xユーザ: 箱のht0.333333「ユーザ」FS: 箱ht0.666667はUser.s-0、0.333333Clientの.nで「システム」を「ファイルします」: 箱ht1.333333のwid1.1、「クライアント、\、-」 FS.se+0.5の.swがある"SMTP"\、Client.se-0、0.166667の0「SMTPクライアント」rjustはUser.eに移行します。 FS.eへのmyarrow(0.5)移動。 Client.eへのmyarrow(0.5)移動。 SMTP: myarrow(1.8)サーバ: 箱ht1.333333のwid1.1、「SMTP.c「SMTPサーバー」における.nがある0.25と「メール」がServer.sw-0、0.166667でljustするサーバ」 .swがHere.xにある"SMTP"\、Client.s.y箱invis ht0.5の"SMTP"がSMTP.cの.sで「/が返答すると命令する」という\箱のinvis htはServer.e.xに移行します、FS.e.y。 myarrow(0.5) FS2: .swがServer.se.x+0.5、FS.s.y.PE .DEにある箱のht0.666667「ファイル」「システム」\

Lilly                        Informational                     [Page 11]

RFC 4263                 Media Type text/troff              January 2006

リリーInformational[11ページ]RFC4263メディアTypeテキスト/troff2006年1月

   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

+-------+ +----------+ +----------+ | ユーザ| <-->+| | | +-------+ | | SMTP| | | |コマンド/回答| | +-------+ | クライアント| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-->+サーバ| +-------+ | | | SMTP| そして、メール| SMTP| | | | ファイル| <-->+| | | <-->+ファイル| |システム| | | | | |システム| +-------+ +----------+ +----------+ +-------+ SMTPクライアントSMTPサーバ

Appendix B. Disclaimers

付録B.注意書き

   This document has exactly one (1) author.

このドキュメントには、ちょうど1(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.

「」 /の存在、彼女、」、「」 このドキュメントの決まり文句の部のそれらの「作者」(複数)は無関係です。 このドキュメントの作者は決まり文句のテキストに責任がありません。

   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に向けられるべきです。

Lilly                        Informational                     [Page 12]

RFC 4263                 Media Type text/troff              January 2006

リリーInformational[12ページ]RFC4263メディアTypeテキスト/troff2006年1月

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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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を分けます」。 「メディアタイプ」、RFC2046、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)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、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]、N.、およびK.ムーア、「パラメタ値をまねてください、そして、コード化されて、拡大を言い表してください」 「文字コード、言語、および続刊」、RFC2231、11月1997日

   [N6.Errata]    RFC-Editor errata page,
                  http://www.rfc-editor.org/errata.html

[N6.Errata]RFC-エディタ誤字ページ、 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] ポステル、J.、およびJ.レイノルズ、「指示、RFCが書く、」、RFC2223、10月1997日

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

B. [I2.Lilly05]リリー、Progress、2005年5月の「troffとnroffを使用することでインターネット草稿とRequests For Commentsに書く」Work。

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

解放された[I3.RFC4288]とN.とJ.Klensin、「メディアは仕様と登録手順をタイプする」BCP13、RFC4288、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、ISO10646の変化形式」STD63、RFC3629、11月2003日

   [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.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」

   [I6.RFC2781]   Hoffman, P. and F. Yergeau, "UTF-16, an encoding of
                  ISO 10646", RFC 2781, February 2000.

[I6.RFC2781]ホフマン、2000年2月のP.とF.Yergeau、「UTF-16、ISO10646のコード化」RFC2781。

Lilly                        Informational                     [Page 13]

RFC 4263                 Media Type text/troff              January 2006

リリーInformational[13ページ]RFC4263メディアTypeテキスト/troff2006年1月

   [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--Aはテーブルの用意をするためにプログラムを作ります」、ベル研究所が科学技術報告書#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.

[I9.CSTR116]カーニハン、ブライアンW.、「映画--科学技術報告書No.116を計算することでのAT&Tベル研究所、マリー・ヒル(ニュージャージー)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]ベントリーとジョン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.

182-193、1975ACM18、年の[I11.eqn]カーニハン、ブライアンWとチェリー、ローリンダL.、「植字数学のシステム」コミュニケーション。

   [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]ベントリー、「DFORMAT--Aは植字データ形式のためにプログラムを作ります」、科学技術報告書No.142、AT&Tベル研究所を計算してジョンL.マリー・ヒル(ニュージャージー)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時分割システム(第1巻):」 「UNIXプログラマのマニュアル」、ホルト、ラインハート、およびウィンストン、1979

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

[I14.me]オールマン、エリックP.、「NROFF使用がある筆記用紙、-、私、」、U.S.ドル: 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システム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プログラマのマニュアル」、ホルト、ラインハート、およびウィンストン、1979

Lilly                        Informational                     [Page 14]

RFC 4263                 Media Type text/troff              January 2006

リリーInformational[14ページ]RFC4263メディアTypeテキスト/troff2006年1月

   [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.ムーア、「中でプレゼンテーション情報を伝えて、インターネットは通信します」。 「満足している気質ヘッダーフィールド」、RFC2183、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を分けます」。 「順応評価基準と例」、RFC2049、11月1996日

   [I19.RFC3282]  Alvestrand, H., "Content Language Headers", RFC 3282,
                  May 2002.

[I19.RFC3282]Alvestrand(H.、「満足している言語ヘッダー」、RFC3282)は2002がそうするかもしれません。

   [I20.BCP18]    Alvestrand, H., "IETF Policy on Character Sets and
                  Languages", BCP 18, RFC 2277, January 1998.

[I20.BCP18] Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、1998年1月。

Author's Address

作者のアドレス

   Bruce Lilly

ブルース・リリー

   EMail: blilly@erols.com

メール: blilly@erols.com

Lilly                        Informational                     [Page 15]

RFC 4263                 Media Type text/troff              January 2006

リリーInformational[15ページ]RFC4263メディアTypeテキスト/troff2006年1月

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Lilly                        Informational                     [Page 16]

リリーInformationalです。[16ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

FLOOR関数 最大の整数値(小数点以下の切捨て)

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る