RFC1111 日本語訳

1111 Request for comments on Request for Comments: Instructions to RFCauthors. J. Postel. August 1989. (Format: TXT=11793 bytes) (Obsoletes RFC0825) (Obsoleted by RFC1543, RFC2223) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                          J. Postel
Request for Comments: 1111                                           ISI
Obsoletes: 825                                               August 1989

コメントを求めるワーキンググループJ.ポステルの要求をネットワークでつないでください: 1111ISIは以下を時代遅れにします。 825 1989年8月

              Request for Comments on Request for Comments

コメントのための要求に応じてコメントを求める要求

                      Instructions to RFC Authors

RFC作者への指示

Status of this Memo

このMemoの状態

   This RFC specifies a standard for the Internet community.  Authors of
   RFCs are expected to adopt and implement this standard.  Distribution
   of this memo is unlimited.

このRFCはインターネットコミュニティの規格を指定します。 RFCsの作者は、この規格を採用して、実行すると予想されます。 このメモの分配は無制限です。

1.  Introduction

1. 序論

   RFCs are distributed online by being stored as public access files,
   and a short message is sent to the distribution list indicating the
   availability of the memo.

パブリックアクセスがファイルされるとき、格納されることによって、オンラインでRFCsを分配します、そして、メモの有用性を示す発送先リストに短いメッセージを送ります。

   The online files are copied by the interested people and printed or
   displayed at their site on their equipment.  (An RFC may also be
   returned via email in response to an email query.)  This means that
   the format of the online files must meet the constraints of a wide
   variety of printing and display equipment.

彼らの設備に関する彼らのサイトにオンライン・ファイルを関心がある人々がコピーして、印刷するか、または表示します。 (また、メール質問に対応したメールでRFCを返すかもしれません。) これは、オンライン・ファイルの形式がさまざまな印刷と表示設備の規制を満たさなければならないことを意味します。

2.  Format Rules

2. 形式規則

   To meet the distribution constraints the following rules are
   established for the two allowed formats for RFCs:  ASCII and
   PostScript.

分配規制を満たすために、以下の規則はRFCsのための2つの許容形式のために確立されます: ASCIIとポストスクリプト。

   The RFC Editor attempts to ensure a consistent RFC style.  To do this
   the RFC Editor may choose reformat the RFC submitted.  It is much
   easier to do this if the submission matches the style of the most
   recent RFCs.  Please do look at some recent RFCs and prepare yours in
   the same style.

RFC Editorは、一貫したRFCスタイルを確実にするのを試みます。 これをするために、RFC EditorはRFCが提出した再フォーマットを選ぶかもしれません。 服従が最新のRFCsのスタイルに合っているなら、これをするのははるかに簡単です。 いくつかの最近のRFCsを見て、同じスタイルであなたのものを用意してください。

   You must submit an editable online document to the RFC Editor.  The
   RFC Editor may require minor changes in format or style and will
   insert the actual RFC number.

あなたは編集可能なオンラインドキュメントをRFC Editorに提出しなければなりません。 RFC Editorは形式かスタイルにおけるマイナーチェンジを必要とするかもしれなくて、実際のRFC番号を挿入するでしょう。

   2a.  ASCII Format Rules:

2a。 ASCII形式は統治されます:

      The character codes are ASCII.

キャラクタコードはASCIIです。

      Each page must be limited to 58 lines followed by a form feed on a

aで各ページを改ページがあとに続いた58の線に制限しなければなりません。

Postel                                                          [Page 1]

RFC 1111                    RFC Instructions                 August 1989

ポステル[1ページ]RFC1111RFC指示1989年8月

      line by itself.

それ自体で立ち並んでください。

      Each line must be limited to 72 characters followed by carriage
      return and line feed.

各線を復帰と改行があとに続いた72のキャラクタに制限しなければなりません。

      No overstriking (or underlining) is allowed.

「過剰-打撃」(または、アンダーラインを引く)は許容されていません。

      These "height" and "width" constraints include any headers,
      footers, page numbers, or left side indenting.

これらの「高さ」と「幅」規制はどんなヘッダー、フッター、ページ番号、または左側の入り込むことも含んでいます。

      Do not fill the text with extra spaces to provide a straight right
      margin.

まっすぐなライト・マージンを提供するために余分な空間でテキストを満たさないでください。

      Do not do hyphenation of words at the right margin.

ライト・マージンで単語のハイフン付きをしないでください。

      Do not use footnotes.  If such notes are necessary, put them at
      the end of a section, or at the end of the document.

脚注を使用しないでください。 そのような注意が必要であるなら、セクションの端において、または、ドキュメントの端においてそれらを置いてください。

      Use single spaced text within a paragraph, and one blank line
      between paragraphs.

パラグラフの間でパラグラフ、および1つの空白行の中のただ一つの区切られたテキストを使用してください。

      RFCs in ASCII Format may be submitted to the RFC Editor in email
      messages (or as online files) in either the finished publication
      format or in NROFF.  If you plan to submit a document in NROFF,
      please consult the RFC Editor first.

終わっている公表形式かNROFFのメールメッセージ(またはオンライン・ファイルとして)のRFC EditorにASCII FormatのRFCsを提出するかもしれません。 NROFFのドキュメントを提出するのを計画しているなら、最初に、RFC Editorに相談してください。

   2b.  PostScript Format Rules

2b。 ポストスクリプト形式規則

   Standard page size is 8 1/2 by 11 inches.

標準のページ・サイズは8 1/2×11インチです。

      Margin of 1 inch on all sides (top, bottom, left, and right).

四方(先端、下部、左、および右)の1インチのマージン。

      Main text should have a point size of no less than 10 points with
      a line spacing of 12 points.

主なテキストには、少なくとも10ポイントのポイントサイズが12ポイントの線スペースと共にあるべきです。

      Footnotes and graph notations no smaller than 8 points with a line
      spacing of 9.6 points.

9.6ポイントの線スペースがある8ポイントほど小さくない脚注と図表注釈。

      Three fonts are acceptable: Helvetica, Times Roman and Courier
      Plus their bold-face and italic versions.  These are the three
      standard fonts on most PostScript printers.

3つの字体が許容しています: Helvetica、タイムズのローマン、およびCourier Plusの彼らの太字の、そして、イタリック体のバージョン。 これらはほとんどのポストスクリプトプリンタの3つの標準の字体です。

      Prepare diagrams and images based on lowest common denominator
      PostScript.  Consider common PostScript printer functionality and
      memory requirements.

最小公分母ポストスクリプトに基づくダイヤグラムとイメージを用意してください。 一般的なポストスクリプトがプリンタの機能性とメモリ要件であると考えてください。

      The following PostScript commands should not be used:
      initgraphics, erasepage, copypage, grestoreall, initmatrix,

以下のポストスクリプトコマンドを使用するべきではありません: initgraphics、erasepage、copypage、grestoreall、initmatrix

Postel                                                          [Page 2]

RFC 1111                    RFC Instructions                 August 1989

ポステル[2ページ]RFC1111RFC指示1989年8月

      initclip, banddevice, framedevice, nulldevice and renderbands.

initclip、banddevice、framedevice、nulldevice、およびrenderbands。

      These PostScript rules are likely to changed and expanded as
      experience is gained.

経験するのに応じて、規則がありそうであるこれらのポストスクリプトは、変化して、広がりました。

      RFCs in PostScript Format may be submitted to the RFC Editor in
      email messages (or as online files).  Since PostScript is not
      editable, an editable source version of the document must also be
      submitted.  If you plan to submit a document in PostScript, please
      consult the RFC Editor first.

メールメッセージ(またはオンライン・ファイルとして)のRFC EditorにポストスクリプトFormatのRFCsを提出するかもしれません。 ポストスクリプトが編集可能でないので、また、ドキュメントの編集可能なソースバージョンを提出しなければなりません。 ポストスクリプトでドキュメントを提出するのを計画しているなら、最初に、RFC Editorに相談してください。

3.  Status Statement

3. 状態声明

   Each RFC must include on its first page the "Status of this Memo"
   section which contains a paragraph describing the intention of the
   RFC.  This section is meant to convey the status granted by the RFC
   Editor and the Internet Activities Board (IAB).  There are several
   reasons for publishing a memo as an RFC, for example, to make
   available some information for interested people, or to begin or
   continue a discussion of an interesting idea, or to make available
   the specification of a protocol.

各RFCは、最初のページ「このMemoの状態」部にどれがRFCの意志について説明するパラグラフを含むかを含まなければなりません。 このセクションはRFC EditorとインターネットActivities Board(IAB)によって与えられた状態を伝えることになっています。 関心がある人々への何らかの情報を利用可能にするか、おもしろい考えの議論を始まるか、続けている、またはプロトコルの仕様を利用可能にするように、例えば、RFCとしてメモを発表するいくつかの理由があります。

      The following sample paragraphs may be used to satisfy this
      requirement:

以下のサンプルパラグラフはこの要件を満たすのに使用されるかもしれません:

         Proposed Protocol

提案されたプロトコル

            This RFC suggests a proposed protocol for the Internet
            community, and requests discussion and suggestions for
            improvements.

このRFCは改良のためにインターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。

         Specification

仕様

            This RFC specifies a standard for the Internet community.
            Hosts on the Internet are expected to adopt and implement
            this standard.

このRFCはインターネットコミュニティの規格を指定します。 インターネットのホストは、この規格を採用して、実行すると予想されます。

         Discussion

議論

            The purpose of this RFC is to focus discussion on particular
            problems in the Internet and possible methods of solution.
            No proposed solutions this document are intended as
            standards for the Internet.  Rather, it is hoped that a
            general consensus will emerge as to the appropriate solution
            to such problems, leading eventually to the adoption of
            standards.

このRFCの目的はインターネットの特定の問題と解決策の可能な方法に議論の焦点を合わせることです。 これが記録しない提案された解決策は全くインターネットの規格として意図します。 むしろ、全体的な合意がそのような問題の適切な解決に関して現れることが望まれています、結局規格の採用に通じて。

Postel                                                          [Page 3]

RFC 1111                    RFC Instructions                 August 1989

ポステル[3ページ]RFC1111RFC指示1989年8月

         Information

情報

            This RFC is being distributed to members of the Internet
            community in order to solicit their reactions to the
            proposals contained in it.  While the issues discussed may
            not be directly relevant to the research problems of the
            Internet, they may be interesting to a number of researchers
            and implementers.

このRFCは、それに含まれた提案への彼らの反応に請求するためにインターネットコミュニティのメンバーに分配されています。 議論した問題が直接インターネットの研究課題に関連していないかもしれない間、それらは多くの研究者とimplementersにおもしろいかもしれません。

         Status

状態

            In response to the need for maintenance of current
            information about the status and progress of various
            projects in the Internet community, this RFC is issued for
            the benefit of community members.  The information contained
            in this document is accurate as of the date of publication,
            but is subject to change.  Subsequent RFCs will reflect such
            changes.

状態に関する現行情報の維持とインターネットコミュニティでの様々なプロジェクトの進歩の必要性に対応して、このRFCは共同体のメンバーの利益のために発行されます。 本書では含まれた情報は、公表の日付現在、正確ですが、変化を被りやすいです。 その後のRFCsはそのような変化を反映するでしょう。

      These paragraphs need not be followed word for word, but the
      general intent of the RFC must be made clear.

これらのパラグラフは一語一語従われる必要はありませんが、RFCの総合的目的を明らかにしなければなりません。

4.  Distribution Statement

4. 分配声明

   Each RFC is to also include a "distribution statement".  In general,
   RFCs have unlimited distribution.  There may be a few cases in which
   it is appropriate to restrict the distribution in some way.

また、各RFCは「分配声明」を含むことになっています。 一般に、RFCsには、無制限の配布があります。 何らかの方法で分配を制限するのが適切であるいくつかの場合があるかもしれません。

   Typically, the distribution statement will simply be the sentence
   "Distribution of this memo is unlimited." appended to the "Status of
   this Memo" section.

分配声明は文が「このメモの分配は無制限です」であったなら単に通常、追加になるでしょう。. 「このMemoの状態」セクションに追加します。

5.  Author's Address

5. 作者のアドレス

   Each RFC must have at the very end a section giving the author's
   address, including the name and postal address, the telephone number,
   and the Internet email address.

各RFCはどん尻にセクションに名前と郵便の宛先を含んでいる電話番号、およびインターネットEメールアドレスを作者のアドレスに与えさせなければなりません。

6.  Relation to other RFCs

6. 他のRFCsとの関係

   Sometimes an RFC adds information on a topic discussed in a previous
   RFC or completely replaces an earlier RFC.  There are two terms used
   for these cases respectively, UPDATES and OBSOLETES.  A document that
   obsoletes an earlier document can stand on its own.  A document that
   merely updates an earlier document cannot stand on its own; it is
   something that must be added to or inserted into the existing
   document, and has limited usefulness independently.  The terms
   SUPERSEDES and REPLACES are no longer used.

RFCは時々、前のRFCで議論した話題の情報を加えるか、または以前のRFCを完全に取り替えます。 これらのケースにそれぞれ使用される、2つの用語、UPDATES、およびOBSOLETESがあります。 以前のドキュメントを時代遅れにするドキュメントはそれ自身のところに立つことができます。 単に以前のドキュメントをアップデートするドキュメントはそれ自身のところに立つことができません。 既存のドキュメントに追加されなければならないか挿入していなければならなくて、独自に有用性を制限したのは、何かです。 用語のSUPERSEDESとREPLACESはもう使用されません。

Postel                                                          [Page 4]

RFC 1111                    RFC Instructions                 August 1989

ポステル[4ページ]RFC1111RFC指示1989年8月

   UPDATES

アップデート

      To be used as a reference from a new item that cannot be used
      alone (i.e., one that supplements a previous document), to refer
      to the previous document.  The newer publication is a part that
      will supplement or be added on to the existing document; e.g., an
      addendum, or separate, extra information that is to be added to
      the original document.

前のドキュメントを参照するのに単独で使用できない新商品(すなわち、前のドキュメントを補うもの)からの参照として使用されるために。 より新しい公表は補うか、または既存のドキュメントに追加される部分です。 正本に追加されることになっている例えば、付加物、または別々の、そして、余分な情報。

   OBSOLETES

時代遅れにします。

      To be used to refer to an earlier document that is replaced by
      this document.  This document contains either revised information,
      or else all of the same information plus some new information,
      however extensive or brief that new information is; i.e., this
      document can be used alone, without reference to the older
      document.

以前のドキュメントを参照するのに使用されるために、それをこのドキュメントに取り替えます。 このドキュメントは同じ情報と何らかの新情報の改訂された情報かすべてのどちらかを含んでいます、その新情報がどんなに大規模であるか、または簡潔であっても。 より古いドキュメントの参照なしですなわち、このドキュメントを単独で使用できます。

      For example:

例えば:

         On the Assigned Numbers RFCs, the term OBSOLETES should be used
         since the new document actually incorporates new information
         (however brief) into the text of existing information and is
         more up-to-date than the older document, and hence, replaces it
         and makes it OBSOLETE.

したがって、そして、新しいドキュメントが実際に、新情報(どんなに簡潔であっても)を既存情報のテキストに組み入れて、より古いドキュメントより最新であるのでAssigned民数記RFCsでは、OBSOLETESという用語が使用されるべきである、それを取り替えて、それをOBSOLETEにします。

   In lists of RFCs or the RFC-Index (but not on the RFCs themselves),
   the following may be used with early documents to point to later
   documents.

RFCsのリストかRFC-インデックス(しかし、いずれのRFCs自身でも、そうしない)では、以下は、後のドキュメントを示すのに早めのドキュメントと共に使用されるかもしれません。

   OBSOLETED-BY

時代遅れにされます。

      To be used to refer to the newer document that replaces the older
      document.

より新しいドキュメントを参照するのに使用されるために、それは、より古いドキュメントを置き換えます。

   UPDATED-BY

アップデートします。

      To be used to refer to the newer document that adds information to
      the existing, still useful, document.

より新しいドキュメントを参照するのに使用されるために、それは既存の、そして、それでも、役に立つドキュメントに情報を追加します。

Postel                                                          [Page 5]

RFC 1111                    RFC Instructions                 August 1989

ポステル[5ページ]RFC1111RFC指示1989年8月

7. The RFC Editor

7. RFCエディタ

   The RFC Editor is Jon Postel.

RFC Editorはジョン・ポステルです。

8.  The RFC Announcement List

8. RFC発表リスト

   New RFCs are announced to the RFC distribution list maintained by the
   SRI Network Information Center (NIC).  Contact the SRI-NIC to be
   added or deleted from this mailing list by sending an email message
   to RFC-REQUEST@NIC.DDN.MIL.

新しいRFCsはSRI Networkインフォメーション・センター(NIC)によって維持されたRFC発送先リストに発表されます。 このメーリングリストからメールメッセージを RFC-REQUEST@NIC.DDN.MIL に送ることによって、SRI-NICに連絡して、加えられるか、または削除されてください。

9.  Obtaining RFCs

9. RFCsを入手します。

   RFCs can be obtained via FTP from NIC.DDN.MIL, with the pathname
   RFC:RFCnnnn.TXT (where "nnnn" refers to the number of the RFC).
   Login with FTP, username ANONYMOUS and password GUEST.

NIC.DDN.MILからのFTPでRFCsを入手できます、パス名RFCと共に: RFCnnnn.TXT("nnnn"がRFCの数を呼ぶところ)。 FTP、ユーザ名更生会、およびパスワードGUESTと共にログインしてください。

   The NIC also provides an automatic mail service for those sites which
   cannot use FTP.  Address the request to SERVICE@NIC.DDN.MIL and in
   the subject field of the message indicate the RFC number, as in
   "Subject: RFC nnnn".

また、NICはFTPを使用できないそれらのサイトのための自動メール・サービスを提供します。 SERVICE@NIC.DDN.MIL に要求を記述してください、そして、メッセージの対象の分野では、「Subject:」のようにRFC番号を示してください。 "RFC nnnn"。

   Requests for special distribution (for example, hardcopy) should be
   addressed to either the author of the RFC in question, or to
   NIC@NIC.DDN.MIL.

特別な分配(例えば、ハードコピー)を求める要求は問題のRFCの作者、または、 NIC@NIC.DDN.MIL に記述されるべきです。

   Unless specifically noted otherwise on the RFC itself, all RFCs are
   for unlimited distribution.

別の方法でRFC自身に明確に述べられない場合、すべてのRFCsが無制限の配布のためのものです。

   The RFCs may also be obtained from other information centers,
   including the CSNET Information Center (INFO@SH.CS.NET), the NSFNET
   Information Service (INFO@NIS.NSF.NET).

また、他の情報中心からRFCsを入手するかもしれません、CSNETインフォメーション・センター( INFO@SH.CS.NET )(NSFNET情報Service( INFO@NIS.NSF.NET ))を含んでいて

Author's Address

作者のアドレス

   Jon Postel
   USC Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, California  90292-6695

ジョンポステルUSC情報Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア90292-6695

   Phone:  213-822-1511

以下に電話をしてください。 213-822-1511

   EMail:  POSTEL@ISI.EDU

メール: POSTEL@ISI.EDU

Postel                                                          [Page 6]

ポステル[6ページ]

一覧

 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 

スポンサーリンク

SSDの現在のTBWを調べる方法 SSDの残り寿命 (Windows Linux CentOS)

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

上に戻る